Ok, here's what I'm on about


Code:

Block1:
//do a bunch of stuff here
ld   hl,0
push  hl
jp  MouseRender  ; this routine does not need a mousehook


Block2:
//do a bunch of stuff here
ld  hl,MouseHook
push  hl
jp  MouseRender  ; this routine needs a mousehook


MouseRender:
pop   hl
call GUIMouse  ; popping hl, rather than loading 0 into hl allows me to use this routine with or without a mousehook.
Yes, that would work, but why push and pop hl and then jp? Why not just call GUIMouse directly?
KermMartian wrote:
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:
Block1:
//do a bunch of stuff here
ld   hl,0
jp  MouseRender  ; this routine does not need a mousehook

Block2:
//do a bunch of stuff here
ld  hl,MouseHook
jp  MouseRender  ; this routine needs a mousehook

MouseRender:
call GUIMouse  ; popping hl, rather than loading 0 into hl allows me to use this routine with or without a mousehook.


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:
Block1:
//do a bunch of stuff here
ld   hl,0
call GUIMouse  ; this routine does not need a mousehook

Block2:
//do a bunch of stuff here
ld  hl,MouseHook
call GUIMouse  ; this routine needs a mousehook
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:

UsernameHook:
    ld  a,3
    call    GUIFindThis
    add hl,8
    push    hl
    ld  a,2
    call    GUIFindThis
    add hl,6
    push    hl
    pop de
    pop hl
    ld  b,8
check: 
    ld  (hl),a
    ld  (de),b
    and b
    jr  pushuserbutton
    djnz    check
    bit (ButtonFlag),1
    call  z,popuserbutton
    ld  a,%00000000
    xor (ButtonFlag)
    ld  (ButtonFlag),a
    ret

pushuserbutton:
    ld  a,GUIRButtonText
    ld  hl,UsernameSubmitButton
    ld  de,UsernameSubmitButtonEnd-UsernameSubmitButton
    call    PushGUIStack
    set (ButtonFlag),0
    ret

popuserbutton:
    call    PopGUIStack
    ret
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:
;#####################
;Change Username
;#####################
;
;Allows you to change your username:
;

Username:
    ld  b,4
    call    PopGUIStacks
    ld  hl,ChangeUsernameData
    ld  de,saferam2
    ld  bc,ChangeUsernameDataEnd+1-ChangeUsernameData
    ldir
    ld  de,saferam2+6
    ld  hl,Username
    ld  bc,8
    ldir
    ld  de,saferam2+6+9
    ld  hl,Username
    ld  bc,8
    ldir
    ld  hl,saferam2
    call    PushGUIStacks
    ld  hl,UsernameHook
    call    GUIMouse

ProcessUsername:
    ld  a,3
    call    GUIFindThis     ;returns the current input username's GUI entry
    add hl,8                ;points 'hl' to the start of the current username
    push    hl              ;saves 'hl' to the stack
    ex  hl,de               ;puts 'hl' into 'de'
    ld  a,0
    ld  b,8
    ld  hl,0
checksum:                   ;checksums the current username
    ld  (de),c              ;if the checksum equals $00,
    add a,c                 ;then we call GUIMouse again to force another username
    inc de                  ;if not, then we have to check for a change
    djnz    checksum
    cp  0
    call    z,GUIMouse
    pop de
    ld  a,2
    call    GUIFindThis
    push    hl
    push    de
    add hl,6
    ld  b,8
checksamenames:             ;compares the current username with the old one, byte by byte
    ld  (de),a              ;after encountering one change, it moves to 'finishcheck'
    ld  (hl),c              ;increases 'hl' and 'de'
    cp  c                   ;repeats until 'b' is 0
    jr  nz,finishcheck      ;if 'b' reaches 0, then we recall GUIMouse, to force a different input
    inc de
    inc hl
    djnz    checksamenames
    ld  hl,0
    call    GUIMouse
finishcheck:                ;if both the checksum test and the difference tests are passed
    pop hl                  ;overwrite old username with new one
    ld  de,Username
    ld  bc,8
    ldir
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 Smile)
Doors CS points some of its own pointers into the GUIstack, so unfortunately those would get broken too. Smile So yeah, not recommended. Very Happy
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. Smile 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?
ACagliano wrote:
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:
MouseHook:
    im 2
    ei
    ret
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. Wink
KermMartian wrote:
ACagliano wrote:
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:
MouseHook:
    im 2
    ei
    ret
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.



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:
MainMouseHook:
   im 2            ;because GUIMouse APD sets IM 1
   ei

   ld a,$ff \ out (1),a
    ld    a,$fd   ;group for ENTER
    out (1), a
    nop \ nop   ;let the keyboard settle
    in    a,(1)
   cp    dkClear
   jr z,clearpressed

   ld   a, ($86F9)      ;any incoming pending CALCnet data?
   or a
   ret z
MouseHookClickReceive:
   ld a,(Cn2_Int_RecBuf+7)
   ;Check if it's something we care about!
   cp $02            ;message 2 is whatever
   jr nz,MouseHookClickReceiveClear   ;if not, don't handle it
LetTheGamesBeginPop:
   ld hl, MouseY
   ld (hl), 3
   inc hl
   ld (hl), 102
   pop hl
   ret
clearpressed:
   ld hl, MouseY
   ld (hl), 2
   inc hl
   ld (hl), 91
   pop hl
   ret
MouseHookClickReceiveClear:
   ld hl,0
   ld (Cn2_Int_RecBuf+5),hl
   ret

[...]
;GUI definitions:
ReceivedRequestHS:
   .dw 6+3
   .db GUIRHotspot
   .db 100,-8,8,8
   .dw ReceivedConnRequest
;...
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.
  
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
Page 3 of 4
» All times are UTC - 5 Hours
 
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

 

Advertisement