Can you change anchor points in onInit()?

[SilentRuin]

Is it possible to add or subtract x,y cords to XML named controls In an onInit() function?

Seems I’d have more flexibility as opposed to my current method of overriding them in XML with adjusted anchor points.

[Trenloe]

Have a look at the windowcontrol API reference in the Wiki. Look at setAnchor, setAnchoredWidth, setAnchoredHeight or setStaticBounds: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4162011/windowcontrol

Note that you can usually do most of what is possible using normal XML properties. If you're inserting or removing controls, look at using relative anchoring - this is specifically designed to allow dynamic resizing. More info here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4063439/Ruleset+-+Interfaces+Windows+Panels+Widgets#Anchoring

[SilentRuin]

Have a look at the windowcontrol API reference in the Wiki. Look at setAnchor, setAnchoredWidth, setAnchoredHeight or setStaticBounds: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4162011/windowcontrol

Note that you can usually do most of what is possible using normal XML properties. If you're inserting or removing controls, look at using relative anchoring - this is specifically designed to allow dynamic resizing. More info here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4063439/Ruleset+-+Interfaces+Windows+Panels+Widgets#Anchoring

Unfortunately, the way character sheets are defined you have to redo them to take advantage of relative anchoring - which currently they are all hardcoded in the places I need to move (at least in 5e). I'd also prefer to try (maybe not possible to do what I want we'll see) to force my gap in programmatically (your first suggestion) for the space I need and also to make it optional depending on active states and host/player display version of the sheet.

But your tip gives me the hint I needed to experiment with, so thanks. Worst case scenario I end up working with what I've currently got overriding XML in the XML.

[SilentRuin]

Have a look at the windowcontrol API reference in the Wiki. Look at setAnchor, setAnchoredWidth, setAnchoredHeight or setStaticBounds: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4162011/windowcontrol

Note that you can usually do most of what is possible using normal XML properties. If you're inserting or removing controls, look at using relative anchoring - this is specifically designed to allow dynamic resizing. More info here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4063439/Ruleset+-+Interfaces+Windows+Panels+Widgets#Anchoring

I'm having trouble finding the window for the controls I want to change. The issue is that I want to do this when my window has an onInit.

But at that level I'm on the 'charsheet' window class level, and the actual things I want to change anchor points on are in 'charsheet_main' class level. I can't seem to find the window 'charsheet_main' (buried in tabs?) nor can I find the actual controls under it which are really what I'm after. I'd add onInit to the controls themselves but some already have logic for that and I really don't wish to override and copy them - just want to change the anchor points and disturb that code as little as I possibly can.

I've tried the Interface.findWindow code - trying to guess what I need to give it and no luck. I'm also at the window (charsheet.<specific ID>) and can directly access windows using raw text up to window.tab.tabs[1] - then I get totally lost and can't get past that level guessing at additional text. If you have any lesson or pointer on how to find windows buried in a charsheet window under charsheet_main windows class I'd like to know.

Thanks for any info you can pass on.

[Trenloe]

I can't seem to find the window 'charsheet_main' (buried in tabs?) nor can I find the actual controls under it which are really what I'm after.
What can't you "find"? What are we referring to there? The "charsheet_main" windowclass definition in the FG XML? Or the windowinstance within LUA code?

"charsheet_main" is defined in campaign\record_char_main.xml and has a <script> section (which is where you could run onInit code from).

To get at the windowinstance from outside of it's scope, you can use something like window.main.subwindow (I haven't tested this). Some info here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4129259/subwindow

[SilentRuin]

What can't you "find"? What are we referring to there? The "charsheet_main" windowclass definition in the FG XML? Or the windowinstance within LUA code?

"charsheet_main" is defined in campaign\record_char_main.xml and has a <script> section (which is where you could run onInit code from).

To get at the windowinstance from outside of it's scope, you can use something like window.main.subwindow (I haven't tested this). Some info here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4129259/subwindow

Per the context of the discussion and the statements previously - in the lua code.

I'm handed the window for charsheet as I stated. Then:



