Sign in to follow this  
n4gix

More XML Oddities...

Recommended Posts

Does anyone have a explanation why I cannot substitute an L: var for a G:Var???Why does this not work:(L:DataFields,bool) ! (>L:DataFields,bool)but this does:(G:Var3) ! (>G:Var3)

Share this post


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

(L:DataFields,bool) !(>L:DataFields,bool)I don't know how you come to the conclusion that this code doesn't work, because it does (I just copied/pasted/tested it).So the error is probably at the place in the code where you actually test the (L:DataFields,bool) variable.You didn't forget the ,bool there, did you :-) ????Cheers, Rob

Share this post


Link to post
Share on other sites

As far as I know, the only differences between L: and G: vars are naming conventions and scope (oh, and no units for G:vars....)You don't have an L:DataFields in another gauge?Douglas

Share this post


Link to post
Share on other sites

>(L:DataFields,bool) !>(>L:DataFields,bool)>>I don't know how you come to the conclusion that this code>doesn't work, because it does (I just copied/pasted/tested>it).>>So the error is probably at the place in the code where you>actually test the (L:DataFields,bool) variable.>You didn't forget the ,bool there, did you :-) ????I used the simplest approach possible: I tried it out! ;)No, I didn't forget the ,bool in the either...This is only of importance to me because the a/c will have two copies of this gauge running: one on the 2d panel and one in the VC. I think it would be nice if turning either one of them on would at least turn on the other simultaneously... ;)There are FAR too many variables used to 'synchronize' all of 'em, but at least this one basic should be achievable! ;)

Share this post


Link to post
Share on other sites

>As far as I know, the only differences between L: and G: vars>are naming conventions and scope (oh, and no units for>G:vars....)>>You don't have an L:DataFields in another gauge?Nope. There's only two XML gauges in the entire package, and the other one is a simple N-Number plaquard. ;)

Share this post


Link to post
Share on other sites

Bill,As far as I know an XML gauge is only loaded once, not matter in how many windows (2D or VC) the gauge is defined.Which means that (in your case) if you change a var in the VC definition, the var in the 2D window changes too (because it's the same memory).Now, I know for sure this work for G:Vars, because I use this myself.However, I have never tried this for L:Vars, but I cannot imagine that this works differently.Rob

Share this post


Link to post
Share on other sites

HiWell, it *should* work, and by looking at your earlier xml gauges, I know you know it should work too. Why it doesn't is beyond me. I would also suspect the checking to be wrong, the part where you select graphics based on the L:Var.Have you tried commenting out all the other .gau gauges, to check if some are causing weird problems?I now swear to using L:Var instead of G:Var. I also used G:Vars a lot in the past but they caused many updating bugs when the same gauge was present on two panels, or both on 2D and VC panels. Changing it for a L:Var always did the trick for me.

Share this post


Link to post
Share on other sites

>I now swear to using L:Var instead of G:Var. I also used>G:Vars a lot in the past but they caused many updating bugs>when the same gauge was present on two panels, or both on 2D>and VC panels. Changing it for a L:Var always did the trick>for me. As it turns out, the reason for the L:var not working had nothing to do with the L:var per se, but rather the monitored variable I used to trigger it...This gauge relies a LOT on @macro calls, and I forgot to include the @ as a prefix for the @g:variable... ;)

Share this post


Link to post
Share on other sites

>Bill,>>As far as I know an XML gauge is only loaded once, not matter>in how many windows (2D or VC) the gauge is defined.>Which means that (in your case) if you change a var in the VC>definition, the var in the 2D window changes too (because it's>the same memory).Actually, that is not always true. If your gauge uses @macro calls, and/or CustomDraw routines, then it appears that TWO copies are loaded and initialized.The 2d and 3d instances of the same gauge do NOT remain in synch...

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