I think that's the most creative bug report I've seen in a long time. 😁 Anyway, I plan to stick with the rendering shown on the left. I don't think I understand your objection, still, though. Are you saying that if you click on the (non-present) minimize button, for example, when only the close button is being drawn, then the GUIMouse still terminates? If that's what you're complaining about, that's laziness on my part, and I can easily fix that. If not, could you explain what you mean by "how clicking on them is handled"?

Actually I guess it was 2-part. Yes, GUIMouse terminates when clicking an undrawn button. (That the undrawn ones have triggers is fine, and is actually somewhat useful)
The main thing, though, is that, when clicking on the GUIRWinButtons, I have to click on them as if they were drawn as shown on the right.

I have a suggestion, a routine that will keep the mouse present until a certain area within coordinates is clicked. So users could increase values via clicking arrows on-screen and click "Done" when they are finished after which control can be sent back to the program with the values left in fields.

Hm? If you have a GUIRByteInt or GUIRWordInt, then their value can be modified w/o sum(12 returning.
If you just have arrows, then you program needs to handle the clicks anyway.
If you mean being able to click and then have the cursor go back to where it was, just save the results of sum(6 or sum(12, and use the first two elements of that list (which are the X and Y where the mouse clicked) as the first two arguments of sum(6 or sum(12 last time.

Oh, right 😄 My bad.

Kerm, any luck with the nspire power bug yet?

"No progress [yet, he hasn't] ... looked at itt recently." -KermM 😄

Ah, ok, thanks comic and KermM, just wanted to check

One thing I'd like to do is make those typeable, because it's pretty slow to move across a long range of numbers with GUIRWordInt and GUIRByteInt.

Okay, it seems that many misconceptions have been thrown about for ALCDFIX. It does not modify the OS at all, and it does get undone by RAM clears. What it does is modify the value in the LCD delay port, which is SE/84 only. It requires no modification of any fastcopy routines, it simply adds extra delay after access of ports $10/$11.

Reading http://michaelv.org/programs/calcs/ports/port29.html and http://wikiti.brandonw.net/index.php?title=83Plus:Ports:29 , does that mean that $00->port $20 and $F7-->port $29 is basically all ALCDFIX does? Or is it more complicated than that? This is easily something I can add the DCS7's "boot" sequence.

I think $F7-->$29 is a bit large of a delay. I think ALCDFIX tries to tune the delay to the LCD (well, at least, it displays a bunch of garbage to the screen during execution).

I think I'm misunderstanding; I thought $F7 made the LCD execute at full speed and thus go at its fastest. Anyway, it makes sense that it would do some tuning; it seems to me the best option would be to disassemble ALCDFIX (or find source) and see if I can figure out how it works.

No, the value of port $29 controls the wasted clock cycles after writes to the LCD ports.

its open source, http://www.ticalc.org/archives/files/fileinfo/366/36608.html

Oh, nice! I downloaded it from some "TI-Wizard" site, which didn't have the source in the zip, just a really shoddy readme. Checking over the source now.

Posting reminder, as requested on IRC:

Add an LCD delay slider bar to the Display window, and a button that attempts to tune it to the display, a la ALCDFIX. Don't forget SE/84 only.

Thanks calc84! Duly noted, and added to the To-Do list:

http://dcs.cemetech.net/index.php?title=Doors_CS_7_Scratchwork#To-Do_Items

*bump*

OK, I fixed the first of the issues, the mis-alignment of the clicking. I also managed to optimize out 99 bytes from the GUIMSWinbuttons routine that generates hotspots on the fly from a GUIRWinButtons item on the GUI Stack. I just need to implement something in the DCSBLib section to not allow clicking for the non-present items; I'll edit this post when I do that.

Edit: All done! I optimized another 10 bytes or so off of Page 1, only to spend about 20 bytes on Page 2 adding the click clearing.

Regarding the GUImenu, will we have access to the Start Menu?

It'd be neat if we could access certain aspects via the following:
Code:
Access the desktop. Add items to the desktop. For each line of sum(13,1 add a new icon with the following HEX, would make great use in an RPG trying to make an inventory with graphical icons.

Code:
Access Start Menu, for each new line add another item to the menu, but no more than six? Etc, etc.

Or, am I lagging behind here?