Debug.console(window);
-- WINDOW = { class = charsheet, node = charsheet.id-00001, x,y,w,h = 658,241,525,620 }

Debug.console(window.main);
-- CONTROL_CONTAINER = { name = s'main', x,y,w,h = 15,89,0,0 }

Debug.console(window.main.charsheet_main);
-- nil

Debug.console(window.tabs.tab[1]);
-- { s'icon' = { #1 = s'tab_main' }, s'subwindow' = { #1 = s'main' } }

Debug.console(window.tabs.tab[1].charsheet_main);
-- nil


As you can see from above results I can't find the charsheet_main which has my results (keeping in mind I have XML overrides of its anchor points per past conversation - just want to do this in the code instead). I can find parts leading up to it but I'm lost how to get up to the actual window that will allow me to reference controls and set anchors in the code from where I'm starting.

Calls to


Interface.findWindow ("charsheet_main", <lots of failed tries at field here> );


Also just got nill back. As I stated I am at the charsheet window level for the particular displayed sheet when I enter this onInit I'm trying to do all this in. I just don't understand the syntax to get where I want to go. Usually its dead simple - I'm at the window I want to be in - or I have a straight shot at it with no issues. Not so in tab land.

[Trenloe]

As you can see from above results I can't find the charsheet_main which has my results (keeping in mind I have XML overrides of its anchor points per past conversation - just want to do this in the code instead).
Have you tried what I suggested? window.main.subwindow

EDIT: See the subwindow link I provided above, the descriptive text includes: "A reference to the contained windowinstance object is available from the script environment of the parent subwindow control through the variable subwindow." It also mentions "Using the positioning and sizing functions for the contained windowinstance may have unpredictable results." so keep that in mind - see the paragraph after for recommendations.

"charsheet_main" is the windowclass used to create a windowinstance, but it is not the name of the windowcontrol/variable containing that instance.

[SilentRuin]

Have you tried what I suggested? window.main.subwindow

EDIT: See the subwindow link I provided above, the descriptive text includes: "A reference to the contained windowinstance object is available from the script environment of the parent subwindow control through the variable subwindow." It also mentions "Using the positioning and sizing functions for the contained windowinstance may have unpredictable results." so keep that in mind - see the paragraph after for recommendations.

"charsheet_main" is the windowclass used to create a windowinstance, but it is not the name of the windowcontrol/variable containing that instance.

Added below...


Debug.console(window.main.subwindow);


Came back nil.

Is there a way to just print out every window member? For sure that would be an awesome debug tool if nothing else.

I suppose I can go to the actual control I want - yank out that window - then... I can I go back one window like I do in DB searches? Where I just use ".." or XPATH stuff like that?

[Trenloe]

Try main.subwindow

[SilentRuin]

Try main.subwindow

nil.

I really appreciate your help here as you've forced me to trial and error trying to avoid this altogether.

The thing I love about snipe hunts, is you learn stuff by trying to find the unfindable.

window.main.setAnchor("top", "name", "bottom", "relative", 45);

That actually saves me all my XML multiple overrides and I no longer care how to find the guys I was overriding. Why? Because sub_charsheet is a template.

And now that I realize that - I found it and saw where I could do all I wanted in the above statement. Which once again, reaffirms my fiery all consuming hatred of templates :( May I never make my code so unreadable in the name of re-usability!

So thank you again for forcing me to think outside the box I trapped myself in.

And the thing I hate about snipe hunts?

AHHHHHHHHHHHHHHHHHHH!!!!!!!!!

That about sums it up. Thanks again :)

[Trenloe]

Glad you found a way forward. :)

[SilentRuin]

Glad you found a way forward. :)

Just as an FYI - I had to still try and solve finding a control via a window. In the end I could only manage to do it when I had a <script> at the level the controls were defined as that was only place they were automagically added into the window.<control name>. Any other script location this was not done and I never did find out how to grab them when given a window XML was down toward the root of things. I ended up putting the global onInit inside one of the controls because I was able to access lower things in the XML toward the root (below where I was) by simply doing window.parentcontrol.window type of operations.

