Sign in to follow this  
taguilo

Visibility of gouped click areas

Recommended Posts

Hi All. I'm making a Garmin G1000 and things are progressing nicely.This has a row of 12 buttons (and hence click areas) along the bottom.The way they work is as follows.Click on a button, and all the buttons change function, acting like a sub-menu to the original button clicked.Therefore, in the default state, I allow each button to be active using Visible Visible tags in the Area Area code for each button. Then when a button is clicked and the buttons change function, I have new area code which is active according to a new set of visible tags. This all works great, but I have a lot of Visible tags. I tried grouping all the buttons by nesting them in on visible tag, but this did not work. Can anyone suggest why this grouping tactic did not work, or suggest a way of doing this without a Visible tag for each click area.Many thanks,nick

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Nick,First, thanks for all your contributions that help us to learn. I would have put a fist through the monitor long ago without you!Ok, this is a snippet from some code I used for setting what gauge to navigate by (the gauge tells you if you're on or off course, and this is part of the code to set what navaid you want it to reference).(L:setNavBy,bool) %NavByOBS1(%((L:NavByOBS1,bool))%{if}ON%{else}OFF%{end})(L:NavByOBS1,bool) ! (>L:NavByOBS1,bool) 0 (>L:NavByADF,bool) 0 (>L:NavByOBS2,bool) 0 (>L:NavByGPS,bool) The first problem with nesting I see is that the area is defined before the check for visibility. This makes grouping areas unfeasable unless we could get it to work the other way around, where the visibility is determined before the area is defined.The problem is that visibility is a characteristic of area... so there is no direct way to do what you want to do. However, anything can be done if you're warped enough, and I'm pretty warped. So...Since L:Vars have a scope that allows them to communicate between gauges, why not make each group of buttons into it's own gauge and set the visibility for the gauge (your group of buttons) via a variable that denotes which set should be active when.It's not a perfect solution, but it's possible. It's been used before to be able to access more 2 d windows than can be accessed via SHIFT+#... it may work straight up the same way or may need some tweaking.Sorry I don't have a ready made solution, just some food for thought.Scott / Vorlin

Share this post


Link to post
Share on other sites

Nick,I see only two posibilities here:n1submenu1n2submenu2n3submenu3etc.This for only one button, and nX is a conditional. Each area handles a submenu (as you call it)Or:1(not relevant)n1 If(submenu1) n2 If(submenu2) n3 If(submenu3) etc.I'd rather choose the second option, could be easier to manage using macros. And as I remember, it is the way used in the default GPS500.Tom

Share this post


Link to post
Share on other sites

Thanks guys, food for thought. The seperate gauges sounds interesting. However, the code works ok and it might be more convenient to keep it all in one gauge.The1(not relevant)n1 If(submenu1) n2 If(submenu2) n3 If(submenu3) etc.looks like a decent approach. At least this groups all the functions of one button into one click area. I'll finish the gauge and then I'll know all of it's functions. Then I will probably group the functions. I think this will make the code more efficient.Thanks again for you input,nick

Share this post


Link to post
Share on other sites

Actually, I like Tom's idea better too LOLPerhaps you could try combining the tooltip IF code in my example and the click IF code in Tom's... that could allow one button to be used for unlimited purposes depending on various L:Vars.Oh, btw:"Since L:Vars have a scope that allows them to communicate between gauges..."Yea, I know. It was close to midnight, I was tired. DOH!Scott /Vorlin

Share this post


Link to post
Share on other sites

I wonder which method would be less cpu intensive?n1submenu1n2submenu2n3submenu3etc.This has to read a lot of Visible tags and has the same button area read several times.Or:1(not relevant)n1 If(submenu1) n2 If(submenu2) n3 If(submenu3) etc.This cuts the Visible tags to the same quantity as the number of buttons, but adds additional conditional code before the actual button code is processed. I've got a sneaky feeling that the first method would be less CPU intensive.cheers,nick

Share this post


Link to post
Share on other sites

Hi,You could make macro's for each button.all functions you can imagine@button 1Jan"Beatus ille qui procul negotiis..."

Share this post


Link to post
Share on other sites

Thanks Jan, I take it you add all the conditional code into the macro as well?Is this a 'making the code as tidy as possible' exercise, or are there operational advantages as well?nick

Share this post


Link to post
Share on other sites

Nick,You can do everything what you want or need inside the macro;have a look in the MS-GPS at some click area's!!!As an example one of my fmc buttons: 0 (>L:scroll,number) (L:progr,enum) 1 == if{ 6 (>L:pushbutton,enum) 0 (>L:progr,enum) } (L:pushbutton,enum) 10 == if{ 1 (>L:init,enum) 0 (>L:pushbutton,enum) } (L:rte,enum) 1 == (@g:blinkingField) 2 == and if{ (@g:directTo) 1 == if{ @BottomLeftKnob } } (L:rte,enum) 1 == (@g:blinkingField) 1 == and if{ 10 19 (@g:enteringInput) rng if{ -1 (>@c:IcaoSearchAdvanceCharacter) @InitBlinker quit } @InvokeICAOInputMode((@c:FacilityICAO), 'AVNWM', 31) } (L:arr,enum) 1 == (L:dep,enum) 0 == and (L:arr,enum) 0 == (L:dep,enum) 1 == and | if{ 1 (>L:dep arr,enum) 0 (>L:arr,enum) 0 (>L:dep,enum) } (L:dep arr,enum) 1 == if{ (@c:FlightPlanIsActiveFlightPlan) if{ (@c:FlightPlanWaypointsNumber) -- (>@c:FlightPlanWaypointIndex) (@c:FlightPlanWaypointICAO) (>@c:WaypointAirportICAO) @InvokePopupSelectApproach } } (L:proc,enum) 1 == if{ @ENTButton } (L:dep arr,enum) 1 == (L:legs,enum) 1 == | (L:nrst,enum) 1 == | (L:clb,enum) 1 == | (L:crz,enum) 1 == | (L:des,enum) 1 == | (L:progr,enum) 1 != (L:pushbutton,enum) 6 == and | if{ (@g:messagePopup) 0 == if{ (>K:GPS_CURSOR_BUTTON) } els{ 0 (>@g:messagePopup) } (L:legs,enum) 1 == if{ 2 (>@g:listCurrent) } } els{ (L:legs,enum) 0 == if{ (@g:directTo) 0 == if{ 0 (>L:proc,enum) 0 (>L:legs,enum) 0 (>L:clb,enum) 0 (>L:crz,enum) 0 (>L:des,enum) 0 (>L:nrst,enum) 0 (>L:rte,enum) (L:progr,enum) 1 == if{ 6 (>L:pushbutton,enum) 0 (>L:progr,enum) } els{ 0 (>L:progr,enum) 0 (>L:navrad,enum) 1 (>L:init,enum) 0 (>L:pushbutton,enum) } } } } 1 (>L:fmcsound,enum) L6@L6 Jan"Beatus ille qui procul negotiis..."

Share this post


Link to post
Share on other sites

Jan's fmc macro code is a great example of a complex logic within a simple .I for one prefer to use macros in a more referenced way.Following Jan's example, condition if{subcode1 } condition if{ subcode2 }etc@Macro1 If only one macro is called, it would be the same to put the entire code with its subcodes inside the On the other hand, I find easier to identify what does each subcdode do by using this syntax:codecodeetccondition if{ @Subcode1 }condition if{ @Subcode2 }etcI guess another point of view does always good :-)Tom

