Visibility of gouped click areas

[nickpike 0]

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

[Guest Vorlin]

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

[taguilo 33]

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

[nickpike 0]

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

[Guest Vorlin]

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

[nickpike 0]

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

[spokes2112 179]

Wrong example :-(

[phjvh 0]

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

[nickpike 0]

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

[phjvh 0]

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..."

[taguilo 33]

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

[nickpike 0]

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

[Guest Vorlin]

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

[taguilo 33]

>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

[taguilo 33]

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