0 Members and 5 Guests are viewing this topic.
The OS does not expose a very simple way to generate menus, which is why the feature does not exist. But if any assembly wizards want to provide the majority of a solution, I'll happily include it! That is, if I can fit it.
;Does anyone knows why it's actually required to change these flags for a menu ?
;<-- What does this line exactly does ?
;Is it always the case ? Does anyone know why ?
;What does this line does ?
Official Name: appCurWordSet to have the text cursor cover the entire token.
;There must be an easier way to do this.
ld hl, $8508 ld de, $8509 ld (hl), 0 ld bc, 127 ldir
The OS's all-input routines use the raw key scanning commands along with raw key hooks, so those latters must be saved before and restored after calling such BCALLs.
Port 6 controls the flash page currently mapped to $4000-$7FFF. I guess the BCALL maps another page to this zone, so the current page (retrieved with in a, (6)) must be saved in A for future restore. That's only supposition though.
As I said above, the BCALL may map a specific flash page to $4000-$7FFF, so there's no reason why it wouldn't write the answer to an equally specific page. Also, page 1 is not flash but RAM, actually the only memory allowing for write.
The job of textShadow is to hold a copy of the large-font chars that were on your screen before you changed context (by entering a menu for example).
There are two RAM pages ; page 0 is mapped in $8000-$BFFF and page 1 is mapped in $C000-$FFFF. Else you would have 16kb of RAM, not 32kb ! (although only 24 are usable). It's just that ChkFindSym returns DE > $BFFF and B = 0 if the variable is in page 1. That's why it says B=0 is RAM.
ld b, 1ld hl, $8006bcall(_LoadCIndPaged)ld h, 0ld l, c
I've been playing with this for a while now. It seems that, at least for simple menus, this should be totally capable. But one problem I've run into so far is that, if I move the cursor into and then out of the number entry field, the dialog glitches out. Does this happen for you too, and/or do you have any idea why this would be happening?
.dw $C0DE.dw routineStop-routineBegin ;size of the command.db $CF ;compatibility = all.db $E6, $00 ;token to match = menu.db $00 ;command type = inline.db $00 ;arguments count = zero.org $0000routineBegin: ex de, hl ;this is just for testingroutineStop:.dw $0000 ;no more commands
.ERROR#Axiom(TEST)Menu(
I'm not sure what shell you're trying to compile this for, but right now your shell compatibility byte is 0xCF = 0b11001111. That means that it's incompatible with applications and Axe fusion. If that isn't the issue, I can't say what the issue is by looking at that.
As for increasing the number of arguments allowed, I'll look into it. Although I had a quick glance at the Axiom parsing code and was absolutely clueless about how it even checks the number of arguments, so it might not be easy for me to figure out.
What assembler are you using ? The .org preprocessor instruction have different behaviors depending on assemblers.
.org physically moves PC, as in, if you do .org $+8, the final compiled program will effectively have 8 zero bytes in the middle. I don't think TASM can do anything else related to PC, so I strongly recommend you using another assembler. I use SPASM, whose .org directive works the way you intend it to.Download SPASM : http://wabbit.codeplex.com/releases/view/45088
Wait ! It works ! I don't know what it changed, but thanks !