Does anyone know, when I use
junk=rsrc_gaddr(type_tree,treeno,formaddr&)
to select a tree number, if I can use that formaddr& value to read back what tree number is actually selected ?
I could store "treeno" in a external variable and keep track of selected tree that way, but seems a little crap in storing the treeno externally, rather than just reading back from the tree address itself...
rsrc_gaddr read back selected tree ?
Moderator: troed
rsrc_gaddr read back selected tree ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
- thorsten.otto
- Posts: 148
- Joined: Mon Nov 04, 2019 2:20 am
Re: rsrc_gaddr read back selected tree ?
First off, i wonder why you need to do that? The tree number is usually only needed for rsrc_gaddr(), after that you just use the returned OBJECT tree pointer.
And no, there is no direct way to read the number back. You could loop over all the tree numbers in your resource, calling rsrc_gaddr() on them until you get back the same address, but storing just the number seems to be much easier.
Another option would be to not use rsrc_gaddr() at all, and fetch the array of tree pointers from the header of the resource file. It is available in the AES global array after a successfull rsrc_load() call.
And no, there is no direct way to read the number back. You could loop over all the tree numbers in your resource, calling rsrc_gaddr() on them until you get back the same address, but storing just the number seems to be much easier.
Another option would be to not use rsrc_gaddr() at all, and fetch the array of tree pointers from the header of the resource file. It is available in the AES global array after a successfull rsrc_load() call.
Re: rsrc_gaddr read back selected tree ?
It comes from another problem that when I have a tree like this.. (BH file)
Code: Select all
CONST BOOTROM%= 0
CONST ROMSELECT%= 2
CONST RADIO1%= 3
CONST RADIO2%= 4
CONST RADIO3%= 5
CONST RADIO4%= 6
CONST RADIO5%= 7
CONST BANK1INFO%= 8
CONST BANK2INFO%= 9
CONST BANK3INFO%= 10
CONST BANK4INFO%= 11
CONST MBROM%= 12
CONST RTC2%= 2
CONST RTCRESET%= 3
CONST YEARUP%= 6
CONST MONTHUP%= 7
CONST DAYUP%= 8
CONST SECSUP%= 9
EDIT: The only other way would be to disable the buttons somehow in each menu tree.. but that seems like a faff really.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Re: rsrc_gaddr read back selected tree ?
Or is there some better method to get button clicks ?
Currently I have to use..
FOB=objc_find(tree&,0,7,mx,my)
Where FOB will return the button clicked on, but it doesn't return which tree that button is on..
So if I have
FORM1 =0
BUTTON1 =0
BUTTON2 =1
FORM2 =1
BUTTON1 =0
BUTTON2 =1
FOB will return 0 or 1, but that click could be on FORM1 or FORM2.. hence the problem.
For the moment I will just use a global "treeitem" variable to store which tree I displayed on screen..
The code would then be:
If treeitem = FORM1 AND BUTTONPRESS = BUTTON0...
If treeitem = FORM2 AND BUTTONPRESS = BUTTON0...
I don't think its supposed to be done like that, but I cannot find any other way around the problem.
Currently I have to use..
FOB=objc_find(tree&,0,7,mx,my)
Where FOB will return the button clicked on, but it doesn't return which tree that button is on..
So if I have
FORM1 =0
BUTTON1 =0
BUTTON2 =1
FORM2 =1
BUTTON1 =0
BUTTON2 =1
FOB will return 0 or 1, but that click could be on FORM1 or FORM2.. hence the problem.
For the moment I will just use a global "treeitem" variable to store which tree I displayed on screen..
The code would then be:
If treeitem = FORM1 AND BUTTONPRESS = BUTTON0...
If treeitem = FORM2 AND BUTTONPRESS = BUTTON0...
I don't think its supposed to be done like that, but I cannot find any other way around the problem.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
- thorsten.otto
- Posts: 148
- Joined: Mon Nov 04, 2019 2:20 am
Re: rsrc_gaddr read back selected tree ?
But you are passing the address of the tree to objc_find(), so you certainly know which tree the button belongs to? There is no need to handle cases for any other object tree.