Issues with setting properties of components at init time
Augustifolia opened this issue · 4 comments
Normally you can use SomeDirectGuiClass(component_parameter) to set a parameter of a component of some directGui element when you create the element. However this is not possible in some of the DirectGuiExtension classes (for example DirectCollapsibleFrame). This seems to be caused by initialiseoptions being called before the components are created. However just moving that function call will not always work because the functions from DirectGuiHelper are sometimes called when the components are created, which requires that initialiseoptions have been called.
One idea about how to solve this could be to use the frameSize instead of the DGH functions while creating the components. If anything has the wrong size thereafter, that could be updated at the end of the __init__ method with the correct size given by DGH.
What are your thoughts? Does this sound like a good solution or would you rather this be solved in some other way?
Hm, I guess in the case of the collapsible frame, this might work. And since this is only on the setup part, there may not be that much of a performance problem. So, if this approach works, we sure can go for it. It's important to have the extension widgets behave close to what one would expect when working with other direct widgets.
Do you know of any cases where we can't use the frameSize and should use DGH instead? As long as there is a default frameSize it seems to work fine to just use the frameSize, but I am not sure that it will always work.
The classes that require changes are:
- DirectCollapsibleFrame
- DirectDatePicker
- DirectScrolledWindowFrame
- DirectSplitFrame
There does however appear to be an issue with DGH.getRealRight. If you change the scale of the DirectDatePicker the position of the monthPicker will not be correct (if the scale is set at init time). However if the frameSize is used to calculate the position instead of DGH, the position will be correct.
I think it may have some problems when used in combination with the auto sizer widget and/or the box sizer which also use the DGH for positioning. Can't remember which but there were some standard widgets which haven't had the framesize set during placement if not explicitly set.
But that may be remedied if that function is called at the end as you proposed.
Alright, I just pushed a fix for this to #3.