XML... macros vs. L:variables

[Guest jprintz]

Okay, I've been tinkering a lot more with XML macros lately, and can't believe I haven't relied on them a LOT more. I've done a forum search and have seen this topic touched on only slightly, so I'll ask....Asume we have little snippets of code / calculations that we'll need to use more than once in our gauge, and since used in several sub-elements, we'll need to declare / define them at the very top. We could use......the macro method:calculationscalculationscalculationsor.... the L:Var method: calculations (>L:Var1) calculations (>L:Var2) calculations (>L:Var3)I'm now having some trouble understanding why anyone would ever use the L:Var method *within a single gauge*. L:Var's can be used in other gauges in the same panel, while macros can be called only in the gauge in which they're defined, AFAIK, but is there ANY other advantage to L:Var's that I'm missing?And, are the following assumptions true?1) The calculations required to pass values into "global" L:Vars, defined up at the top of the gauge, are done each pass through the gauge, whether the particular variable is currently being used or not?2) The calculations done within a macro, even if also defined at the top, outer-most element, are performed only when the macro is currently in use?3) The units returned by a macro calculation are always of type "number"?Thanks for any insight!

[n4gix 4,947]

I'm afraid that a macro isn't a "calculation" at all, nor is it a sub-routine, nor is it a function...Tom wrote up a most excellent article on macros some years ago, and which is now incorporated in to the FSWiki that I help run:http://forums.flightsim.com/fswiki/index.p...L:_Using_MacrosWherever you see "@Macro1" used, simply substitute whatever is contained in the Macro1 code!As for L:var,unit those are nothing more complicated than a custom variable we can define and use for whatever we need. All L:vars are by default FLOAT64 variables.

[Guest jprintz]

Hi Bill, and thanks for taking the time to reply.>I'm afraid that a macro isn't a "calculation" at all, nor is>it a sub-routine, nor is it a function...>Eh?From Tom's example:(A:VELOCITY WORLD X, m/s)(A:VELOCITY WORLD Z, m/s) atg2 rnorWhat am I missing? That's certainly a calculation, even if it's happening somewhere else (at the macro call, and not within that macro definition itself). And, at least mathematically speaking, it's a function... I'm a math teacher, so if I used that word, it was probably in that sense... but I realize "function" has a very different and precise meaning in "true" programming languages. I should be more careful on a forum dedicated partially to gauge programming. ;-) Regardless, I'm not concerned about labels.... What I want to know is: is the calculation within the macro definition performed every cycle, so that "Macro1 Result" is READY to be passed any time the macro MIGHT be called? Or is it done only if the macro IS called on a particular pass through?In something like the example in my original post (with many L:Var's or macros defined up top), it is my understanding that L:Var's ARE calculated each pass through, regardless of need. So, assuming the result of Macro1 is the same as that of L:Var1, this would mean that the following are handled very differently...(condition) if{ @Macro1 } els{ 0 }(condition) if{ (L:Var1, number) } els{ 0 } ... in that L:Var1 is calculated whether the condition was met last pass through or not, and @Macro1 is calculated ONLY IF the condition was met. (I say last pass through since XML is always processed linearly, correct?) Anyway, I swear that somewhere, on one of the many gauge/panel forms, someone made reference to this benefit of macros, but I cannot find it now, and want to make sure my understanding is correct. I'll keep looking. Does anyone else have this understanding? Because that could be a HUGE benefit of macros over L:Var's.... >Tom wrote up a most excellent article on macros some years>ago, and which is now incorporated in to the FSWiki that I>help run:>>http://forums.flightsim.com/fswiki/index.p...L:_Using_Macros>>Wherever you see "@Macro1" used, simply substitute whatever is>contained in the Macro1 code!Yeah, I understand their usage. Thanks. The thread that text was taken from was a great help to me when I started working with macros. But I guess I'm really asking about what's going on "behind the scenes." >As for L:var,unit those are nothing more complicated than a>custom variable we can define and use for whatever we need.>All L:vars are by default FLOAT64 variables.Understood. Thanks. I'm assuming that, similarly, the result of a calculation within the macro definition is always FLOAT64?

[nickpike 0]

In simplistic terms a Macro is just a section of code.If you have some complex coding that gets repeated a lot, put that code into the macro, and then call up the macro when needed.It is not necessarily a complete section of code or a complete calculation, it is just some of the code you require.You can do more neat things with macros, but see Tom's stuff.An example,If you use a function and then if{ @1 }or if{ @2 }, etc in the macro called, key_input_COM1then in the code@key_input_COM1(100, 10, 1, 0.1, 0.01, 0.001)If @2 is relevant, the value 10 is used.Have a look at the default gps500 gauge. It's full of macros. You'll understand it or get a headache, depends if XML is in the blood :()

[taguilo 33]

>Hi Bill, and thanks for taking the time to reply.>>>>I'm afraid that a macro isn't a "calculation" at all, nor is>>it a sub-routine, nor is it a function...>>>>Eh?>>From Tom's example:>>> (A:VELOCITY WORLD X, m/s)(A:VELOCITY WORLD Z, m/s) atg2 rnor>>>>What am I missing? That's certainly a calculation, even if>it's happening somewhere else (at the macro call, and not>within that macro definition itself). And, at least>mathematically speaking, it's a function... I'm a math>teacher, so if I used that word, it was probably in that>sense... but I realize "function" has a very different and>precise meaning in "true" programming languages. I should be>more careful on a forum dedicated partially to gauge> programming. ;-) Regardless, I'm not concerned about>labels.... >Bill's own definition about macros is somehow correct, as a macro is nothing more than a literal replacement of text within a script. Because of this, macros might *appear* sometimes like subroutines or functions that return a value, but the reality is other.For example, this macro *seems* to *return* a value:5 2 *...2 @Value +And this one *returns* a piece of code:llo... (L:He@Code ,bool) +or this one which is well known ;-)C:fs9gps. (@g:FlightPlanIsLoaded)>What I want to know is: is the calculation within the macro>definition performed every cycle, so that "Macro1 Result" is>READY to be passed any time the macro MIGHT be called? Or is>it done only if the macro IS called on a particular pass>through?Macros only exist in source code, they are merged with their calling scripts at gauge init and the complete text is actually loaded in memory. For example, this exist in an XML file:34 6 + 67 / ...@MyMacro (>L:MyVar,number)And this is loaded and parsed by FS on each cycle:...34 6 + 67 / (>L:MyVar,number)>>In something like the example in my original post (with many>L:Var's or macros defined up top), it is my understanding that>L:Var's ARE calculated each pass through, regardless of need.>So, assuming the result of Macro1 is the same as that of>L:Var1, this would mean that the following are handled very>differently...>>> (condition) if{ @Macro1 } els{ 0 }>> (condition) if{ (L:Var1, number) } els{ 0 } >>No. At runtime there is no difference in the way both scripts are handled.>... in that L:Var1 is calculated whether the condition was met>last pass through or not, and @Macro1 is calculated ONLY IF>the condition was met. (I say last pass through since XML is>always processed linearly, correct?) Anyway, I swear that>somewhere, on one of the many gauge/panel forms, someone made>reference to this benefit of macros, but I cannot find it now,>and want to make sure my understanding is correct. I'll keep>looking. Does anyone else have this understanding? Because>that could be a HUGE benefit of macros over L:Var's.... >>Essentially, macros are very useful to avoid typing repetitive text on XML sources, which helps on keeping these files short and readable, especially on huge gauges (ie FS GPS). And not only they won't improve the performance of a gauge, but actually this last one will load slower than expected to happen taking into account the file size, because the parser has to "expand" it's contents with macro code before panel init.Tom

