I could swear it took more voltage (via a charge pump, so therefore more current) to erase than to write, but a few minutes of researching didn't turn up a solid comparison.

@Brandon Would it be possible to get right/secondary click to pass 15 to getKey? And maybe even up/down arrow or +/- for scroll up/down? B/c it would be epic if you could get a mouse to take full advantage of the DCS homescreen... plus, I would love to write programs that work well with a mouse.

Since he's making an SE, he could do that by in quick succession setting the X, then Y coordinates, then clicking, so it would definitely be useable.

I'm not following, what does getKey have to do with anything?

He's just misunderstanding how Shell Expansions work. Do what I said instead?

Except I don't get what you're suggesting either.

In order to click on the scroll up or scroll down buttons, I'm suggesting returning d three times in successive iterations, using one of your two safeRAM bytes to signal where you are in the sequence. You'll need to return d once to set the x, again to set the y, and a third time to click.

I see, you were talking about scrolling up and down.

Indeed. An alternative is to take advantage of the fact that I said I'm not going to move MseX and MseY, and just adjust the cursor yourself and then return d to click, but I don't like that quite as much

I have two requests for additions/modifications to DoorsCS, Kerm:

1. You said I wouldn't be able to use certain parts of the DoorsCS GUI because the shell expansion would try to recurse while I was trying to bring up a dialog (or something to that effect). Would this be easily solved by having a flag in memory that I can set/reset to enable/disable loading and execution of the shell expansions?

2. Would it be possible for you to load the name of the currently-executing shell expansion into memory (for example into OP1 or progToEdit or something) when executing SEBoot? So that I'm aware of my own name, should it ever get renamed, and I can consistently look myself up for stuff.

Actually, the problem is that loading up the GUI system when Doors CS isn't expecting it (ie, in an SE) will almost definitely make it crash and burn when your SE returns. We *might* be able to figure out a way for you to collapse the stack and jump to the beginning of the DCS App, but I'm not sure, and that sounds super-hacky.

Hmm, that might be difficult. I'll think about how I could implement that.

Progress update: in addition to what's in the video, it now shows a configuration screen when you middle-click allowing for adjusting sensitivity of X direction, Y direction, and the scroll wheel, which automatically clicks up and down on the DoorsCS scrollbar when you scroll the wheel.

It also has the beginnings of support for "gestures", which is really just moving the mouse to any of the 4 corners, which will let you run a program or FLASH application. (Circular motions and so on are difficult and just beyond what I want to put into this.)

Kerm, does runprog work now? If I swap in the base page of DoorsCS (or whichever page it's on), can I call it directly as if I were a MirageOS program? I don't need to regain control after calling it. And if so, could you store the name of the FLASH application (or the page containing the MirageOS jump table) somewhere so I'm not hard-coding "DoorsCS7" or anything?

That's epic! And nothing fails from using the GUI in the middle of the desktop?

That makes sense.

RunProg works beautifully now. You can use Doors CS' RunProg just like MirageOS's, except that it of course supports more filetypes and functionality, such as AP files. Since your SE is getting called from Doors CS, and specifically from the base page (by design), why not just read port 6?

I'm currently having an issue with the configuration screen, which I think is related to my dynamic loading of SE sections.



I could, now that you've confirmed that's where it is.

Would you recommend running a FLASH application from within an SE? Is there clean-up that you must do first before giving up control to me (and before I give up control to the application)? If so, it could be modified to go into your _PutAway vector, which _ExecuteApp will eventually trigger.

If you could sufficiently clean the stack, make the SE put Doors CS back into Bank 1 after you run the other app, and then start it over, then I see no problems with brutally stealing control from it. If that's infeasible, then the main problems would be with hooks like the GetCSC hook and the Parser hook being disabled, since Doors CS wouldn't have gotten a chance to re-enable them on exit.