Minty23185Fresh
December 12th, 2017, 23:46
As near as I can tell positional values had using getPosition() are relative values, relative to the parent. For example the positional values for a combobox within a subwindow (of a form) are relative to the subwindow, not the form and definitely not the application (FG).
This appears to be untrue for the subwindows, i.e. the windowlist items, of a windowlist. They appear to be relative to the application.
For those of you who have been watching my foibles as I add more and more functionality to my Field Filters for All Libraries extension, you'll probably want to skip this next section as I provide some history and setup for newcomers.
========== History and Setup ==========
The Field Filters for All Libraries extension (https://www.fantasygrounds.com/forums/showthread.php?40954-Field-Filters-for-All-Libraries) is rooted in the CoreRPG masterindex windowclass. The number of field filters per library varies, with the NPC library having the largest number. So many that some field filters were multi-purposed, and still the form took up the entire height of a standard FG environment.
To alleviate this real estate problem I implemented a scrollable windowlist object to hold the field filter controls. Users select filter values using an input text box or a dropdown combobox, depending on the field being filtered.
While attempting to implement the windowlist I came upon a problem with the dropdown list. The height and width of a combobox's dropdown list is limited by the size of it's parent window. In my case the height of the parent window containing the combobox (and dropdown list) is roughly the same size as the combobox. To escape this problem I create the dropdown list at form level rather than at window list subwindow level. More details can be found here (https://www.fantasygrounds.com/forums/showthread.php?41293-Combo-boxes-are-really-hard-emKay!).
========== Observing the Problem ==========
To recap, in my extension, the control / window layering is:
application, form, windowlist, windowlist-subwindow, combobox
As I prepared to publish the latest revision of my extension I noticed that if a form was repositioned on the screen the positioning of the dropdown list varied. So much so, that if the form was toward the bottom of FG, the dropdown was positioned off-form and was therefore invisible. Here's a screenshot (in all cases I was clicking the "Alignment" filter):
21718
In the left panel the form is at the top of the application. In the center panel I have repositioned the form about half way down the application window. In the right panel the form is at the top of the application window but I expanded it's height so that the "Alignment" filter was at roughly the same position as it is in the center panel (so that I might compare "apples to apples, so to speak).
Note the positions of the comboboxes when they appeared when I clicked the dropdown button. In the left and right panels they are in approximately the desired position, just a little above their corresponding combobox. Also note there are eight choices (one of which is blank) in each "drop up". In the middle panel the combobox is misplaced, and mis-sized. It is on top of the corresponding combobox and drops below, plus there are only three and one half fields to choose from. (It is chopped off at the bottom because it is falling outside its parent (the form).
There is a genericcontrol on the form that anchors some of the other controls. I put a red dot in the middle panel of the screen shot to indicate it's approximate position. The anchor's position on the form varies based on the controls' sizes above it but it remains in roughly the same relative position to my windowlist. I calculated where to place my form level "drop up" based on that anchor and the position of the activating combobox within the windowlist object.
========== Each Object's getPosition() ==========
I placed some Debug.console() commands in the combobox's button onClick() function and dumped the getPosition() values for each of the layered windows and controls. There are three groups of values shown below corresponding to each of the panels in the screenshot above.
Runtime Notice: s'Parent form position, size=' | #360 | #-15 | #450 | #450 | s'masterindex' | databasenode = { npc }
Runtime Notice: s'Form anchor position, size=' | #35 | #270 | #365 | #0 | s'listbottomanchor'
Runtime Notice: s'Windowlist position, size=' | #35 | #300 | #365 | #125 | s'list_customfilter'
Runtime Notice: s'Subwindow position, size=' | #395 | #360 | #365 | #25 | s'masterindexcustomfilteritem' | nil
Runtime Notice: s'Combobox position, size=' | #155 | #0 | #205 | #20 | s'filter_custom_value_Alignment'
Runtime Notice: s'Parent form position, size=' | #355 | #141 | #450 | #450 | s'masterindex' | databasenode = { npc }
Runtime Notice: s'Form anchor position, size=' | #35 | #270 | #365 | #0 | s'listbottomanchor'
Runtime Notice: s'Windowlist position, size=' | #35 | #300 | #365 | #125 | s'list_customfilter'
Runtime Notice: s'Subwindow position, size=' | #390 | #516 | #365 | #25 | s'masterindexcustomfilteritem' | nil
Runtime Notice: s'Combobox position, size=' | #155 | #0 | #205 | #20 | s'filter_custom_value_Alignment'
Runtime Notice: s'Parent form position, size=' | #360 | #-15 | #450 | #604 | s'masterindex' | databasenode = { npc }
Runtime Notice: s'Form anchor position, size=' | #35 | #424 | #365 | #0 | s'listbottomanchor'
Runtime Notice: s'Windowlist position, size=' | #35 | #454 | #365 | #125 | s'list_customfilter'
Runtime Notice: s'Subwindow position, size=' | #395 | #514 | #365 | #25 | s'masterindexcustomfilteritem' | nil
Runtime Notice: s'Combobox position, size=' | #155 | #0 | #205 | #20 | s'filter_custom_value_Alignment'
Analyzing these numbers, one can see that nearly everything is as expected except the position of the subwindow. E.g. the combobox, position is always the same within the subwindow. For the first two sets of data the anchor and windowlist are in the same position. In the third they are down the screen a bit because of resize, but they are still within 30 pixels of one another. The subwindow position is "erratic" or more accurately unexpected or inconsistent with the other controls.
========== Conclusion ==========
By looking at the absolute values of the positions of the subwindow in the middle and last sets of data I surmised that the
getPosition() function returns positional values relative to the application not relative to the parent windowlist
for each of the windowlist subwindows (a.k.a windowlist list items).
This is not consistent with the behavior of getPosition() for other controls and subwindows.
This might be the desired behavior, but at the moment it seems to me, to be perplexing as to why it would be.
I have released a new version of the Field Filters for all Libraries based upon this assumption, and things look to be going fine. Should I observe differently I'll revisit this post and correct it.
This appears to be untrue for the subwindows, i.e. the windowlist items, of a windowlist. They appear to be relative to the application.
For those of you who have been watching my foibles as I add more and more functionality to my Field Filters for All Libraries extension, you'll probably want to skip this next section as I provide some history and setup for newcomers.
========== History and Setup ==========
The Field Filters for All Libraries extension (https://www.fantasygrounds.com/forums/showthread.php?40954-Field-Filters-for-All-Libraries) is rooted in the CoreRPG masterindex windowclass. The number of field filters per library varies, with the NPC library having the largest number. So many that some field filters were multi-purposed, and still the form took up the entire height of a standard FG environment.
To alleviate this real estate problem I implemented a scrollable windowlist object to hold the field filter controls. Users select filter values using an input text box or a dropdown combobox, depending on the field being filtered.
While attempting to implement the windowlist I came upon a problem with the dropdown list. The height and width of a combobox's dropdown list is limited by the size of it's parent window. In my case the height of the parent window containing the combobox (and dropdown list) is roughly the same size as the combobox. To escape this problem I create the dropdown list at form level rather than at window list subwindow level. More details can be found here (https://www.fantasygrounds.com/forums/showthread.php?41293-Combo-boxes-are-really-hard-emKay!).
========== Observing the Problem ==========
To recap, in my extension, the control / window layering is:
application, form, windowlist, windowlist-subwindow, combobox
As I prepared to publish the latest revision of my extension I noticed that if a form was repositioned on the screen the positioning of the dropdown list varied. So much so, that if the form was toward the bottom of FG, the dropdown was positioned off-form and was therefore invisible. Here's a screenshot (in all cases I was clicking the "Alignment" filter):
21718
In the left panel the form is at the top of the application. In the center panel I have repositioned the form about half way down the application window. In the right panel the form is at the top of the application window but I expanded it's height so that the "Alignment" filter was at roughly the same position as it is in the center panel (so that I might compare "apples to apples, so to speak).
Note the positions of the comboboxes when they appeared when I clicked the dropdown button. In the left and right panels they are in approximately the desired position, just a little above their corresponding combobox. Also note there are eight choices (one of which is blank) in each "drop up". In the middle panel the combobox is misplaced, and mis-sized. It is on top of the corresponding combobox and drops below, plus there are only three and one half fields to choose from. (It is chopped off at the bottom because it is falling outside its parent (the form).
There is a genericcontrol on the form that anchors some of the other controls. I put a red dot in the middle panel of the screen shot to indicate it's approximate position. The anchor's position on the form varies based on the controls' sizes above it but it remains in roughly the same relative position to my windowlist. I calculated where to place my form level "drop up" based on that anchor and the position of the activating combobox within the windowlist object.
========== Each Object's getPosition() ==========
I placed some Debug.console() commands in the combobox's button onClick() function and dumped the getPosition() values for each of the layered windows and controls. There are three groups of values shown below corresponding to each of the panels in the screenshot above.
Runtime Notice: s'Parent form position, size=' | #360 | #-15 | #450 | #450 | s'masterindex' | databasenode = { npc }
Runtime Notice: s'Form anchor position, size=' | #35 | #270 | #365 | #0 | s'listbottomanchor'
Runtime Notice: s'Windowlist position, size=' | #35 | #300 | #365 | #125 | s'list_customfilter'
Runtime Notice: s'Subwindow position, size=' | #395 | #360 | #365 | #25 | s'masterindexcustomfilteritem' | nil
Runtime Notice: s'Combobox position, size=' | #155 | #0 | #205 | #20 | s'filter_custom_value_Alignment'
Runtime Notice: s'Parent form position, size=' | #355 | #141 | #450 | #450 | s'masterindex' | databasenode = { npc }
Runtime Notice: s'Form anchor position, size=' | #35 | #270 | #365 | #0 | s'listbottomanchor'
Runtime Notice: s'Windowlist position, size=' | #35 | #300 | #365 | #125 | s'list_customfilter'
Runtime Notice: s'Subwindow position, size=' | #390 | #516 | #365 | #25 | s'masterindexcustomfilteritem' | nil
Runtime Notice: s'Combobox position, size=' | #155 | #0 | #205 | #20 | s'filter_custom_value_Alignment'
Runtime Notice: s'Parent form position, size=' | #360 | #-15 | #450 | #604 | s'masterindex' | databasenode = { npc }
Runtime Notice: s'Form anchor position, size=' | #35 | #424 | #365 | #0 | s'listbottomanchor'
Runtime Notice: s'Windowlist position, size=' | #35 | #454 | #365 | #125 | s'list_customfilter'
Runtime Notice: s'Subwindow position, size=' | #395 | #514 | #365 | #25 | s'masterindexcustomfilteritem' | nil
Runtime Notice: s'Combobox position, size=' | #155 | #0 | #205 | #20 | s'filter_custom_value_Alignment'
Analyzing these numbers, one can see that nearly everything is as expected except the position of the subwindow. E.g. the combobox, position is always the same within the subwindow. For the first two sets of data the anchor and windowlist are in the same position. In the third they are down the screen a bit because of resize, but they are still within 30 pixels of one another. The subwindow position is "erratic" or more accurately unexpected or inconsistent with the other controls.
========== Conclusion ==========
By looking at the absolute values of the positions of the subwindow in the middle and last sets of data I surmised that the
getPosition() function returns positional values relative to the application not relative to the parent windowlist
for each of the windowlist subwindows (a.k.a windowlist list items).
This is not consistent with the behavior of getPosition() for other controls and subwindows.
This might be the desired behavior, but at the moment it seems to me, to be perplexing as to why it would be.
I have released a new version of the Field Filters for all Libraries based upon this assumption, and things look to be going fine. Should I observe differently I'll revisit this post and correct it.