[Herbie63 0]

For me the main advantage of using macros is that they make the code easier to write (or to understand somewhen later...). This especially when there are complex actions or calculations to perform with mouse click events. So I meanwhile prefer to "call" a macro only in the code for mouse click events.

[n4gix 4,947]

Thankfully Tom already covered most of the details, so I'll only add just a bit more to his excellent explanation.As Tom wrote, a @Macro is nothing more nor less than a handy "label/name" we can give a hunk of text: it is replaced on panel init with the contents of the @Macro label.As for your question about:(condition) if{ @Macro1 } els{ 0 }(condition) if{ (L:Var1, number) } els{ 0 } The answer is that in both cases, the state of the (condition) will determine which of the two possibilities is "executed." In both cases above, if the (condition) is FALSE, nothing happens... ;)

[spokes2112 179]

To answer one of your other inquiries, you wrote...I'm now having some trouble understanding why anyone would ever use the L:Var method *within a single gauge*. L:Var's can be used in other gauges in the same panel, while macros can be called only in the gauge in which they're defined, AFAIK, but is there ANY other advantage to L:Var's that I'm missing?One of the best uses for a L:Var in a single gauge is for an initial load initialization of variable states.L:Vars are not "volatile"G:Vars, l0,s0,sp0 are "volatile"Volatile means at every quage read the variable gets set to zero.This works for an INI.. It will only work on first load. (L:INI, bool) 0 == if{ (SET MY INI PARAMETERS) 1 (>L:INI, bool) }This will not work as it sets parameters each time the gauge is read. (G:Var1) 0 == if{ (SET MY INI PARAMETERS) 1 (>G:Var1) }Another good use for L:Vars is for custom variables. It's just plain easier to follow (L:LavSeatDown, bool) (L:LavFlushLever, bool) (L:LavFlushPumpTimer, number) than (G:Var1) (G:Var2) (G:Var3) within your code. :-erksEDIT - Yet another reason to use L:Vars is that you may never know during panel/aircraft design when you need to communicate with another gauge or the model system. If you use (G:Vars) it would require a rewrite. Roman

[taguilo 33]

>>This will not work as it sets parameters each time the gauge>is read. > (G:Var1) 0 == if{ (SET MY INI PARAMETERS) 1 (>G:Var1)>}>Roman, this is not exactly true. GVars indeed retain their values but they are visible only inside their related gauges.For example, in gauge1 (G:Var1) 0 == if{ 20 (>G:Var1) } In gauge2 (G:Var1) 0 == if{ 30 (>G:Var1) } G:Var1 will be 20 in gauge1 and 30 in gauge2, UNTIL a panel/aircraft reload, panel resize or end of flight. IMHO most important drawback that advices not to use them in gauges is the panel resize resetting action.Tom

[spokes2112 179]

Tom, DUH !! I stand corrected thanks.. It was the resize/reload problem that I was trying to remember.Roman