Glad I could help, also another bug.
Double-right clicking on any item in the 1st slot produces an exit from Doors and a few strange symbols onto the main screen.
xXEpicxXXxFailXx wrote:
Glad I could help, also another bug.
Double-right clicking on any item in the 1<sup>st</sup> slot produces an exit from Doors and a few strange symbols onto the main screen.
Odd, I can duplicate that, but only when I'm in a non-desktop folder. Do you see the same?
Hehe, double post.
And yes, I see the same.
xXEpicxXXxFailXx wrote:
Hehe, double post.
And yes, I see the same.
Fixed the double-post. 
OK, thanks for verifying that; I bet the two bugs are very closely related.
KermMartian wrote:
Fixed the double-post.
OK, thanks for verifying that; I bet the two bugs are very closely related.
Yeah, I'd say so.
Also, not another bug, but a suggestion for the next beta.
While using some of the libs (sum(6) especially), if scripted badly, the game could get hung up on the command. For this, there should be an exit-program button (clear?).
While testing out more libs I forgot which way the coordinate system went and scripted buttons off of the screen so they were unreachable by mistake. I also had the game in a loop so if you clicked an empty space it would go back to sum(6). Since I couldn't reach the coordinates for quiting, I was stuck. I couldn't break the test game, because on just turned it off. Long story short(ish) I had to pull a battery to quit. To prevent this from happening to other users there should be a quit button. This would be highly appreciated.
I've had the same problem, but what I did was I had 4 buttons on the screen, although only one worked. Luckily it displayed Text on the homescreen and then was at Pause. So all I had todo was Click "ON". But yes, an exit button would be very helpful.
I've kinda noticed that in my own testing. I'm not really sure what to do about it though, because I don't want to remove the ability to press any of the keys, although I guess that's kinda pointless for the BASIC mouse. What would be a good [BREAK] key?
KermMartian wrote:
...What would be a good [BREAK] key?
[STO->] and [Y=] are kinda out-of-the-way, maybe one of them?
Yeah, Do Y=. Its not easily accessable, but its not too hard to reach.
Svakk wrote:
Yeah, Do Y=. Its not easily accessable, but its not too hard to reach.
Actually, I almost liked [STO>] better; it's close to the [ON] key. I'll try both and see how they feel. And what do you think the behavior from pressing that should be? What should be the return values?
Oh, I don't know. Maybe something similar to :stop, but safer.
xXEpicxXXxFailXx wrote:
Oh, I don't know. Maybe something similar to :stop, but safer.
Well, it generally returns {X, Y, click, item}, so how about if I return -1 as item? I think that would be good.
Sounds great, try it out.
xXEpicxXXxFailXx wrote:
Sounds great, try it out.
That took way longer than it should have, mostly due to my exhaustion and silly mistakes. Press [STO>] for a panic buttons; Ans(3)=0, Ans(4) will be one higher than it could ever be otherwise. Either handle it as a special case or ignore it and reloop, in which case you get a few cycles to press [ON] and trigger an ERR:BREAK.
Details:
http://dcs.cemetech.net/index.php?title=BasicLibs:GUIMouse#Description
Sounds awesome, one step closer to Doors CS 7 being epic.
xXEpicxXXxFailXx wrote:
Sounds awesome, one step closer to Doors CS 7 being epic.
Thanks, I hope so. Next up is some improvement to the GUIRMultiline text input box, including making scrolling up more dependable, and using the edit buffer functionality to speed things up.
calcdude84se wrote:
Bug report about GUIRTextMultiline:
One can click in empty areas and the cursor will be halfway on a line and can be moved outside of the input area.
Bug resolved!
calcdude84se wrote:
In addition, the cursor will occasionally be in the middle of a character rather than between characters.
Screenie:
calcdude84se wrote:
A third bug, which I have trouble consistently replicating but have nonetheless encountered multiple times, is that the beginning of the contents of the input area can be made to display elsewhere than the top-left screen corner, and garbage is displayed before it. Sometime the garbage covers the whole area (or seems to clear it) and the actual beginning cannot be seen.
Haven't touched this one yet, as I can't seem to replicate it. Want me to send you another beta to see if it got fixed as a side-effect of these things, or if it's still there?
Sure, that'll be fine. I'll mess around again w/DocDE and see if I can get it to happen.
calcdude84se wrote:
Sure, that'll be fine. I'll mess around again w/DocDE and see if I can get it to happen.
Superb. In the meantime, I'll consider what it will take to move text editing to the edit buffer, and how I can do so without breaking anything.
http://www.cemetech.net/files/dcs6.7.4_beta.8xk
xXEpicxXXxFailXx wrote:
Fabulous work, as always! Just checked out the libs (on my new TI-84+SE) and they are stunning. I guess this means that Doors CS 7.0 is in the close future.
However, a quick bug I found.
1. Made folder
2. Entered said folder
3. Opened side menu by right clicking
4. Clicked the back arrow
This crashed it. Should be simple to fix.
Finally repaired! Turned out that a pointer into an item to be added to the GUI stack was off by three. It was quite hard to trace and replicate. This also fixes the second related issue that was reported.
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
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
