Superb, thanks so much. Would it be possible for you to delete two so that the last page has 4 programs, then check for infopops on the last two? I thought I did and we had decided both spaces got infopop'd.

I will certainly I'll also check for every other combo.

Awesomesauce, sir, you're a lifesaver.

I'm Player/Tanner not SIr

Will edit with what happened.

Edit:
programs on last page | infopops
5 - 1
4 - 1
3 - 1

...I'm starting to see a pattern...

Then there's definitely a single program that the count routine thinks is visible and the display routine things is hidden. I look forward to the test set.

*bump*

I cannot believe how much effort and debugging that fix took. The routine that counts how many programs are oncalc has been almost completely reconfigured, and even Shell Expansions were among the casualties that needed to be configured. Please, please give the following beta a try, just browse through the desktop, make folders, try running some stuff from within DCS and via HomeRun, and see if you can make anything break:

http://www.cemetech.net/files/dcs6.8.8.8xk

Edit: I noticed that if an SE is installed, and an infopop activates, everything goes head over heels.

*bump again*

InfoPop+SEs issue fixed, must have been there for a while. Tentatively fixed issue with 'u' and 'v' and 'w' variables in programs causing the editor to crash by forbidding editing triggered by expr()-style problems for any variable not of type $05 (program) or $06 (protected program). Please test!

http://www.cemetech.net/files/dcs6.8.8_beta.8xk

An idea for error handling. Copy-pasted from IRC

With all the parser hooks, as you are going through the program, each time you get to a new line, store the Basic parser pointer, then if you happen upon a crash, back it up to that pointer.

An excellent idea. I feel like by the time I also stored the name of the current program, though, which would be vital for when a program called another program (called another program....), I would possibly impact the TI-BASIC execution speed in a nonzero manner. I'll definitely be open to considering more elegant and universal Goto tracking for error catching in the future, but for DCS 7 I'll stick with what I have for the sake of my sanity. I learned my lesson yesterday about trying to reconfigure core parts of DCS. :/

At any rate, I'm happy to hear that my fix was successful in that it prevents you from crashing your calculator with that parsing error. I don't suppose you've noticed the case where Goto's go to the wrong line with XLib/Celtic/DCSB Libs? That's my final bug on my bug list for 6.9.

I have indeed noticed that, it gets a little bit annoying :/ Though it seems to only go one line further down than it should.

Edit: Oh, and what did you mean about storing the program name? Don't you only need to do that once during its execution?

Come to think of it, the ParserHook is notified when execution begins on a new variable, but again, it could be a string or something, so I'd have to check if it was something like the "v" variable, and by the time I did all this checking I feel like I'd be adding more overhead.

Edit: One line further, really? The next time you notice this happening, can you let me know (or if you can think of a place where you can replicate it?).

I seem to recall it happening with something like:

Code:


(I was trying to remember the syntax for the dcs libs while this was happening ) That should work...maybe. I haven't tried it in a while

That didn't do it for me, but this did; it went to the "666" line:
Code:
Does that sounds about right? I didn't realize it always went one line too far, is that what you say is the case?

... it isn't even erroring on what I posted... Even if I change it to a sum(7 or whatever...

If you pause the answer from the Sum(...) you'll see the error code. But does the code I posted do what you expected?

indeed, it stops on line 666

I noticed that when I removed the sum(0 and replaced it with sum({8,5 that it did the same thing still. I had thought that the sum() was what was throwing it off. I'm pretty sure there's some cases in which the Goto is correct though, so I need to figure out in precisely what instances it breaks.

ok... i found something funny,

not really a bug, but still something that needs fixing...

if you replace a file using TI Connect from a computer, it seems that it ends up leaving 2 exact copies of the same file in DoorCS's view

but... you could just delete the older copy anyways... so its not that big of a deal



oh... and also the new DE7 seem to make files that it edited up back out to the desktop...

i am not sure yet since i have yet to confirm this, but its very likely

Quick thing, it seems that ever so often a file will be claimed non exsistant, which then causes some weird glitches O_o

Huh? I don't understand how that's possible.

Were you able to confirm this?

Edit: An email conversation: