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:


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.

I found two tiny bugs, but all in all it's good stuff. 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:


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:

Haha, Montuori