Do windowlists have a default or minimum height?

[Minty23185Fresh]

In order to better understand <anchored> I have been hacking away at the anchors for the windowlist in masterindex. I have been able to shrink and manipulate the windowlist as desired except for the height. Is there some sort of default height?

Intuitively it would seem as though the height of the subwindows (a.k.a <child>) could determine a minimum height for the list. For instance, if the list item (subwindow) height was 20 and one could specify a minimum number of visible subwindows, say 5, then it would follow that the minimum list height would be 100. But I can't find mention of a minimum number of subwindows either?

In case you want the code, I have taken this:


<template name="masterindex_list">
<windowlist name="list">
<anchored to="contentanchor">
<top anchor="bottom" relation="relative" offset="20" />
<left />
<right />
<bottom parent="bottomanchor" anchor="top" relation="relative" offset="-70" />
</anchored>


to this:


<template name="masterindex_list">
<windowlist name="list">
<anchored>
<top parent="contentanchor" anchor="bottom" relation="relative" offset="20" />
<left anchor="left" relation="absolute" offset="30" />
<size width="100" height="100" />
</anchored>


The modified code throws the following warning:
Ruleset Warning: window: Anchored static height ignored for control (list) in windowclass (masterindex)

Which is actually obvious since the height of the windowlist isn't changing. But to me, not obvious why.

The dialogs go from the panel on the left to the panel on the right in the screenshot below.
21531

[Bidmaron]

Minty, anchoring is still just a mystery to me. I wish I knew the answer.

[celestian]

This is one reason I seriously hope that FGU will have (eventually) a visual build tool for stuff like this. I seriously hate trying to get all the gidgets and doodads lined up and where I want them.

[Moon Wizard]

This does not have anything to do with fiddly behavior, and a visual builder would not help in this scenario (since the issue is multiple dynamically sizing control types from top and bottom). It has to do with how the master index window was designed.

The masterindex_window.lua script specifically sets the bottom anchor dynamically, based on the number of filters defined for the record type. So, the bottom anchor will always be set by the Lua script, no matter how the template or control definition is changed. The initial anchor in the template is only defined as a starting point for reference and to prevent any initial layout errors.

This is the source of your issue. If you want to override this behavior, you will also have to override the Lua script for the masterindex window, as well as the template definition for the list.

The masterindex window has a lot of moving parts and customizations, and really wasn't meant to be "extended". You are probably better off replacing whole definitions (windowclass, template, etc.) and whole script files, than by trying to insert bits and try to jury rig the existing parts to still work. You'll save yourself a lot of "why" scenarios, since your code is then fixed and you can replace parts wholesale as you need. Up to you though.

Cheers,
JPG

[Bidmaron]

MW, thanks for your explanation.

As you can see from the screen shot, I have successfully modified it to provide the import/export buttons and the generator button. I have also gotten the export icons into the rows successfully. It took a lot of goobering, and I doubt it will win any code elegance awards, but it worked. If anyone is curious, I'll try to remember where I did everything (yeah, I know it was only a week ago, but so what?) and post some code here. MW helped me get the export icons right (yes, I know the icon is for import and not export. I have to fix that, but I hate making graphics, so I'll get around to it)

Screen shot of buttons added to the top (a lot easier to do than what Minty wants to do):
21537

Screen shot of export icons on individual rows:
21538

[Minty23185Fresh]

I think Bidmaron's extension here is a perfect example of why I would not want to do wholesale replacement. Users would be placed in an either or situation. Either use my extension, or Bidmaron's extension. That in my mind is unacceptable. If one of our extensions is a bit more popular the other will be pushed to obscurity. I have a knack for rolling 1's, so that would be me. I'll do the work up front, planning for the "automatic miss".

Thanks Moon Wizard. I'm sure you're getting tired of us and would like to field somebody else's questions for a while. Thanks for you patience!

[Minty23185Fresh]

Oh, and I forgot: Moon Wizard, thank you very much for your explanation of lua's outside influence on the situation. My understanding of the XML appears to be sound, which is what I was hoping to gain via my experiment. Had I had the confidence to believe I knew what I was doing, then I might have gone looking elsewhere before throwing in the towel and asking for help.

[Bidmaron]

Minty, I am not convinced our extensions won't work together. I am only overriding the master index for generators and tables, and I don't think you are doing anything that will not work right alongside what I am doing. The beauty of FG interface design is that unless we are both affecting the exact same controls (which I don't believe we are), everything should just automagically work.

My major surgery is in the tables and generators windows, which you are not monkeying with.

Those master index changes I posted should work fine with what you are doing.