Kind of a pain to have to program from the top down, instead of the other way, but I could never solve it starting at window.charsheet.

Just FYI to round out the information - and if anyone ever can tell how to access things wherever one may be in the window XML chain of things (not the DB - that's easy).

[Trenloe]

Another issue you're probably be running into is that all of the GUI is not initiated at the time you're running the code.

See this comment in the subwindow Wiki entry: By default, the windowinstance object will not be instantiated until the control is visible on screen. (See fastinit tag below)

https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4129259/subwindow

Adding <fastinit /> to the subwindow definition in charsheet:

<sub_charsheet name="main">
<class>charsheet_main</class>
<fastinit />
</sub_charsheet>

Makes main.subwindow and (for example, the level control in the main subwindow) main.subwindow.level accessible at the top level.

For example: in the onInit of the "charsheet" windowclass:


Debug.console("main = ", main);
Debug.console("main.subwindow = ", main.subwindow);
Debug.console("main.subwindow.level = ", main.subwindow.level);


Gives the following when the PC sheet is first opened. Without fastinit main.subwindow is nil.

Runtime Notice: Reloading ruleset
Runtime Notice: s'main = ' | subwindow = { x,y,w,h = 15,89,0,0 }
Runtime Notice: s'main.subwindow = ' | windowinstance = { class = charsheet_main, node = charsheet.id-00003, x,y,w,h = 712,329,108,430 }
Runtime Notice: s'main.subwindow.level = ' | numbercontrol = { value = #0, x,y,w,h = 0,0,0,0 }


WARNING! I would not make all the charsheet subwindows use <fastinit /> I did this in the PFRPG2 ruleset and had a lot of issues with incorrect data across the subwindows. I'd recommend you put any code within the onInit of the individual subwindows (the windowclasses within the subwindows) and not within the code of the top level window (charsheet in campaign\scripts\char.lua - don't put them here).

[SilentRuin]

Another issue you're probably be running into is that all of the GUI is not initiated at the time you're running the code.

See this comment in the subwindow Wiki entry: By default, the windowinstance object will not be instantiated until the control is visible on screen. (See fastinit tag below)

https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4129259/subwindow

Adding <fastinit /> to the subwindow definition in charsheet:

<sub_charsheet name="main">
<class>charsheet_main</class>
<fastinit />
</sub_charsheet>

Makes main.subwindow and (for example, the level control in the main subwindow) main.subwindow.level accessible at the top level.

For example: in the onInit of the "charsheet" windowclass:


Debug.console("main = ", main);
Debug.console("main.subwindow = ", main.subwindow);
Debug.console("main.subwindow.level = ", main.subwindow.level);


Gives the following when the PC sheet is first opened. Without fastinit main.subwindow is nil.

Runtime Notice: Reloading ruleset
Runtime Notice: s'main = ' | subwindow = { x,y,w,h = 15,89,0,0 }
Runtime Notice: s'main.subwindow = ' | windowinstance = { class = charsheet_main, node = charsheet.id-00003, x,y,w,h = 712,329,108,430 }
Runtime Notice: s'main.subwindow.level = ' | numbercontrol = { value = #0, x,y,w,h = 0,0,0,0 }


WARNING! I would not make all the charsheet subwindows use <fastinit /> I did this in the PFRPG2 ruleset and had a lot of issues with incorrect data across the subwindows. I'd recommend you put any code within the onInit of the individual subwindows (the windowclasses within the subwindows) and not within the code of the top level window (charsheet in campaign\scripts\char.lua - don't put them here).

Thanks - they already did (having started them from some ruleset code that already did that not through any foreknowledge on my part).

Everything I wanted in regards to making space and putting something in there on host, while only doing if a buttoncontrol is active on the player - works 'mostly'. My current issue is trying to figure out how to get the player sheets to react to the button press on the host without having to close them down and bring them back up (essentially force a refresh of the sheet).

I'm about to start looking at that, so if you happen to know a quick way to refresh a window so it "sees" what is currently in the DB (in this case setting of buttoncontrol maintains a status in my personal XML tag section of the sheet DB that needs to be respected), let me know.

But really I'm just starting to look - hoping its not some elaborate DB.hanlder or something I have to watch in both places - I'm looking for "magic" and "easy" :)

