Table Questions

[Bidmaron]

I am working on a table extension and am coming across a few things that I don't understand even after all my time with FG. First, within the record_table.xml file of the CoreRPG ruleset, there is the following sub window declaration within the main table window definition:

<subwindow name="tablecolumnheaders">
<anchored>
<top parent="columnanchor" anchor="bottom" relation="relative" offset="7" />
<left />
<right />
</anchored>
<class>table_column_headers</class>
<fastinit />
<activate />
</subwindow>

When I go to subwindow (and its inherited widow control) in the ruleset reference wiki, the fastinit tag "If specified, instantiate the windowinstance when this control is created. Otherwise, the windowinstance will not be instantiated until control is drawn on screen." The activate tag "If specified, show the control. By default, the control is hidden."

So, why are these tags necessary? The activate ensures the column headers are visible, so why the fastinit? Similarly, if the two tags were eliminated, when would the table headers not be visible? If the user minimizes the window, it wouldn't be, but by then everything is initialized. I get the sense I'm missing something important here, but maybe not?

[Moon Wizard]

Subwindows controls are also used to implement tabbed windows, by having a tab control template and a number of subwindow controls to match. Instead of having all the subwindows initialize at once (and thus be slow to open), only the first tab is initialized when it is set active.

If you end up using a subwindow control for a dynamic grouping scenario like the table column headers, and the subwindow will always be shown, you can force the contained window to be initialized before onInit is called for the control and parent window. Otherwise, the window won't exist during the control and parent window onInit, and will be created when FG tries to draw the window.

If I were to redo this window, I would probably just create/destory table column header controls, instead of using a subwindow.

Regards,
JPG

[Bidmaron]

Ah, thanks. As I suspected, I was missing something important. Another design question that results in some difficulty using the code:

You made the subwindow for table lines non-scrollable. This means that when you scroll on a long table, you lose the control to add a row and you have to scroll all the way to top to add a row. Is there any reason that subwindow couldn't be scrollable so the column headers and table controls stay in view and only the rows scroll?

[Bidmaron]

In the files list_textitem.lua and ct_effectlabel.lua there are routines onNavigateLeft and onNavigateRight that handle <Tab> and <Shift><Tab>. However, these routines are never explicitly invoked in the CoreRPG ruleset anywhere. Nor do the stringfield inheritance hierarchy have these defined. The only explanation I can come up with is the developer documentation is missing something?

(There are also onNavigateUp and onNavigateDown, but these are explicitly called in the ruleset)

On further looking there is also a onDelete, onDeleteUp, and onDeleteDown never called. These all look like important functionality, I just can't figure out what invokes these routines.

---edit---
nvm. I missed the inheritance from textbasecontrol virtual element, and it invokes all the routines I was missing.

[Moon Wizard]

The original tables code was written by a community developer, and added with permission; because it was a popular extension. I've thought about changing that too, but the header takes up quite a bit of room. Perhaps the edit buttons should be on the bottom in their own non-scrollable area. Not sure, most large tables are built using Par5E or via XML.

Regards,
JPG

[Bidmaron]

MW, I'd like to update it. Currently, I want to:
1. Fix the scroll issue
2. Fix where in edit mode you can use scroll wheel on column header to set individual column widths.
3. Fix rollon slash handler to change dice and offset so you can do what the settlement guy wants and roll different than standard table would want. Also you need to be able to manually control dice in a table. That way you can have lower values you don't normally see unless you have a negative modifier and higher values you don't see without a positive modifier.
4. Parse addition to where you can put something like [last] so adjacent columns can resolve using most recent die roll.
5. Change the <parcel> option to <encounter> if it is npcs you are rolling.

Any other table stuff need updating?

[Bidmaron]

I have a windowlist called "results" and I want to access the nth windowinstance in that list. How do I do that? I can loop through all of them with results.getWindow(), and I can get to next and previous instance with results.getNextWindow(currentInstance), but how do I get a single instance without looping through the getWindow results? I think the answer is results[n]?

Another related question is the dimensions of a multi-column windowlist. I can control the dimensions of each column with windowlist.setColumnWidth(value), but if I use setWidth of a windowinstance can I override the constant width setting of the windowlist itself or is a multi-column window list always constrained to equal width columns?

[Moon Wizard]

To grab the nth window in a list, you need to call windowlist.getWindows(), and then use [n] with the return value. If you want only visible windows (i.e. filtered list), then call windowlist.getWindows(true).

The multi-column windowlist is always constrained to the column values listed. If you make your child window instances bigger than the column width, then they will actually overlap on the screen which makes it really hard to interact with them.

Regards,
JPG

[Bidmaron]

Thanks