Share this post


Link to post
Share on other sites

Thanks again guys. Actually, the plot now thickens.Recently I did an editing exercise on a number of very lengthy, complex gauges. Making more use of memory registers, removing duplicate code, etc. I have seen comments on this forum saying that a lot of gauges, their complexity.etc did not seem to slow FS or cause frame rate problems. However, after the editing exercise mentioned above, an 8 second per minute slow down of the aircrafts clock/timer was removed and frame rate improvement was significant. So I believe in buiding the code as CPU friendly as possible. Question.If a lot of complex button code is put into a macro, it would be processed during each gauge cycle. If it is put into a click area, it would be processed once. Therefore, I'm thinking, would the latter help optimise FS performance?cheers,nick

Share this post


Link to post
Share on other sites

Silly questions from the student in the corner....1) Can we emulate a switch statement with Select / Case within the click code or are we chained to IF's?2) Is a Select with 10 Cases less CPU intensive than ten linear IF / ELS statements?Just a thought...Scott / Vorlin

Share this post


Link to post
Share on other sites

>Question.>If a lot of complex button code is put into a macro, it would>be processed during each gauge cycle. No, code iniside a struct is not executed directly but parsed in replace of the calling reference (@macro) To make it more clear:This is what we users write to save lot of typing:value1 value2 operator1 value3value4 value5 operator2 value6cond1 if{ @MyMacro1 }cond2 if{ @MyMacro2 }cond3 if{ @MyMacro1 }An this is what is translated to assembled code:cond1 if{ value1 value2 operator1 value3 }cond2 if{ value4 value5 operator2 value6 }cond3 if{ value1 value2 operator1 value3 }Remember what I use to phrase ...Literal replacement of text...:-)Tom

Share this post


Link to post
Share on other sites

Scott,>1) Can we emulate a switch statement with Select / Case within the >click code or are we chained to IF's? (with / ) is a component of the structure. It cannot be used within structures. >Is a Select with 10 Cases less CPU intensive than ten linear IF / >ELS statements?Both are different things. is used only to display bitmaps, and doesn't support anything else, where if/els are conditional operators to be used within the stack's space.Tom

Share this post


Link to post
Share on other sites

Hi Tom, can I summarise by saying,The use of macros is less CPU intensive. The more code you can put into a macro, the better.Also, using Select/ Case is not very CPU intensive. This presumably is less intensive than a load of Visible statements.Ref an example above, I can't think at this time of the morning where you would use if/els for displaying multiple bitmaps. Obviously this can be used in Select/ Case, but I'm thinking the way the question was put, it was being used another way.cheers,nick

