FG Spreadshirt Swag
Page 1 of 2 12 Last
  1. #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" />
    However, when combined with a backcolor, the backcolor only expands vertically, and not to the sides. Maybe this is a bug - I don't know.

    Do I need to use scripting with getSize() for this? Would that even expand the backcolor properly?

  2. #2

    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.

  3. #3
    Trenloe's Avatar
    Join Date
    May 2011
    Location
    Colorado, USA
    Posts
    33,362
    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!

  4. #4
    Quote Originally Posted by Bidmaron View Post
    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.
    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.
    Yes, I agree: That would be easy. ...but I prefer nice looking code. I want to learn about the tools that are the most suitable, and I want to do it the best way. ...and I also want any bugs to be noted and fixed (not just for me, but so that things generally work as intended).

    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).
    Sounds exciting. I'll try to look into it.

    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.
    I literally can't. I don't understand human interaction. Growing up, mostly in a mental asylum, I've never really been taught how, and I'm also severely emotionally disturbed. Not in a "Haha, you're so emotionally disturbed." way, but actually chronically emotionally disturbed and schizoid. When I close my eyes all I see is my fingers digging through flesh. When I relax I scream. That's why I don't take my meds: Because they make me think coherently. I try my best to say "Thank you." but that's pretty much all I know how to do. I don't understand human worth because I just can't see the concept. You humans complain about your hurt emotions all the time around me, and all I can do is to tell you to stop hurting yourselves on me. I can only be so much sorry for my own existence. I didn't ask for this.

    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 tried looking for dynamic sizing a lot, but all I got was "relation" "relative". Where do I find something about dynamic sizing? That sounds like "dynamically size a control according to text" - just what I want.
    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.
    Okay, so onInit() works here.

    Comment removed because Trenloe is right. I apologize.
    Thank you. I mean, I'm not hurt by being called things. I just don't want to hurt you guys. I don't mean you any harm.

  5. #5
    Quote Originally Posted by Bidmaron View Post
    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.
    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>
    the backcolor still won't fill out the side margins - only the top and bottom margins.

    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.

  6. #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
    I don't know how finding an active tag would help me, though.
    Last edited by MooCow; December 31st, 2019 at 08:53.

  7. #7

    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.

  8. #8
    damned's Avatar
    Join Date
    Mar 2011
    Location
    Australia
    Posts
    26,656
    Blog Entries
    1
    Quote Originally Posted by MooCow View Post
    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?
    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>

  9. #9
    Quote Originally Posted by Bidmaron View Post
    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.
    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???).
    I've never bothered to learn Object Oriented Programming, so I don't know if there's any voodoo equivalent of "this.getSize()" that will yield anything other than zero, within a template, probably because at the time that Fantasy Grounds encounters my script, it doesn't have any instance parameters to work with. That's probably what you meant with "depth-first creation". I don't know if there's an equivalent of onCreation(). Why I want getSize() is because I want the size of the text, so that I can add margins to it, and set that as the new width. That way I don't have to use offsets, which seem really inconsistent and buggy. (See my bug report in the support forum.)
    Example code:
    Code:
    			<script>
    				function onInit()
    					setBackColor("#FF0000");
    					local w,h = getSize();
    					setAnchoredWidth(w+150);
    				end
    			</script>
    (This will just give the control the width of 0+150. I need the length of the text for this to work.)

    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.
    It's hard to tell, but you might be referring to this part:
    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
    I have no idea what this is supposed to do. What I'm looking for is simply the variable that contains the width of a text after it has been printed. Since I can't execute your code until it's updated, I don't even know what your program, or the dragline, does. Judging by the graphics, it looks like a slider of some sort.

    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.
    Deciphering your code would take me about a week. You'll probably be home in a week, and able to point out exactly what one line of code you're talking about.

    As for dynamically-sized controls, read the anchor material on the wiki.
    As I said: The only part about dynamic sizing that I found, refer to the resizing of actual windows. There might be other forms of resizing, but it looks like Google is censoring parts of the refdoc, so I'm not getting the hits that I want. Instead I'm getting forum threads talking about other things.

    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.
    Actually the first thing I did, was get rid of the resize widget. I will probably instate it later on, but for now, my character sheet is fixed in size, until I get all the default dimensions right. (Text is welcome to expand controls, though.)

    You can dynamically size yourself the hard way (see my dragline control) or rely upon FG's built-in features.
    What features do you mean? The resize widget, or the text expanding the control? I'm getting the feeling that we're talking about different things here.

    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.
    Does it read the data nodes for the control width somewhere? ...and how? Your code contains about a thousand lines of code, and I'm starting to suspect that you're playing games with me here, trying to be as elusive as possible: "Read this program. Something like what you want might be in there somewhere. ...probably. Read it. Reverse engineer it."

    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.
    Okay, so your program exported XML files, I take it.

    Anyway, this is all my thumbs can stand, and I have to get back to work.
    Thank you. Next time, however, wait until you're home proper, and can cut-and-paste what lines of code that you're referring to.
    Last edited by MooCow; January 1st, 2020 at 10:28.

  10. #10
    Quote Originally Posted by damned View Post
    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>
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
STAR TREK 2d20

Log in

Log in