DJ Omnimaga wrote:
Let me tell you about the hours and hours that I spent obsessing over that exact issue, Kevin (search "Reuben" on my Doors CS 7 Scratchwork page). In the end the best I could come up with was some crazy Omnicalc combination of flags and such that I simply couldn't replicate. Hope you're not too unhappy about that.
Sorry I missed it in the long list of bug reports x.x. I wonder if it could have to do with the usage of the Horiz command?
DJ Omnimaga wrote:
Sorry I missed it in the long list of bug reports x.x. I wonder if it could have to do with the usage of the Horiz command?
It could absolutely have something to do with that. If you want, I can bump that particular bug report and see if I can eventually figure out what the issue is.
When I recall a picture (pic100 for example) it works great, but then if I want to display text superimposed onto the picture, it clears the screen, but this only happens the first time you call the text( routine within the execution of the program. I was able to get around this by placing a text(0,0,"" after recalling the pic for the first time and recalling it again. After that, the rest of the program and subprograms run fine. I had to make the code similar to this:
real(3,100,0,1
text(0,0,"" <- Clears screen
real(3,100,0,1
text(20,20,"Hello World" <- Displays text without clearing the screen
I haven't tested this with the standard pics 0-9, but I am for sure getting this problem with the non-standard pics. When I use standard xLIB, I do not get this problem.
Have you tried using a RecallPic instead of real(3...) and seeing if the same thing happens? Also, what OS version are you using, 2.53MP or something earlier? I suspect this may be yet another ridiculous TI-OS flag issue, of which I had already traced down many during development.
*bump* Tanner reports a bug wherein sum(7,8,... stores and displays the wrong hexadecimal sequence. It appears from a memory examination that it is indeed a Doors CS bug.
Edit: Fixed, it was a single '4' that should have been '6'. I'll accumulate a few more bug reports before patching.
Editing programs while using DCS is *faaaarrr* slower than the TI-OS editor.
player, I said the exact same thing to Kerm, be he didnt beleive me, perhaps you will convince him
_player1537 wrote:
Editing programs while using DCS is *faaaarrr* slower than the TI-OS editor.
Grrrrrrrr it IS the TI-OS editor. Go yell at TI.
It does slow down in particularly large files. Otherwise its fine.
KermMartian wrote:
_player1537 wrote:
Editing programs while using DCS is *faaaarrr* slower than the TI-OS editor.
Grrrrrrrr it IS the TI-OS editor. Go yell at TI.
I have experienced that scrolling text is extremely slow - in general - if you have MathPrint enabled. Perhaps this has something to do with the problem (this is of course a TI-OS related issue)?
ACagliano wrote:
It does slow down in particularly large files. Otherwise its fine.
I'm sorry to hear that, and I wish there was something I could do about it, but again, I hand over full control to the TI-OS during editing, and only catch the AppChange event when the editor exits in order to bring you back to the Doors CS desktop.
Two minor, minor glitches that I've fixed:
:: The sum(7,8 glitch noted above
:: A one-pixel error in the hotspots in the DCS Menu
I'll look at an xLIB/TI-OS flag issue that was reported, as well as a possible issue with the Celtic III LineRead() function with archived programs, next.
@Olav: That makes sense. Once again, it's all on the TI-OS, so maybe they just wrote terribly unoptimized code for when the editing window is 8 rows tall.
*bump* I solved the LineRead issue, it was as simple as a "nz" instead of a "z" on a jump. I'm thinking of quietly patching the version of DCS here and on ticalc.org for that, the sum(7,
bug, and the one-pixel DCS Menu offset; does anyone have any other quick and simple bug reports?
KermMartian wrote:
*bump* I solved the LineRead issue, it was as simple as a "nz" instead of a "z" on a jump. I'm thinking of quietly patching the version of DCS here and on ticalc.org for that, the sum(7,
bug, and the one-pixel DCS Menu offset; does anyone have any other quick and simple bug reports?
This is obviously very minor, but if you go into the option to rename a program, then cancel the renaming process, the file, if it was archived, becomes unarchived.
technomonkey76 wrote:
KermMartian wrote:
*bump* I solved the LineRead issue, it was as simple as a "nz" instead of a "z" on a jump. I'm thinking of quietly patching the version of DCS here and on ticalc.org for that, the sum(7,
bug, and the one-pixel DCS Menu offset; does anyone have any other quick and simple bug reports?
This is obviously very minor, but if you go into the option to rename a program, then cancel the renaming process, the file, if it was archived, becomes unarchived. Huh, that's a bit odd; I might as well fix it. Thanks for noticing that.
Edit: Fixed that, and fixed a few other places where I played fast-and-loose with Op1. Care to test the fixes for me?
*bump*
I quietly released Doors CS 7.0.1 today, which adds four bug fixes: (1) one-pixel hotspot misalignment in DCS Menu, (2) Canceling copy/rename caused archived programs to move to RAM, (3) small LineRead bug in CIII libs due to flag transposition, and (4) Incorrect functionality of DCSB Libs sum(7,8,...) PushGUIStack function for GUIRButtonImgs.
Details:
http://dcs.cemetech.net/index.php?title=Version_History
Bugs regarding DCS7 and Graph3 conflicting:
When homerun is activated, the Xmin variable in 3D graphing gets random characters added to the end of it after it has been selected by the cursor.
The editor in DCS7 won't start when Graph3 is active. First try returns to the desktop, second try starts the editor, but with an empty project. This has however no effect on the program edited.
olav_nordmann wrote:
Bugs regarding DCS7 and Graph3 conflicting:
When homerun is activated, the Xmin variable in 3D graphing gets random characters added to the end of it after it has been selected by the cursor.
The editor in DCS7 won't start when Graph3 is active. First try returns to the desktop, second try starts the editor, but with an empty project. This has however no effect on the program edited.
Very weird. It sounds like Graph3 might have an AppChange hook that is stopping Doors CS from properly handing over control to the TI-OS for the editor. Do you consider these serious enough for me to try to find a solution, or not really? The obvious solution would be to either disable Graph3 or Doors CS 7's HomeRun feature, which admittedly is not the most elegant fix in the history of bugs and conflicts.
I have the following issue.
Yesterday, I attempted to run a program and it gave me an error within the code. I went to select Goto. DCS did not goto, but instead I exited DCS and went to the homescreen automatically. When I did this, I found that pressing the PRGM key and moving over to EDIT caused the calc to take a very long time to process. I returned to DCS and disabled the parser hook. That resolved the issue.
ACagliano wrote:
I have the following issue.
Yesterday, I attempted to run a program and it gave me an error within the code. I went to select Goto. DCS did not goto, but instead I exited DCS and went to the homescreen automatically. When I did this, I found that pressing the PRGM key and moving over to EDIT caused the calc to take a very long time to process. I returned to DCS and disabled the parser hook. That resolved the issue.
The first part of the bug report is indicative of the TI-OS passing insufficient information to Doors CS about where the error occurred, such that it was impossible to open the editor. I'm not sure about the second part of the report; is this replicable? If so, can you send me the program in question and post here instructions on reproducing it?