[Trenloe]

You'll need to use a field in the DB that the GM side can update and that the player side can get an onUpdate event triggered. If the state of the button press on the GM side is stored in the database this could be that field.

Usually you'll use DB.addHandler on the player side to register and onUpdate event handler. https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4063529/DB#addHandler

Search in the 5E ruleset files for DB.addHandler to see plenty of examples.

[SilentRuin]

You'll need to use a field in the DB that the GM side can update and that the player side can get an onUpdate event triggered. If the state of the button press on the GM side is stored in the database this could be that field.

Usually you'll use DB.addHandler on the player side to register and onUpdate event handler. https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4063529/DB#addHandler

Search in the 5E ruleset files for DB.addHandler to see plenty of examples.

So no magic then. Ok, I already know how to do that as I've done that in other extensions - was hoping there was some bit of arcane stuff I was unaware of that just "did it for me".

Though I'm not sure I ever done the "onUpdate" when i've dealt with DB handlers. Assuming that is is just something hooked into the low level of the window - but I'll search for examples - thanks again!

[Oh that onUpdate I've definitely used thats just part of the handler. I'm looking for something to force the sheet to be redisplayed - unless that somehow does it?]

[Trenloe]

onUpdate will just raise an event - you'll need to trigger the GUI update within code that gets triggered by that event.

If the GM view and the player view are the same, and something gets done on the GM side when a button is pressed, and you want that to happen on the player side as well, then try to write your code that is attached to events that will happen on both sides. For example, tie the button state to a database field (use a buttonfield not a buttoncontrol) and then run code against onValueChanged not onButtonPressed - because onButtonPressed will only run on the side that pressed the button.

[SilentRuin]

onUpdate will just raise an event - you'll need to trigger the GUI update within code that gets triggered by that event.

If the GM view and the player view are the same, and something gets done on the GM side when a button is pressed, and you want that to happen on the player side as well, then try to write your code that is attached to events that will happen on both sides. For example, tie the button state to a database field (use a buttonfield not a buttoncontrol) and then run code against onValueChanged not onButtonPressed - because onButtonPressed will only run on the side that pressed the button.

Probably not expressing myself correctly. I have no issues with understanding onValueChanged vs onButtonPressed as I learned by "trial by fire" in designing my last extension. I also understand DB.addhandler and my function I kick off from it for the same reason (burned till I learned last time).

My issue is - when I'm popping into my callback - I need to insure the window itself, is redrawn. Physically redone. So far the current rabbit hole I'm down has me looking at trying to do the following in the callback where I'm trying to see how findWindow() works (no luck). Below is an example of my attempts to find the charsheet window sitting right under my face (no luck in syntax - doing something stupid).



local nodeChar = DB.getChild(nodeActive, "...");
Debug.console(nodeChar); -- something like charsheet.id-00001

local w = Interface.findWindow("charsheet", nodeChar);
Debug.console(w); -- nil

local w = Interface.findWindow(nodeChar.getNodeName(), "charsheet");
Debug.console(w); -- nil

-- other failed tries with findWindow()


I see lots of examples in code where this is working but I'm doing something stupid or not understanding the context. IF I can find the window sitting right in front of my face on the screen, then I can do something like this (I hope) to refresh the screen.



w.close();

local wRefreshed = Interface.openWindow("charsheet", nodeChar);
Debug.console(wRefreshed);



I actually tried to just use the openWindow() and it worked just fine bringing it up (or returning wRefreshed if already up). Which got me down another rabbit hole involving why it was not going through the onInit() code I had to add of one of my controls - which will probably result in moving that back to the windowclass containing them using



function onSubwindowInstantiated()
-- do stuff like I did in onInit() of control
end


WHICH of course gets me FULL CIRCLE back into trying to access the window controls via window.... syntax.

I suspect some of the magic of adding window.[control_name] logic is messing me up because I'm doing something stupid - but at this point I'm down one to many rabbit holes.

