If this is the wrong way (as it doesn't seem to work), can somebody tell me the correct way to get the SpeedButtonNode pointer for the button that was just clicked on?
Hmm, well that proves that it isn't getting the SPEEDBAR_SelectedNode property.
What's confusing me is that the autodoc states that SPEEDBAR_SelectedNode applies to OM_NOTIFY only. This explains why GetAttr is failing, but how do I get the info from an OM_NOTIFY attribute?
In order to get OM_NOTIFY updates in your application you need to set the gadget's ICA_TARGET to ICTARGET_IDCMP so that it sends them IDCMP_IDCMPUPDATE messages to your window's UserPort and then use an IDCMP hook to catch the messages if you're using window.class.
What I would probably do instead of doing this and using SPEEDBAR_SelectedNode as it seems unreliable is probably to just put all the speedbar button nodes in an array with the speedbar button ids as indexes. In fact I've already done that in a program except it was for a slightly different reason.
Do you have first-hand experience of it being unreliable? If so I'll do an array as you suggest (actually I'll probably just chuck my userdata in the array instead), otherwise I have other things using ICA_TARGET so it's no hassle to do it using that method.
Do I have experience with the tag? No, not really. If you already have IDCMP_IDCMPUPDATE handling then go ahead and try it.
IDCMP_IDCMPUPDATE is just something I generally try to avoid as it tends to generate a lot of messages that fill up your windows' IDCMP port and also requires installing a special IDCMP hook with window.class.
Well, the IDCMP_UPDATE handling isnt weird at all. It was invented for very special and rare cases of Intuition event handling, far away from simple gadget event handling.
What indeed IS weird is the fact that speedbar.gadget was taken over to OS4 completely unchanged. This gadget is a complete mess, and it is weird to manage (not to mention the handling of it. "Oversize" speedbar gadget are crude to handle for a user. I would NEVER use it. Instead I would make up my own).
In a normal case, it would have been abandoned in its current form and replaced by a gadget that is handling its internals like e.g. clicktab.gadget and relatives do.
These dont need an IDCMP_TARGET to tell what node of the gadget was clicked. Simply get the node number from a quite normal Intuition gadget message and resolve the appropriate node to get more information.
The only code I have that deals with speedbar is AWeb.
It used a convoluted IDCMP_UPDATE based approach which I couldn't quite work out. So I didn;t post about it. Just the more rigorous code for checking the GetAttrs results.
But if you looking aweb/window.c and aweb/event.c in the aweb source (on os4depot) there is code for handling the speedbar.
AWeb doesn't use a Reaction window for it main window though, so the code will require some changes.
search for 'userbutton' and 'speedbar' to find the right bits.
I've avoided speedbar.gadget up until now for the reasons you mentioned (and I was indeed expecting it to work like clicktab!). However, I wanted a dynamically-updateable button bar and speedbar seemed to fit the bill. It could do with an update though - the user interface issues definitely need fixing, and I'd like to see an option to display the image to the left of the text.
@broadblues
Thanks, I figured it out eventually. You have to use GetTagData in IDCMP_IDCMPUPDATE to retrieve the button node that was clicked.
Im glad you found a way to get the node, finally. I couldnt have been of help with this, as I rejected the use of speedbar.gadget as soon as I saw the weirdness of it.
Yes, speedbar.gadget should be fixed soon, because, as you pointed out, it could be of use in many programs.
Chris, the latest modification you are talking are related to NetSurf right ? If so there is a problem with latest build #688, after installed i changed the prefs according to my need (as usual) and then i click to save --> DSI
Quote:
Crash log for task "NetSurf" Generated by GrimReaper 53.5 Crash occured in module kernel at address 0x01815F9C Type of crash: unknown exception
These dont need an IDCMP_TARGET to tell what node of the gadget was clicked. Simply get the node number from a quite normal Intuition gadget message and resolve the appropriate node to get more information.
Only if you need the node pointer (the speedbutton ID is stored in the Code field of the IDCMP_GADGETUP IntuiMessage) and even then there are other ways, like simply going through the button list until you find the node with the right ID, or as I suggested earlier storing them in an ID indexed array and then retrieving the node pointer from there.