Ok, here's what I'm on about


Code:

Yes, that would work, but why push and pop hl and then jp? Why not just call GUIMouse directly?

Well, I placed call GUIMouse in a subroutine so that I didn't have to deal with several call GUIMouse's. Memory-wise. Plus, its just easier for me to follow. The pop and push hl are so that hl can vary and still use the same routine.

You misunderstand me (I think): jp'ing to a routine doesn't modify any registers (other than sp, but that's neither here nor there). Therefore, there's no need to push and pop hl across the call, because pushing and popping is to protect registers from use, and nothing is using hl between the push and the pop. Therefore, when you remove the pushes and pops, it just looks like:


Code:


Because a jp and a call are the same size, there's no point jumping to a call instead of just performing the call directly:


Code:

Oh. I feel like an idiot.

Ok, considering that my current username is at de and the input one is at hl, will this routine display the submit button if a change has occurred?


Code:

Wait, is that inside the MouseHook? Manipulating the GUIStack from within the MouseHook is very very very not a good idea at all.

Hmm. I don't really mod it, other than push or pop the button. How would you recommend I achieve the button then? Maybe scrap the MouseHook and have this test done at the beginning of the Submit Button's goto. If it fails the test, call the Mouse again, so that you are forced to go back.

Edit: My internet bugged out. The two successive posts happened by accident. You can delete the former.

Edit 2: Here's my rewrite--

Code:

Looks good to me. Yes, pushing and popping items from the stack inside the mouse is modifying the stack. Among other things, the mouse pushes a bunch of items corresponding to special hotspots and areas (for example, hotspots for windowbutton items, for buttons, for input boxes, etc), which end up at the top of the stack. If you then push more stuff on top of those temporary stack items, things tend to go kablooey.

Oh. I see. So theoretically, tho, if I could locate the last item I push before calling GUIMouse (maybe by pushing the pointer to the current location), I could do it (bcall(_InsertMem), change size field, push item), but I'm sure that's not something you would recommend (and something I wouldn't try )

Doors CS points some of its own pointers into the GUIstack, so unfortunately those would get broken too. So yeah, not recommended.

Umm...I use a temporary program, in RAM, to contain the network data. The program initializes at 1052 bytes, which is enough room for 50 members and a 2 byte size*. At this point, the server stops anyone else from joining.

*The two byte size is the pointer to the next free space in the program. So, de contains the first byte of the program, the word at de gets loaded into hl, then de+2 and hl get summed, bringing me to the place to write data from a join message.

I plan on pushing 'de' into the stack, so that I can pop it whenever I need it, but I forgot that the program may move around. Is there a way to prevent this. Other than write data into the program, use CALCnet, and use the GUI system in DCS7, I do no other program/appvar creation. So, a few questions:

1. What is the call that move the GUI appvar above all other programs/appvars?
2. If I call this before creating my appvar, will it move?
3. Should I use the push/pop method, or should I create a pointer to it in some RAM location and use that as kind of a lookup table?
4. *Very important* Can I use CALCnet, the GUI system, and saferam1 all simultaneously? Remember, that the data in saferam1 must remain constant. Saferam1 contains ship info and system health data. Or should I create another temp program to hold this data?
5. If I go the temp program route, can I do 'ld a,(de+n), where n is the number of bytes forward, to read data, or must i do "ld hl,n / add hl,de / ex hl,de / ld a,(de)"?
6. If I am within a 'call', is there a way to do kind of like an "absolute ret" , where I exit the program? If not, I can just change the call to a jp, then just jp back to the beginning of the battle loop.

0. Why not just use a 2-byte piece of the hundreds of bytes of immoveable safeRAM for the address, instead of using the stack? It'll make life much easier for you. (You know about the safeRAM areas, right?)
1. The call you're thinking of is APGui_gui7ToTop. Note that if you use this, you'll have to ChkFindSym your appvar again
2. Probably. HOWEVER. If you create your appvar before you OpenGUIStack, then you do NOT need to use that call, because the varying size of the GUI stack will not move your appvar around. This is the better solution.
3. See Point 0.
4. CALCnet and the GUI system work well together. Note that the mouse and CALCnet do not work happily together unless you use a mousehook that starts with im 2 \ ei, even if that's the only thing in the hook. I can show you some example code for this if you need. Check out Interfacing CALCnet2 -> Memory Areas for details about memory that you can and cannot use.
5. No, only the ix register can do that sort of indexing, and only +/- 127.
6. Yes. This: QuitToShell. You really should jump to a routine that shuts down Cn2, closes the GUI stack, and deletes your temp appvar, then calls that, though.

Ok,

0= The problem still remains that the program will move. So, here's another question. Though the program moves, does the VAT entry for that program move? If not, then I'll indirect to the VAT entry, then use that to jump to the program's address.
1= OK.
2= OK.
3= OK.
4= Sure, I'd like to see some code. What will happen if I don't do that? Would it be safer to use "call RenderGUI", then use direct input to handle the screen?
5= OK. No biggie. I can use the longer method.
6= OK.
7= NEW: So, with Cn2 + GUI active, would it be better to use saferam or to create temp programs (I'd need 2) to hold my data.

0 - If the appvar is below the gui7 appvar in RAM, it will not move as long as you don't delete or resize anything below your appvar. Do I misunderstand? And I would be even less confident about static VAT structure than static ordering of items in RAM
4 - Then the Cn2.2 interrupt gets disabled, and network activity stops. You could do that solution, but if you don't mind the stub mouse hook, it'll make everything work fine with Cn2.2 + the GUI mouse.
7 - Either one would work equally well. If your necessary storage is larger than the amount of available safe safeRAM, then that's your answer there.

4= ok, what do I need in the stub mouse hook?
7= it appears that Cn2 uses the memory dubbed SEram in dcs7.inc, or address $86EC. saferam1 and 2 are untouched. The dcs pdf says that the GUI uses 73 bytes starting at AppBackupScreen. What is that?
NEW: Is Quittoshell a call, bcall, or jump? And what is a bjump? When would you use it?

4. I just use:

Code:
However, it's strongly recommended that you add a way to handle network activity by "clicking" on an invisible hotspot if incoming data appears. If you want to see a demo of that, I can share that too.

7. So CALCnet uses SERam, aka SavesScreen, which makes that unavailable. The Doors CS GUI (read about GUI Memory Areas also uses the first 129 bytes of AppBackupScreen, so you can use from offset 129 upwards.

NEW: Call or jump, doesn't matter which. A BJUMP is to a BCALL as a jp is to a call.

Sure, you can demo that...
Um, not familiar with interrupts, so why is im 2 / ei really necessary?

Again, the GUIMouse system, because of an oversight from myself, shuts off interrupts at one point, so it's important to set the interrupts back to mode 2 (the mode that CALCnet uses) and then enable interrupts again. This needs to be in a mousehook so that any time the GUIMouse routines turn interrupts off, the hook turns them on again.

Here's the sort of code I was talking about:


Code:

Hmm. I doubt I'd need to use this, other than the interrupt enabling and stuff. The only times I'd need to do this are when the connection is rejected because the "server" is full (in which case i really don't need to be checking buffers).
In every other case, I will simply use GUIRender, and Cn2_GetCSC to correspond.