-
December 30th, 2019, 11:48 #1
Margin sizes doesn't seem to work with backcolor
I've been searching for a while now, and I can't find how to pad out the margins (i.e. the space between the edges of a control, and the text that it contains).
For example, "X" is something I want in this figure:
|XLabelXXX|
Instead I just get:
|Label|
The following applies margins:
Code:<anchored position="insideleft" height="15" offset="45,45,45,45" />
Do I need to use scripting with getSize() for this? Would that even expand the backcolor properly?
-
December 30th, 2019, 12:30 #2
Archangel
- Join Date
- Apr 2008
- Location
- Virginia Beach
- Posts
- 3,096
Warning: I am not dead and therefore somehow may not be reliable.
If you are trying to do this during window construction, getsize is not reliable unless you have a detailed understanding of the FG window construction process.
As others have tried to get you to do, the best way to do this is with a frame.
You are trying to do what most of us do with FG and try to make it work like we want instead of how it actually works. Why are you so wed to not using a frame? Surely the number of colors cannot be that high. If you want a border, stack two frames. Easy peasy.
Alternatively, you could use the preload construct for windows. At work now and cannot get to wiki to tell you the option but there is a switch you can set in your window to prebuild it. Cannot remember it’s name. However, it comes with its own baggage if you use it (can’t remember the particulars).
I am not sure why I am even replying as if you don’t treat us humans any better you may never see another reply here.
If you don’t put your size in attributes but use actual tags for them, you can also directly read the xml window definition to get the sizes. This is how I do it in my (non working at the moment due to updates in 3.7.7 which I haven’t had time to address) generators extension. Look there for bracketed array references to the size tags if you want to see how it is done during initialization of Windows and controls. That won’t work however if the control has any dynamic sizing features.
The last thing you can do is take the top level window onInit (which runs last after controls created unless you use the preload flag I mentioned) and have it call a routine to do the sizing of selected controls. I think I might also use that technique in generators extension.
Comment removed because Trenloe is right. I apologize.Last edited by Bidmaron; December 30th, 2019 at 13:12.
-
December 30th, 2019, 13:04 #3
Please try to keep it civil. If you can’t reply without being insulting then please don’t reply at all.
Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!
-
December 30th, 2019, 13:44 #4
I was under the impression that that "windowcontrol" applied to every control within a window.
As others have tried to get you to do, the best way to do this is with a frame.
You are trying to do what most of us do with FG and try to make it work like we want instead of how it actually works. Why are you so wed to not using a frame? Surely the number of colors cannot be that high. If you want a border, stack two frames. Easy peasy.
Alternatively, you could use the preload construct for windows. At work now and cannot get to wiki to tell you the option but there is a switch you can set in your window to prebuild it. Cannot remember it’s name. However, it comes with its own baggage if you use it (can’t remember the particulars).
I am not sure why I am even replying as if you don’t treat us humans any better you may never see another reply here.
If you don’t put your size in attributes but use actual tags for them, you can also directly read the xml window definition to get the sizes. This is how I do it in my (non working at the moment due to updates in 3.7.7 which I haven’t had time to address) generators extension. Look there for bracketed array references to the size tags if you want to see how it is done during initialization of Windows and controls. That won’t work however if the control has any dynamic sizing features.
I'll use actual tags and look for your extension otherwise.
The last thing you can do is take the top level window onInit (which runs last after controls created unless you use the preload flag I mentioned) and have it call a routine to do the sizing of selected controls. I think I might also use that technique in generators extension.
Comment removed because Trenloe is right. I apologize.
-
December 31st, 2019, 07:59 #5
Update:
- I tried searching for a "preload construct", but everything I found was about preloading images somehow, so you'll have to clarify that. I looked through the options menu, and found nothing there either.
- I also don't know how you "directly read the xml window definition to get the sizes". How do I "read the XML window"? What window?
- Edit: Found your Generators Extension here: https://www.fantasygrounds.com/forum...tors-Extension ...so you don't need to link it.
- I'd still like to know what tags are tied to "dynamic sizing features".
As for onInit(), if I execute it outside the control, it won't show up. If I execute onInit() directly inside the control, like so
Code:<stringcontrol> <script> function onInit() setBackColor("#FF0000"); end </script> ... </stringcontrol>
This strengthens my suspicion that this is a bug, and if it's a bug, then it seems that a simple backcolor tab within a template, is the cleanest and most intended way to do it, which means that I'll go with that approach. It will look like ****, until it's fixed in the future, but that's not my fault - that's just more incentive for the devs to fix the bug.Last edited by MooCow; December 31st, 2019 at 08:25.
-
December 31st, 2019, 08:40 #6
I downloaded your Generators extension, but found no reference to any color. Your only two frames are for slider bars. What am I looking for here?
Is it this part?
Code:<anchored to="rightanchor"> <top /> <right anchor="left" relation="relative" offset="-5" /> </anchored>
Edit:
No, you seem to have some sort of debug commands here, that "finds active tags":
Code:doDebug("***findActiveTag***;aTagStack,sTag=",aTagStack,sTag); for i=1,#aTagStack do if tagsAreEqual(aTagStack[i],sTag) then --doDebug("found the active tag at #",i); return i; end end return nil; end --findActiveTag
Last edited by MooCow; December 31st, 2019 at 08:53.
-
December 31st, 2019, 13:39 #7
Archangel
- Join Date
- Apr 2008
- Location
- Virginia Beach
- Posts
- 3,096
MooCow, I am at work at a defense contractor. I cannot get to any site tagged with game or anything with 'Fantasy' in its url (I'm sure you can imagine what that is designed to prevent). So, I am stuck with my phone (and only on breaks when I leave the secure lab and cannot have my phone). So, I can't effectively research anything on my phone, and I am not a very good thumb typer. So, I am doing this from memory.
The tag is fastinit, and it is in the subwindow. I have not tried it, but as I understand its function, if you use it, I believe the controls will be valid in the onInit calls. The problem is that FG does a depth-first creation of windows and controls, so you cannot get to the sizes of controls from window initialization code, and I don't think I've been able to get getSize() to work in the onInit of the control itself, if I remember correctly (guessing that onInit might be invoked before the control is fully created???). If you look at my onInit code and the routines it calls, you will somewhere find where I read the xml using LUA table notation. This only works for static controls, and it only works if you define sizes in xml tags and not attributes (you cannot use LUA table notation to get to attributes, only tags). Look at my template override for the table window at the description (I think) field, which I dynamically size based on the dragline control. I think some of my size reading stuff is in there somewhere.
The other thing you can do is defer accessing sizes until after the window is fully instantiated. I do this in Generators too by using some other event or handler that I cannot recall, but you should be able to find it looking through my code.
As for dynamically-sized controls, read the anchor material on the wiki. I find it hard to follow, but it is factually correct and if you experiment with the options enough, you will eventually figure it out. But the gist of a dynamically sized control is that you anchor its edge(s) to a window edge or some control that is itself anchored to a window edge, and when the window size changes, your control will resize. I don't think that helps what you are trying to do directly, but it is probably something you will eventually want to do.
You can dynamically size yourself the hard way (see my dragline control) or rely upon FG's built-in features.
Generators does not do what you are trying to do directly, but since you refuse to layer frames, which is the easy way, you are going to need to get to the size tags or attributes to do what you want (if I understand what you want properly), and Generators has at least two different techniques where I determine control size either at instantiation or during window usage.
The tagstack code you found is not useful for what you are trying to do. Those tags are for macro-scripting of tables (not LUA tables, FG random tables), which is one of the things Generators was doing.
Anyway, this is all my thumbs can stand, and I have to get back to work.Last edited by Bidmaron; December 31st, 2019 at 13:44.
-
December 31st, 2019, 14:21 #8
This code may or may not help...
This code looks at the size of the Character sheet and several frames have their size defined by a calculation based on the current character sheet window size.
If the size of the sheet changes then the frames also change size.
Code:<script> function onInit() self.onSizeChanged = resizeFrames; end function resizeFrames(sourceWindow) local nWidth,_ = getSize(); spellpointsframe.setStaticBounds(15, 115, (nWidth*2/3)-30, 70) combatframe.setStaticBounds((nWidth/3*2)-15, 20, (nWidth/3)-10, 165) lfgframe.setStaticBounds(5, 15, (nWidth/6), 112) luckframe.setStaticBounds((nWidth/6), 15, (nWidth/6), 112) rerollframe.setStaticBounds((nWidth/3)-5, 15, (nWidth/6), 112) abframe.setStaticBounds((nWidth/2)-10, 15, (nWidth/6), 112) cas2.setStaticBounds((nWidth/3), 185, (nWidth/3)-15, 260) cas3.setStaticBounds((nWidth*2/3)-15, 185, (nWidth/3)-15, -1) cas1.setStaticBounds(15, 185, (nWidth/3)-15, 195) cas1a.setStaticBounds(15, 380, (nWidth/3)-15, 120) cas3a.setStaticBounds(15, 500, (nWidth/3)-15, -1) end </script>
-
January 1st, 2020, 10:17 #9
I had no idea that you would be stuck in a high-security lab during the holidays. Thank you for trying to help me out, but please don't wear yourself out doing it.
The tag is fastinit, and it is in the subwindow. I have not tried it, but as I understand its function, if you use it, I believe the controls will be valid in the onInit calls. The problem is that FG does a depth-first creation of windows and controls, so you cannot get to the sizes of controls from window initialization code, and I don't think I've been able to get getSize() to work in the onInit of the control itself, if I remember correctly (guessing that onInit might be invoked before the control is fully created???).
Example code:
Code:<script> function onInit() setBackColor("#FF0000"); local w,h = getSize(); setAnchoredWidth(w+150); end </script>
The offset scripting seems to be done with "setAnchor(target, parent, parentanchor, [relation], [offset])" but this seems to need parent controls, and, again, I don't know how to write something abstract like "this.parent" within a template, and have that be resolved for every instance.
If you look at my onInit code and the routines it calls, you will somewhere find where I read the xml using LUA table notation. This only works for static controls, and it only works if you define sizes in xml tags and not attributes (you cannot use LUA table notation to get to attributes, only tags). Look at my template override for the table window at the description (I think) field, which I dynamically size based on the dragline control. I think some of my size reading stuff is in there somewhere.
Code:function onInit() local bSetAnchor=false; local sTool="dragline_tooltip_dragparent"; if type(anchored[1].top[1])=="table" then if anchored[1].top[1].parent then if anchored[1].top[1].parent[1]~="" then bSetAnchor=true; if (anchored[1].top[1].offset or 0)~=0 then nOffset1=anchored[1].top[1].offset or 0; end end end end if target and target~="" then sTool="dragline_tooltip_dragboth"; sControl=target[1]; bTarget=true; if type(target)=="table" then nOffset2=target.offset or 0; if (target.masteranchor or "")~="" then sAnchor=target.masteranchor; end end elseif mooring and mooring~="" then sControl=mooring[1]; if type(mooring)=="table" then nOffset2=mooring.offset or 0; if (mooring.masteranchor or "")~="" then sAnchor=mooring.masteranchor; end end end if nOffset1==0 then nOffset1=3; end if nOffset2==0 then nOffset2=15; end setTooltipText(Interface.getString(sTool)); if bSetAnchor then setAnchor("top",anchored[1].top[1].parent[1],"bottom","absolute",nOffset1); initHeight(window[anchored[1].top[1].parent[1]]); else Debug.chat("Missing dragline target."); end if bTarget then initHeight(window[sControl]); end end
The other thing you can do is defer accessing sizes until after the window is fully instantiated. I do this in Generators too by using some other event or handler that I cannot recall, but you should be able to find it looking through my code.
As for dynamically-sized controls, read the anchor material on the wiki.
I find it hard to follow, but it is factually correct and if you experiment with the options enough, you will eventually figure it out. But the gist of a dynamically sized control is that you anchor its edge(s) to a window edge or some control that is itself anchored to a window edge, and when the window size changes, your control will resize. I don't think that helps what you are trying to do directly, but it is probably something you will eventually want to do.
You can dynamically size yourself the hard way (see my dragline control) or rely upon FG's built-in features.
Generators does not do what you are trying to do directly, but since you refuse to layer frames, which is the easy way, you are going to need to get to the size tags or attributes to do what you want (if I understand what you want properly), and Generators has at least two different techniques where I determine control size either at instantiation or during window usage.
The tagstack code you found is not useful for what you are trying to do. Those tags are for macro-scripting of tables (not LUA tables, FG random tables), which is one of the things Generators was doing.
Anyway, this is all my thumbs can stand, and I have to get back to work.Last edited by MooCow; January 1st, 2020 at 10:28.
-
January 1st, 2020, 10:44 #10
Well, it both helps, and doesn't help.
"function onSizeChanged(source)
This handler is triggered whenever the size of a window is changed. It can be used to implement specific content positioning based on window size."
My problem isn't related to resizing a window.
However, the meta syntax is actually helpful: A function calling "self.eventName = functionName" repeatedly, might update the bounds of a static control. If I can find an event that will trigger every time that a template is instanced, to retroactively fit in margins, then that will probably be the solution. (I can just center the text in a slightly expanded width.)
Thank you.
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks