The far more responsible thing to do would be to back up the hooks you use, and restore them before exiting. And having your keyhook loader be an option somewhere.

A hook manager is in the works, which can do that stuff for you. It should be the OS's responsibility (or at least some other application), not yours.
I'm talking about the ON+prgm hook, which needs to be there outside (obviously)
Yes, that's what I meant by "keyhook loader", which I said should be optional.

I'm not telling you "don't chain hooks", I'm just throwing in my opinion and that someone else is doing that work anyway.
The way to do it (I think) is to save the previous one to the appvar and jump to it if prgm wasn't pressed (or something like that)
Yeah, that's how the hook manager is being written, so less work for Kerm is all I was getting at.
I'd be happy to do that, I agree it would be more responsible. Anyone got more info or sample code on hook chaining?
Alright.

When you go to install your hook, check to see if the bit is already set. If not, yay, no worries. If so, then...

Copy the 4-byte block for that hook (address, page, and page backup) into your appvar. Then install your own, which does this:

Save all registers. Look up your appvar and find the 4 bytes you saved. Use GetBytePaged or similar to get the first byte of the other hook, and make sure that it's 83h.

If it is 83h, then copy the 4 bytes to the 4-byte block, restore the registers, and call that hook. You can do this by using OffPageJump or similar. Then, once you've gotten control again, restore your own 4-byte block, and return if the hook you just called told you to. If not, do your own loader thing.

If it wasn't 83h, then just don't run it and do your own loader thing. You might also want to set some sort of flag in the appvar to not bother with chaining.

That was probably confusing, so here's the short version: when your hook gets called, restore the old hook and try calling it, then restore yourself and do your own thing.

I think I'm too lazy to write any code, but maybe you get the idea.

EDIT: Okay, I wrote it:


Code:

installMyHook:
   bit 5,(iy+34h)
   jr z,installRawKeyHook
   ld hl,sDCSAppVar
   rst 20h
   B_CALL ChkFindSym
   inc de
   inc de
   ld hl,9B84h
   ld bc,4
   ldir
installRawKeyHook:
   ld hl,myRawKeyHook
   in a,(6)
   B_CALL EnRawKeyHook
   ret
sDCSAppVar:
   DB AppVarObj,"DCS",0

myRawKeyHook:
   add a,e
   push af
   push de
   push bc
   push hl
   ld hl,sDCSAppVar
   rst 20h
   B_CALL ChkFindSym
   inc de
   inc de
   ex de,hl
   ld e,(hl)
   inc hl
   ld d,(hl)
   inc hl
   ld a,(hl)
   ld h,d
   ld l,e
   inc de
   ld (appBackUpScreen),de
   ld (appBackUpScreen+1),a
   B_CALL GetBytePaged
   ld a,b
   cp 83h
   jr nz,myRawKeyHookContinue
   pop hl
   pop bc
   pop de
   pop af
   ld ix,returnPoint
   push ix
   ld ix,appBackUpScreen
   push ix
   B_JUMP OffPageJump
returnPoint:
   ret z ;other hook said to ignore keypress
   jr $F
myRawKeyHookContinue:
   pop hl
   pop bc
   pop de
   pop af
$$:   
   cp kPrgm
   ret nz
   in a,(4)
   bit 3,a
   ld a,kPrgm
   ret nz
   ld hl,sDCS
   ld de,progToEdit
   ld bc,8
   ldir
   B_CALL ExecuteApp
sDCS:
   DB "DoorsCS6"


I didn't run this and it probably doesn't work perfectly, but hopefully it gets the point across.
Yay! Can't wait for 6.1 Beta 2. Cool
I found two tiny bugs, but all in all it's good stuff. Smile Sweet.
*super epic necro-bump* I recently re-visited this topic, and for some reason I'm struggling with hook chaining on the TI-84 Plus C Silver Edition. The following code returns to the right location (namely the initial value of ix) but on the wrong page (the target page, not the calling page). Without using (1) a fragile RAM-stored stub to restore ports $6 and $e or (2) complex code that find the pointer to __bank_call_ret and uses it, how can I make this a true off-page call?


Code:
   push ix ; Assuming ix = HookChainer_Continue
      ld ix,Op1 ; Op1 contains the address and page of the OPJ
      push ix
         bjump(_OffPageJump)
HookChainer_Continue:


Edit: "solved" thanks to Runer112 and IRC. The solution is a bit hacky, but because I have the address low, address high, and page in RAM already (in the first three bytes of OP1), and the OS tries to look up bcall vectors when bit 7 of the target is set by subtracting $4000. Therefore, bcall'ing OP1+$4000 will bcall the address and pointer stored in OP1! Credit to Runer112 for this cool trick.

Code:
   push ix
      bcall(OP1 | (1 << 14)) ; Op1 contains the address and page of the OPJ
      ret
Haha, Montuori
  
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 2 of 2
» 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