I'm not convinced... Yes it would have been better if they were there from the start (because of the equally useful item extra fields), but No, I don't think that the SetGadgetFilter() context field should've been used instead.
Even for those people who have decided to use it for their own purposes, the new extra field won't break that functionality - they can still access the context field in the same way. It's just that the new proper place to store such object pointers would be in the extra field using the two new functions. With all these tweaks I make to MaxGUI, I don't want to get in a position where the code makes even less sense than it does at the moment, and we are in serious danger of doing that by using fields for different purposes for which they were originally intended.
I'm sure it was made clear that people shouldn't access the TGadget objects directly to ensure compatability with future versions - although it's tempting sometimes, usually alternatives can be found such as using TProxyGadget instead.
I've had a look into the implementation and seem to have a cross-platform working solution - the drivers aren't really affected as it's an internal change inside MaxGUI.MaxGUI. As originally described, it simply entails having two new functions:
SetGadgetExtra() and GadgetExtra()
The only problem I can see is whether or not we should pass this value along with gadget events (which don't already use the EventExtra() parameter) - my thoughts are that we shouldn't as we shouldn't be confusing the gadget and event extra properties as they won't always be the same (e.g. treeview events).
Even for those people who have decided to use it for their own purposes, the new extra field won't break that functionality - they can still access the context field in the same way. It's just that the new proper place to store such object pointers would be in the extra field using the two new functions. With all these tweaks I make to MaxGUI, I don't want to get in a position where the code makes even less sense than it does at the moment, and we are in serious danger of doing that by using fields for different purposes for which they were originally intended.
I'm sure it was made clear that people shouldn't access the TGadget objects directly to ensure compatability with future versions - although it's tempting sometimes, usually alternatives can be found such as using TProxyGadget instead.
If you could implement it now with MaxGuiEx that would really be fine, because than there is an official way we can go.
I've had a look into the implementation and seem to have a cross-platform working solution - the drivers aren't really affected as it's an internal change inside MaxGUI.MaxGUI. As originally described, it simply entails having two new functions:
SetGadgetExtra() and GadgetExtra()
The only problem I can see is whether or not we should pass this value along with gadget events (which don't already use the EventExtra() parameter) - my thoughts are that we shouldn't as we shouldn't be confusing the gadget and event extra properties as they won't always be the same (e.g. treeview events).