Then Mateo's post reminded me. DCS hinders my calculators charging abilities when I turn it off via the DCS homescreen. It gets about half the charging it would get done if it is turned off via the actual equation screen.
KermMartian wrote:
merthsoft wrote:
Two feature requests:

1) Ability to run a program whose name is in a string.
Is it too complicated to use the Celtic 2 CSE functions to put "prgmNAME" in a program and call that instead? I certainly will be the first to admit that that's not very elegant.
Certainly not too complicated, just not ideal. That adds a few steps that seem unnecessary.
KermMartian wrote:
Quote:
2) Ability to "register" custom headers with a program, so that a program with that header will be run with the program that is registered. The registering program would have a function to get the name of the program that ran it in a string. This would facilitate custom level sets and such. (I probably would say no to this request unless multiple people wanted it. I know I'm kind of unique in some of my wants Wink)
Doors CS 7 tried to provide this for ASM programmers, and I think Document DE (and maybe mobileTunes 3) are the only programs people actually use that exploit this feature. I doubt this will find its way into Doors CSE for ASM or BASIC programmers.
That's what I figured--no big deal.

KermMartian wrote:
solarsoftware wrote:
Also, could we have the ability to disable ERR:BREAK while running BASIC programs in a setting or something? They're running in a frame, so it would be possible.
I don't know what you mean by "frame", but they're not running in any such thing. Yes, I could make programs able to catch [ON], but I won't, because it's too easy for newbie TI-BASIC programmers to lock up users' calculators that way.
Agreed here. This would be a terrible feature. It would be too easily for someone to accidentally or maliciously force a battery pull.
But people's lock screen could easily be broken that way... ;( (sheds single tear)
solarsoftware wrote:
Bug: I used the input command with a variable, and my code was Input("",A. The input displayed a square, my calculator whitescreened, and then it reset. Fix?
Suggestions:
-bumping up brightness
Question:
When will 8.2 be released? (beta if available)
Off-Topic:
Will we be seeing mobileTunes 3 for CSE/CE anytime soon?


Input occasionally glitches like that for me, too. I don't think it's a DCSE thing.
Kerm,

EDIT: Removing bug report that was user error Neutral

Thing 2:

Code:
prgmA
1

3
4
5


Code:
prgmB
"1->Str9
"A->Str0
2:det(1


After running prgmB, the results were
Quote:
1

3
4
5
And str9 said ..NULLINE

So, the tl;dr:
If you insert into a blank line, nothing happens.

Also, I think I've mentioned this before, but it'd be nice if ArcUnarcVar could take a parameter to specify archiving and unarchiving. Also, does the wiki page have a list of the possible error codes? I couldn't find one.

Also also, I can't turn off my calc when in the program editor.
Double post for new bug report:
If you do something like

Code:
prgmA
Disp A

and then do:
1->A:prgmA
It may not display the right variable. Here's a screenshot:

Note this is with DCSE 8.1.2 Build 1547 with OS 4.2. With OS 4.0 with DCSE 8.0.1 Build 1339 this does not happen. Ans is not affected, but I did test with B and got the same results.
merthsoft wrote:
Double post for new bug report:
If you do something like

Code:
prgmA
Disp A

and then do:
1->A:prgmA
It may not display the right variable. Here's a screenshot:

Note this is with DCSE 8.1.2 Build 1547 with OS 4.2. With OS 4.0 with DCSE 8.0.1 Build 1339 this does not happen. Ans is not affected, but I did test with B and got the same results.


The full mem reset isn't necessary-- it'll also stop happening if you do the commands separately (as in, 1->A, press ENTER, then run prgmA). Even if you enter 1->A:prgmA after that, it'll show up correctly.
The bug returns if you DelVar A.
It looks like it affects all TIOS variables, including theta, n (the sequence/recursive equation variable; go to catalog and press N) and Ans.
The full reset was to demonstrate that it's not an OS issue. The beginning of the GIF is without DCSE installed.

For me Ans was not affected. Can you post your test code? I had Disp Ans and then did 1->A:prgmA and 3->A:prgmA and got 1 and 3.
merthsoft wrote:
The full reset was to demonstrate that it's not an OS issue. The beginning of the GIF is without DCSE installed.

For me Ans was not affected. Can you post your test code? I had Disp Ans and then did 1->A:prgmA and 3->A:prgmA and got 1 and 3.


Oh, right. You did mention in IRC, though, that it's 'fixed with a full reset;' I was responding to that.

That's actually exactly what I did (although I only tried 1->A and not 3->A), maybe try DelVar Ans and run it again?
/s
Huh, I must've mis-tested. You are right, this does affect Ans.
Request:
In archiving and unarchiving a program, can the calls be made definite in det(5? Like 1 for archiving and 2 for unarchiving or something? Instead of a toggle?
solarsoftware wrote:
Request:
In archiving and unarchiving a program, can the calls be made definite in det(5? Like 1 for archiving and 2 for unarchiving or something? Instead of a toggle?

As a workaround for this, try this:

Code:

:"(name of AppVar/Program, with the beginnning being the rowSwap( token if it's an AppVar"->Str0
:det(8
:sub(Ans,1,1
:If Ans="R":det(5            ;or, Ans="A" to run det(5 if the var is archived. Ans="R" to test if it's in RAM.

Sorry if you already know this, just trying to help! Smile
EDIT: You forgot about Str9...

I fixed it now, Cortana's icon now changes even when archived! Laughing

BUG: Attempting to move a program in a string doesn't work.
Str3:det(11,0,4:prgmXTEMP004 won't work
Electromagnet8 wrote:
In the past it was mentioned that there is a bug in DoorsCSE where the alpha hotkeys do not work after running DoorsCSE.
In the animated screenshot below, I load DoorsCSE and a program into archive.
I then open DoorsCSE and run the program.
I enter a value in by pressing [2nd].
After I input the value and press [Enter], I quit the program by pressing [Clear].
I then press [Enter] as DoorsCSE prompts in the status bar.
I quit DoorsCSE by pressing [Clear].
Finally, I try the alpha hotkeys. None of the hotkeys work.
To fix this, I run DoorsCSE via the [On][Prgm] keyhook and quit with [Clear].


KermMartian wrote:
That seems to be the main way around it. I'm disappointed to hear that this is a widespread problems with programs that use Input/Prompt, though, and I'm trying to track down which flag or hook interactions are responsible for the problem.
I have found the problem, and I think it may be an OS bug. When _ParseInp is called from an App, and Input/Prompt (ie, the edit context) is invoked, appRunning,(iy+APIFlg) does not get properly reset once the App is completely exited. This prevents the context menus from launching. This fix will be in the next Doors CSE release.

Unicorn wrote:
Then Mateo's post reminded me. DCS hinders my calculators charging abilities when I turn it off via the DCS homescreen. It gets about half the charging it would get done if it is turned off via the actual equation screen.
This is extremely unlikely. Doors CSE simply invokes the OS's [2nd][ON] functionality, so the OS has full control when it turns off the calculator.

merthsoft wrote:
Double post for new bug report:
If you do something like

Code:
prgmA
Disp A

and then do:
1->A:prgmA
It may not display the right variable. Here's a screenshot:

Note this is with DCSE 8.1.2 Build 1547 with OS 4.2. With OS 4.0 with DCSE 8.0.1 Build 1339 this does not happen. Ans is not affected, but I did test with B and got the same results.
Thanks for this thorough report. I will do my best to track this down and let you guys know what I find.

Edit:
Merthsoft wrote:
Note this is with DCSE 8.1.2 Build 1547 with OS 4.2. With OS 4.0 with DCSE 8.0.1 Build 1339 this does not happen. Ans is not affected, but I did test with B and got the same results.
I tested this as appearing with OS 4.0 and both the latest build and build 1339.

Edit #2:
IRC wrote:
[00:40:53] <@KermM> BrandonW: in http://brandonw.net/svn/calcstuff/Noshell/trunk/hook.asm , can you explain what the code at homescreenProg does?
[00:41:13] <@KermM> It appears to find a line of input on the homescreen with a prgm token and run just the program in that line.
[00:41:41] <@KermM> Why not just wait until the parser hook just gets called on that program?
[00:41:58] <@KermM> I ask because Doors CSE does something similar, and it's making 1->A:prgmB not function correctly.


Edit #3: I made a lot of progress on putting together this new ParserHook, and with unarchived BASIC and Assembly programs, colon-delimited homescreen commands work well. Unfortunately, I discovered that when the TI-OS invokes the ParserHook with a=0 and a program name, it has already checked to see if that program is unarchived, which explains why BrandonW does what he does. I may have to revert my edits and forget about solving this bug.
*bump* Unfortunately, I'm marking that bug with WONTFIX, because the TI-OS checks if programs are Archived before invoking the ParserHook on programs that are about to be executed. My approach of waiting until a program is about to be executed, or an Asm( command is starting to be parsed, will therefore not work. An alternative might be to replace prgmXXX with a special command that my ParserHook can intercept, an alternative that I'll continue to explore if people like BrandonW will humor me.
A way to test the color of a pixel on the graph screen. Like Pxl-test, but it gives a color number rather than simply 1 or 0 .
ReGuess wrote:
A way to test the color of a pixel on the graph screen. Like Pxl-test, but it gives a color number rather than simply 1 or 0 .

You mean like GetPixelA and GetPixelB? I think these require being in xLIBC drawing mode, though.
I was gonna suggest those, but I had the impression that ReGuess wanted to pixel-test what's actually stored on the graph screen as opposed to the LCD itself.

GetPixelA and B works in both 320x240 and 160x240 mode, but as I witnessed when making my FF:MF game, it operates as if the vertical resolution was 120 pixels, so it only checks every two pixel vertically. In addition to that, you'll have to switch between both half of the screen because GetPixelA/B only use half of the screen at a time.
Don't know where to post this, but yeah, take a look Razz
PT_ wrote:
Don't know where to post this, but yeah, take a look Razz
You created a program with a non-alphanumeric name. I'm not sure whether this is a feature request (translate tokens to text, to which I'd say no) or a bug report (to which I'd say that this is not a bug).

Edit:
Merthsoft wrote:
Also also, I can't turn off my calc when in the program editor.
APD, instant APD via ON-STAT, and pseudo-APD via 2nd-OFF now work in the program editor. I especially like being able to 2nd-OFF in the program editor and return to where you were.

Merthsoft wrote:
So, the tl;dr:
If you insert into a blank line, nothing happens.
Actually, if you *replace* a blank line, the code appears to not let you. I have no idea why Iambian coded it that way, but now it simply inserts the new text there.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 10, 11, 12, 13, 14  Next
» View previous topic :: View next topic  
Page 11 of 14
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement