Windowlist Column Widths - Dynamically adjusting

[Zeus]

Hey All

I am working on updating my 4E Tables extension at the moment and have been looking to introduce variable table column widths based upon the current size of the window. This so that the table columns scale proportionally when windows are re-sized thus ensuring the table columns make use of all available window real estate.

The Table windows are dynamic in size and thus allow users control over resizing the window. I have all the main controls re-positioning and scaling in anchored width just fine, however I am having trouble with windowlists, in particular windowlists set to output from left to right as opposed from top to bottom, in other words windowslists with column based output using the <fillwidth> option.

Let me explain a little more.

- Each table implements a windowlist for the table's rows.
- Each row contains another windowlist for the row's column data.

The windowlist in each row (for the row's column data) is defined statically in XML and set for column based output with the <fillwidth> tag set.

Within LUA script I am detecting when the main window is resized and then triggering the re-positioning and scaling (width) of controls based upon the current windowsize.

My challenge: How to dynamically adjust the <width> of the columns of the windowlist.

1. There doesn't appear to be a method for changing this in LUA script. e.g. mywindowlistcontrol.setColumnWidth(colwidth).

2. I have tried updating the <width> definition by using the following statement in a LUA script:

mywindowlistcontrol.columns[1].width[1] = newcolumnwidth;

The latter works in so much that the <width> value is set, but the windowlist doesn't update to reflect the change.

Is there a way to force FGII to re-draw the windowlist thus using the new <width> value for the columns?

I am looking to the community for any suggestions or pointers as someone may have already figured this out before I raise a request for the devs to add a setColumnWidth(colwidth) method to the standard LUA API.

Anyone?

[Ikael]

I have been fighting similar issues before, but haven't found any good solution. One way to do this however, is to close and re-open your window on every window resized handler call. This, of course, is not good way to do it anyways, but I have used this close-reopen on making some re-rendering. Defenitely I would like to see better rerender supper in FGII.

[Zeus]

Ikael - I have used that approach in the past but have had mixed results.

In this case, I am pretty sure it wouldn't work as the onSizedChanged handler is continuously triggered during the drag operation of the window resize therefore having the window close and then re-open would interrupt the user re-sizing the window. I'm guessing it would also tax the FGII engine leading to potential performance hits.

I'd prefer a cleaner approach but I guess I may have to fall back to trying something like this if nothing else is doable. Thanks for the suggestion though.

[Stitched]

The base, underlying window handler code needs a major overhaul IMHO.

Who foresaw that people would own dual-monitors or massive LCD screens when FG first came out? Now with FG2, we are running it on everything from 10" netbooks to massive 27" Apple Cinema displays.

It's just strange to have things like the chat window, or other windows, not be allowed to expand to fill the "real-estate" if it's available.


Ikael - I have used that approach in the past but have had mixed results.

In this case, I am pretty sure it wouldn't work as the onSizedChanged handler is continuously triggered during the drag operation of the window resize therefore having the window close and then re-open would interrupt the user re-sizing the window. I'm guessing it would also tax the FGII engine leading to potential performance hits.

I'd prefer a cleaner approach but I guess I may have to fall back to trying something like this if nothing else is doable. Thanks for the suggestion though.

[Zeus]

The base, underlying window handler code needs a major overhaul IMHO.

Who foresaw that people would own dual-monitors or massive LCD screens when FG first came out? Now with FG2, we are running it on everything from 10" netbooks to massive 27" Apple Cinema displays.

It's just strange to have things like the chat window, or other windows, not be allowed to expand to fill the "real-estate" if it's available.

I don't believe FGII window API is at fault here for the above constraints. The window system does after all allow for windows to scale based upon the definition you provide and the frame, size and anchoring attributes.

The chatwindow though is not a regular windowclass/window. Its **special** in that it is defined as its own object type. Its this way I believe due to the special handling routines required to support dice handling and chat buffers. Still if the devs could tweak it to allow for more control - it would be nice.

I can live with its limits though, I run on a 27" Apple cinema display and all of the remaining desktop estate is usually consumed by game content e.g notes, sheets, maps etc. etc.

Anyhow a little off-topic.

[StuartW]

@DrZeuss

I think it looks like you need to petition for an API change. In my experience, trying to modify a control's behaviour by changing the tag values (such as columns[1].width[1]=...) isn't effective, and I'd guess that this is because the internal FG2 objects such as windowlists as created at load time by parsing the tags, but thereafter have separate identities from those tags.

The other problem with windowlists is that I think they are 'optimised' (in that they don't display the full behaviour set, as this would slow them down). It certainly used to be the case that entries in windowlists didn't respond to size changes very well for that reason.

I could be wrong though, but it is probably worth asking JPG.

Stuart

[Zeus]

StuartW - Cheers buddy, I suspected this might be the case.

JPG/DD - Any chance of an API update to include a setColumnWidth(colwidth) for windowlists?