Learning lots - but ugh... I feel like I'm going around in circles slowing coming into some sort of solution which I've not found yet.

That's the best I can explain it.

[Trenloe]

Recheck the Wiki documentation on script scope: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4128914/Ruleset+-+Scripting#Script-Block-Scope

Specifically "parentcontrol" - search for that in the 5E ruleset and see how it's used to navigate up the GUI hierarchy.

And, always remember where you're running code. Your idea of w.close and then re-opening the window won't work if your code is running in the window - because closing the window will close that script block scope. And closing something like the character sheet and re-opening just to refresh is very inefficient, especially for complex window hierarchies like the character sheet.

To take a step back from this... Good GUI design has the controls sourced on database fields. Unless the GUI state is temporary and doesn't need to be maintained across system restarts, or across instances. If you're dynamically building the interface, which I believe is what you're doing, then you'll need to have event handlers that trigger when something changes that results in updates being needed. If you have these event handlers at the GUI hierarchy level where you want to run code, then accessing the GUI structure through should be simplified.

[SilentRuin]

Recheck the Wiki documentation on script scope: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4128914/Ruleset+-+Scripting#Script-Block-Scope

Specifically "parentcontrol" - search for that in the 5E ruleset and see how it's used to navigate up the GUI hierarchy.

And, always remember where you're running code. Your idea of w.close and then re-opening the window won't work if your code is running in the window - because closing the window will close that script block scope. And closing something like the character sheet and re-opening just to refresh is very inefficient, especially for complex window hierarchies like the character sheet.

To take a step back from this... Good GUI design has the controls sourced on database fields. Unless the GUI state is temporary and doesn't need to be maintained across system restarts, or across instances. If you're dynamically building the interface, which I believe is what you're doing, then you'll need to have event handlers that trigger when something changes that results in updates being needed. If you have these event handlers at the GUI hierarchy level where you want to run code, then accessing the GUI structure through should be simplified.

Yeah, those script blocks are what are killing me.

If I have a windowclass with a script in it - and simply call down into a function from it like the below example:

XML file


<windowclass name="blah">
<script>
function onInit()
MyStuff.InitThisThing()
end
</script>


The the InitThisThing code will have no access to getDatabaseNode() or any of the script block control names. Yet if I do this:



<windowclass name="blah">
<script>
function onInit()
MyStuff.InitThisThing(getDatabaseNode(), MyControlName)
end
</script>


Then magically I can access it. Yet I have no window available at all here like I do in a buttoncontrol script where I can just pass that in and get access to whatever I want. At the windowclass I literally have to pass everything I want access to into it.

I feel I'm missing something basic - but this seems to be the only way to get access to things at this level.

My code currently has the source coded to the controls - but you seem to forget I don't want those controls seen - nor do I want the gap I've created there - when the button is not active. Sure its in the host always - but on player side this is just normal old character sheet - until button hits and everything changes. To get that change instantly on the DB button update is what I'm missing - everything else works.

Having the anchor points reset and the visibilitly of my window controls reset is the goal. All at once. Which requires code to trigger that can call each of those things - which is where my trouble is (well, until I just discovered what I found above - which I've not worked through the implications of yet).

Gist being - its very confusing on when things are available in script block and when they are not.

[Trenloe]

Then magically I can access it.
...

I feel I'm missing something basic - but this seems to be the only way to get access to things at this level.
Nope, it's not "magic" that is how Global Script Packages work. They're global, their scope is global, it's not tied to any window or GUI control. So if you call MyStuff.Something (assuming MyStuff is a global script package) then you need to pass it all the information it needs to work with, for example a top level window instance or a top level database node, or whatever it needs to work with.



My code currently has the source coded to the controls - but you seem to forget I don't want those controls seen - nor do I want the gap I've created there - when the button is not active.
I'm not forgetting, it's just that it's very, very, very hard to follow what you're trying to do.

My recommendation would be to take a step back and spend some time reading documentation and learning more about script scope. Programming isn't "magic" (as you've said a few times) and expecting something to "magically" work is a recipe to failure sooner rather than later. From trying to help you in this thread it seems your approach is to flail around with code until something works. Sorry if that's not correct, but it's what it looks like. Whereas some people might get lucky with coding some simple things with that approach, it's really not a good idea. Few people enjoy reading documentation and teaching themselves, it's much for fun to write code and see it in action, but I really feel you need to take those steps to some education through reading rather than purely through trial and error.

