GadgetExtra() / SetGadgetExtra()
BlitzMax Forums/MaxGUI Module/GadgetExtra() / SetGadgetExtra()
| ||
| This is a continuation of the discussion in the following thread: http://www.blitzbasic.com/Community/posts.php?topic=78024 jsp: SetGadgetFilter would be probably a good solution as we could attach it to a single gadget, where the OK Button works more in general... What i don't like about the SetGadgetFilter is, that it uses the gadget context field, which is of enormous help and may the reason it was not chosen. Best would be if the context field is completely free and another one is only used internally. SebHoll: Unfortunately, the context field in TGadget is there specifically for storing the parameter passed by SetGadgetFilter(). Perhaps you need a new GadgetExtra()/SetGadgetExtra() function pair? ;-) jsp: It's off topic now and i don't want to harvest this thread could you may put it in an extra one? Also to ask others what they think about it. Actually a GadgetExtra()/SetGadgetExtra() should have been there from the start (like for listitems), because now we have the problem with backward compatibility. My suggestion would be to take a new field for the SetGadgetFilter and a function pair as you suggested to set/get the context field. As skid approved that we can use it, probably a lot have it in use in their programs and changing only the filter for the TextField and the TextArea is much easier and would not hurt anybody. If you could implement it now with MaxGuiEx that would really be fine, because than there is an official way we can go. |
| ||
| 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. 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). |
| ||
| 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. That's of course correct. The idea behind my suggestion was just that the usage of all old code would immediately be ok and additionally accessible via the new function set, thus a smooth transition. It's just that the new proper place to store such object pointers would be in the extra field using the two new functions. I'm fine with this and it's 100% better than before. 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. You probably know that we suggest to every new MaxGui user Assari's great tutorials which makes a good use of it and that since more than 2 years, so it is probably wide spread... 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) No we shouldn't !! It's absolutely perfect, the way it is, but would be nice to access the new field also more oop like Button.GadgetExtra() and not only via the function (and doesn't break in the future;). |
| ||
| GadgetExtra() is part of the first command every one should have updated after synchronising MaxGui. I personnaly added those commands + GadgetExtra:Object(gad:TGadget)/SetgadgetExtra(gad:TGadget,obj:TObject) + GadgetObject:Object(gad:TGadget)/SetGadgetObject(gad:TGadget,obj:TObject) and an "extra:Object" field. ( gadgetExtra/GadgetObject are the same functions... ) For now, it could be great to finally have those commands in an "official" way. Like this, I won't have to update source every time I instal maxGui ^^. |
   |