Share this post


Link to post
Share on other sites

>The use of macros is less CPU intensive. No way. There is no advantage in terms of assembled code efficiency with the use of macros. The only benefited is the programmer that has to write less lines (and an improvement of readability too IMO), but that's all.>The more code you can put into a macro, the better.Most of times this is true. But because of the reasons stated above.>Also, using Select/ Case is not very CPU intensive. This>presumably is less intensive than a load of Visible>statements.We'd have to separate this in two parts:Code is what we know the most common way of managing pure code within a stack's area. When used to support logic only, is not needed because there is no bitmap to show.Typical example would beMake the hydraulics workI would assume like you that there is not much CPU cost here.Now, when there is a need to show bitmap(s), enters in action.And for sure in this case there will be a hit in performance, because bitmaps' display consumes a lot of CPU (and FPS) power.>Ref an example above, I can't think at this time of the>morning where you would use if/els for displaying multiple>bitmaps. Obviously this can be used in Select/ Case, but I'm>thinking the way the question was put, it was being used>another way.As I posted on this same thread earlier, if/els are components of the stack, and they only "push" values that can be tested by statements.Tom

Share this post


Link to post
Share on other sites

Tom,fps, bitmaps, value, visible etc...How do you program knobs with backlighting (like the in the 757)?I still need 2 elements.One for the knob and one for the overprojected backlighting when on.Jan"Beatus ille qui procul negotiis..."

Share this post


Link to post
Share on other sites

>Obviously this can be used in Select/ Case, but I'm>thinking the way the question was put, it was being used>another way.I was hoping to use Case structures to decide what code to use after the Case structure determined the situation... but if it can only apply to bitmaps, that appears to be a serious limitiation. It's a shame that we can't put logic there or, apparently, even a nested Element within the Case that would handle the logic within the nested Element.IE:0 (>L:OnGround,bool)OR (stack) 'Down' sp30 It would be nice... maybe someday.Scott / Vorlin

Share this post


Link to post
Share on other sites

>I was hoping to use Case structures to decide what code to use>after the Case structure determined the situation... but if it>can only apply to bitmaps, that appears to be a serious>limitiation. It's a shame that we can't put logic there or,>apparently, even a nested Element within the Case that would>handle the logic within the nested Element.>In fact what IS logic it that we can't put extra (stack) code inside a .AFAIK, those structures surrounded by "<>" (like ) are nothing but pointers to certain areas of memory in the assembled codeStrictly speaking of , when the code is compiled, each Case value is associated with a memory location where its corresponding bitmap resides. So, when a stack value is extracted with a command, it is compared against the array of defined pointers (Case's) and the matched pointer will redirect the code to the memory area that contains the bitmap to be displayed.Within this logic, I guess there is no room for other type of code.Tom

Share this post


Link to post
Share on other sites

Hi Tom, thanks for being your usual very helpul self.>Now, if only Transparency tag would work for Circle command....I had cause to use a transparent circular element recently, so used a bitmap with alpha (originally intended for shadowing). I presume you know this technique?cheers,nick

Share this post


Link to post
Share on other sites

>>I was hoping to use Case structures to decide what code to>use>>after the Case structure determined the situation... (snip) It's a shame that we can't put logic there or,>>apparently, even a nested Element within the Case that would>>handle the logic within the nested Element.>>>>In fact what IS logic it that we can't put extra (stack) code>inside a .(snip)>...when a stack value is extracted with a command,>it is compared against the array of defined pointers (Case's)>and the matched pointer will redirect the code to the memory>area that contains the bitmap to be displayed.>>Within this logic, I guess there is no room for other type of>code.I got the idea in general, but I'm getting the impression (and it could be a wrong impression!!!) that you seem to think this is very simple to understand... and with your background and experience, I imagine it is! (smile)Unfortunatly, I come from a background where it's very common to write a Select / Case in the way below and I was wondering if it could be emulated in MSXML for FS9: Food @PizzaMacro @EnchaladaMacro @ChineseMenuMacro In my background, selecting what function or macro to do next depending on the results of a Select (Switch) argument is considered to be a great way to write your script.But, if I understand you correctly, MS designed the CASE tag so that it's code is assembled to include the functions of an IMAGE tag and we can't get rid of that so that we can use the CASE for something other than displaying a bitmap because the CASE tag itself is going to be assembled into code that tells FS9 to display the image contained within the CASE tags no matter what.So to write: @PizzaMacro Would be assembled into final code that tells FS9 "if the value is equal to zero" then:"@PizzaMacro"Which would, of course, fail miserably.Wow... after all that time learning to use Case to branch from function to function for my other projects outside of FS9, this leaves me a little stunned. Oh well, nested if's haven't been taken away so there's always a way to do what we need to do.Thanks,Scott / Vorlin

Share this post


Link to post
Share on other sites

Yes, indeed I use alpha masks in some of my gauge (ie Stdby Attitude), however I couldn'd get fair results with small bitmaps (switches).I'm gettin axious waiting for FSX arrival.. :-(Tom

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this