[SilentRuin]

Nope, it's not "magic" that is how Global Script Packages work. They're global, their scope is global, it's not tied to any window or GUI control. So if you call MyStuff.Something (assuming MyStuff is a global script package) then you need to pass it all the information it needs to work with, for example a top level window instance or a top level database node, or whatever it needs to work with.



I'm not forgetting, it's just that it's very, very, very hard to follow what you're trying to do.

My recommendation would be to take a step back and spend some time reading documentation and learning more about script scope. Programming isn't "magic" (as you've said a few times) and expecting something to "magically" work is a recipe to failure sooner rather than later. From trying to help you in this thread it seems your approach is to flail around with code until something works. Sorry if that's not correct, but it's what it looks like. Whereas some people might get lucky with coding some simple things with that approach, it's really not a good idea. Few people enjoy reading documentation and teaching themselves, it's much for fun to write code and see it in action, but I really feel you need to take those steps to some education through reading rather than purely through trial and error.

Code I'm familiar working with has no "buried" intelligence like the script packaging. What you do - is what you get. Including XML. All this "script package" stuff is additional intelligence I've never had in things I've programmed with so, yeah. Magic. Especially, when all of the documentation assumes an underlying understanding of some of these things. New to LUA - new to "global script packages". Granted code is code, but really things people assume are "standard" in their worlds are really just specialized tools they are familiar with. And the language in documentation reflects that. These script blocks are "intelligent" with "rules" and underlying logic which is not evident to simply reading the code or the examples available. And don't get me started on the examples or comments within the code.

If it were not for helpful people like yourself, this would take forever to piece things together through documentation and existing code examples. Though that is indeed most of what I do to solve these issues.

Now that I understand "gobal" vs "local" script calls that makes some of the "magic" in the examples I've seen where they have access and I do not simply by the method I used to access LUA code - makes it clearer.

Thanks. I'll keep plugging away. I win in the end usually through pure perseverance. Though it may take me longer, I come out the other end with a deeper understanding having made most of the mistakes one can make.

[SilentRuin]

Pure stubbornness solved it :)

Thank you for being my sounding board on all this. For posterity, I record my solution.

By simply printing out every single possible keyword from the script block, I found "self" was the only window provided (though "parentcontrol" was there also - everything else was nil).

This was for an XML where the windowclass was buried in a subwindow.

Gist being this bit of pretend code shows my solution to get my window to be able to call my 'global' script and play nice with everything and keep everything on host and player side looking the way it should (chunks of windows displayed - or not displayed - real time):

This is all in the XML


<windowclass name="A">
<subwindow name="sub_A">
<class>B</class>
<activate />
<fastinit />
<invisible />
</subwindow>
</sheetdata>
</windowclass>

<windowclass name="B" >
<script>
function onInit()
local nodeChar = self.getDatabaseNode();
DB.addHandler(DB.getPath(nodeChar, "B.thing"), "onUpdate", onActiveUpdate);
Interface.onWindowOpened = onWindowOpened;
onWindowOpened(self);
end

function onClose()
local nodeChar = self.getDatabaseNode();
DB.removeHandler(DB.getPath(nodeChar, "B.thing"), "onUpdate", onActiveUpdate);
end

function onActiveUpdate(nodeActive)
ManagerThing.BActivated(self);
end

function onWindowOpened(w)
local sClass = w.getClass() or "";
if sClass ~= "A" then
return;
end
ManagerThing.BWindowManipulationStuff(self);
end
</script>


And I had access in my ManagerThing to all my controls by self.[control name] and could do whatever anchor or visibility stuff I wanted. And it instantly happened on player side when host hit button.

Huzzah for snipes! ;)

[Trenloe]

Great!

:D