Jump to content

IAS gauge.


Recommended Posts

Now THAT is a great looking, and handy looking too, gauge!

I hope we will see it in the library soonest! Is it for FSX or FS9, both? Neither?

Anyway, great looking work! Nicely done :)



Had a thought...then there was the smell of something burning, and sparks, and then a big fire, and then the lights went out! I guess I better not do that again!

Sgt, USMC, 10 years proud service, Inactive reserve now :D

Link to comment
Share on other sites

  • 3 weeks later...

Hi Pat, Sorry for not replying sooner.

Ace.exe --> wont work in fs9.


Not sure about posting/library.

Noticed issue. When making smaller to fit in 2D main panel, text/numbers run out of box. (numbers end up too low. Boxes are wide enough.).


Only one bitmap used in gauge. Almost black (dark grey) rectangle background image.

Purple boxes are not drawn on image, but result of xml. Each has own coordinates, height and width defined in xml.

Same with text, and with output of variables. Green colour, coordinates, height and width all consequence of xml.


Also defined, font, and fontsize. I think that making font smaller I can make text fit in if gauge is shrunk onto main 2D, and still look ok if gauge is on larger popup panel.


If not I would have to start adjusting coordinates. Not focussed enough for that now. :)


making it work in fs9 is probably possible. But that would require a complete rewrite I think, and I don't have a clue how to start. Probably best to start with the 'IAS only gauge', rewrite that, and once I get that working, (and find someone who is willing to test it in fs9:) ) apply that method to the 'completed gauge'.


It could be a while.

I don't use 2D panels much. I'm now using this as popup in a few jets and that works fine. So I'm not in much of a hurry to 'fix' anything. But before possibly publishing I would kle to try and make sure that people with larger/smaller monitors and resolutions, and people who want to install in 2D main panels can use it too.



Link to comment
Share on other sites

  • 1 month later...

This got a bit further along.


I had made this in Ace.exe and that made it an FSX gauge, won't work in FS9.

Also, the code that the Ace editor spat out made sense, and I could hand edit and add to it, but re-creating it from scratch without using the Ace editor, and in FS2004/2002 syntax seemed a bit daunting.



Today I had a free moment, and created a new gauge. This time starting from scratch without the Ace editor.

I created a little display that shows:

1-Fuel on board at moment of takeoff in percent,

2-FOB at takeoff in kg

3-Current fuel on board in kg

4-Fuel flow in kg per minute (says ppm at the moment, is really kg per minute, need to change text later.)

5-Time remaining with current fuel at this rate of fuel flow.


And, in the right-hand column

6-Distance to GPS target at moment of takeoff,

7-Current distance to target,

8-Fuel use in kg per NM

9-kg duel required for current distance to target.


1- Total fuel amount in percent. (99 in image). Gets smaller with engine running on ground, but freezes as soon as airborne.

Then stays that number. Use--> you can see with how much fuel you took off.

2- Fuel amount in Kg. Again, freezes on takeoff.

3- Current fuel quantity in Kilograms. Simvariable is pounds, division makes kilograms.

4-Current Fuel Flow in Kg per minute. Result of Simvariable for pounds per hour, and division to make into Kg per minute.

5-Time remaining with current Fuel amount and Flow. Simple division. 500 pounds at 10 pounds a minute gives 50 mins remaining.


Right-hand column

6-Distance to destination (GPS target), fixed at moment of takeoff.

7-Current distance to GPS target.

8-Gal required per NM at this time. Calculated as:

((Fuel flow rate, pounds per hour) times factor to make kilograms per hour))

devided by (Speed over Ground, Nautical miles per hour) ---> Result: kilograms per NM

9-Kilograms required for the current distance, when using the current flow in Kg per NM. So, if 300NM to go, and flow is 2kg per NM, then you require 600 kg.


By comparing the required amount (-9-) to the available fuel (-3-) you can see if you will reach the target with your remaining fuel.


A very nice thing is also that if you don't have enough fuel to reah the target, you will see if slowing down would help. (and it does!!).

At less thrust, the fuel flow in kilogram per minute reduces.

Your speed reduces as well.

The reduction in fuel flow per minute is greater then the reduction in speed,

so, the fuel use per NM reduces.

That means, less fuel required for the same remaining distance.

I kinda knew that already, but it's nice to see it actually happening and to be sure slowing down is working. Very nice.:)



This is not at all ready to be shared yet. I started making it 10 hours ago. There are also some issues, (that may not be fixable).

issue1-reloading the aircraft causes an issue. The fuel at takeoff value and GPS at takeoff value show zero after that.

issue 2-if not reloading the aircraft, but reloading the gps plan (or a new one) the "total distance to target" valu and "fuel on board at start" values, do not change. THey stay as they were at the moment of takeoff.

issue 3-the distance to target is only shown when the nav-gps switch is in GPS mode.


This gauge was intended for personal use, and I'm not too bothered with the issues above. Intention was to use it in the RTW(2018)

with a plan of:

load plane at airport 1

load a gps plan to destination (direct to)

(set gps/nav to gps because required for gauge to show value)


see in gauge: fuel on board at takeoff, and if flying faster still would get you in fuel trouble.


I really need to double-check some of the math in the gauge, I have a doubt about one of the values, but on the whole it seems to be working fine.


And, now that I made that, I have a basis for re-creating the speed indicator panel that I showed earlier.


Here are some screenshots.

before TO plan set gps selected.JPG


further in.JPG


higher groundspeed - lower kg per NM

higher groundspeed - lower kg per NM.JPG


too fast

too fast.JPG


slightly slower fuel lasts

slightly slower fuel lasts.JPG


can speed up again

can speed up again.JPG

Link to comment
Share on other sites

You may have this already .

Place the following two macros near the beginning of your code .

Then check if distances are changing as they should .




I did my Radar for my F-111 Pig HUD panel in the FSX syntax.

Mode 3 of that radar has a constantly updating Flight Plan text listing that showscurrent distances.

The display is 15 lines ( Legs ) long but has a scroll bar for Flight plans that are longer , you can do up to 99 Legs .

I created a Flight plan Editor that is incorporated into a MFD , so I can create or modify Flight Plans as often as I like .

For example , you could create 10 or more totally different flight plans or DTO's in a single flight sim session if that is your desire .

The flight plan listing will show each new flight plan and will reflect distances as a flight progresses .


The above macros might help .


What you have done looks wonderful , well done .




Link to comment
Share on other sites

At the moment I'm using as GPS distance: (A:HSI DISTANCE, Nautical miles)

That gives distance to next waypoint I think.


But it may be possible to use another variable, showing total distance of all waypoints. For example: (GPS TARGET DISTANCE, Meters) or (GPS WP CROSS TRK, Meters).



Your idea about a Macro. I haven't used those before. I will add the lines you gave to see if there's a effect. I'm not sure what it does though, or why.


I have a different (simpler) idea of resetting. A reset button.

What my gauge does is:


if{ 1 (>L:TAKENOFF, bool) }



As long as L:TAKENOFF, bool) is still zero,

(A:HSI DISTANCE, Nautical miles) (>L:TODISTANCE, Nautical miles)


And in the display the value of (L:TODISTANCE, Nautical miles) is displayed


As you take off, (L:TAKENOFF, bool) turns to 1.

After that (L:TODISTANCE, Nautical miles) stays at the same number it was.


The actual distance to target while flying does get updated all the time. That number is simply: (A:HSI DISTANCE, Nautical miles)


But L:TODISTANCE does not. It keeps showing the distance to target at the time of taking off.



Then, if you create a new flightplan:

L:TAKENOFF is already 1

So L:TAKEOFFDISTANCE does not get updated.



This does not have to be a bad thing! sometimes you're careless and drift off your flightplan. You remake a flightplan to the same destination.

Having my gauge still shows the original distance and fuel amount when you took off can be very usefull if you want to know how much fuel you spent during the flight and how much distance you covered.

You will of course also see distance to target, and you can draw (correct) conclusions such as: "I had 400NM to go at takeoff, now 200 remaining to target - I had 99% fuel at takeoff, now only 30% remaining ---->> I'm not gonna make it!!


But, it can also be handy to reset the gauge. For example, if you land at your destination, and want to fly on again to somewhere else without restarting the sim.

Or, if you want to fully re-do your fuel calculations when making a new flightplan mid flight..



The issue of not restting is very simple.

(L:TAKENOFF, bool) goes from 0 to 1 at the moment of takeoff,

but nowhere in the gauge does it go back to 0.

(Up til now that was by design, to not complicate things with if els statements.)


A very simple solution for resetting is creating a clickspot that does:

0 (>L:TAKENOFF, bool)

click that spot and the TakeOff values get reset to current values for Distance and Fuel on Board. It would reset both: "TO percent", "TO kg", and "Dist TO". (after which L:TAKENOFF gets set to 1 again.)


I think that's the most simple solution. And it leaves the user the option of resetting or not.



Thanks for the Macro though. I'll look at it again after a lot of coffee. (And a trip to the Ice-Cream shop. I always require some Ice-Cream during/after making a gauge.)


Link to comment
Share on other sites

Addin reset button worked.

Had to put the reset code at the top, and the code for setting to set "L:var to 1 on takeoff" at the bottom of the gauge.


Added the button as two images, round. one red and one green, with black around them.

Red image when (L:TAKENOFF) = 0

Green image shows when (L:TAKENOFF) = 1


also added


red image when plane gets loaded.

as you takeoff, TO kg and such freeze, and button turns green.

as you fly actual fuel decreases, and TO fuel stays constant.

click the button, and TO fuel is set to the Actual fuel. Then freezes at that value.

Image turns red for a second, then turns green.


All exactly as I wanted.

(happens for total distance as well).



I just tested, and distances that are shown is indeed distance to next waypoint.

(and fuel required follows directly from that distance too.)

Making it show total distance is the next thing I will look at. But, as this was intended for racing where usually a flightplan is a direct-gps, I'm very happy with it as is.:)


(Oh, btw, I made the reset switch as a separate gauge as well. To put on a 2D panel. Turns red/green as well.)

Link to comment
Share on other sites

Some images:




1 return to departure

1 return to departure.JPG



2 landed

2 landed.JPG



3 after reset

3 after reset.JPG



4 different flightpln made - ready to go again

4 different flightpln made - ready to go again.JPG



5 just after takeoff - button turns green again

5 just after takeoff - button turns green again.JPG



6 kg req high - because gear down

6 gal req hig because gear down.JPG



7 gear and flaps up - kg req lower because faster

7 gear and flaps up - kg req lower because faster.JPG

Link to comment
Share on other sites

8 at altitude - gs and ias higher - result is ferwer kg per NM and less required

At cruise altitude GS get's higher because now flyin level and every NM traveled is a NM in forward direction. Not just partly forward and partly up.

GS is also higher because IAS higer. I'm flying constant thrust. (No autothrottle) So when flying level same thrust generates more speed. No more fighting to climb.

Notice, not enough fuel to reach target. (I departed with only 60% as you can see.)

8 at altitude - gs and ias higher - result is ferwer kg per NM and less required.JPG



9 Flying much slower - now fuel should reach out

9 Flying much slower - now fuel should reach out.JPG

Link to comment
Share on other sites

There was an error in it.


I though I was working with kilograms/hour divided by NM/hr. (With kg/hr the result of a L:variable defined earlier)

But I had not. I had the fuel per NM calculated as lbs/hour divided by NM/hour. So what you saw was actually Lbs/NM.


I have now multiplied that result by 0.45359237, to give kg/NM


The required amount followed from the Fuel flow. So the value shown was in pounds.

I multiplied that by 0.45359237 as well now, so kg required is now correctly displayed.


(I noticed something was wrong in a test flight. It said I had 300 kg required, and 380 remaining.

but a while later, I had 260 required. I expected therefore to have 340 remaining.

To my surprise, I had over 360 remaining instead.

So, as required dropped by 40 kg, remaining dropped by only 20 kg. That just couldn't be correct.)


I also noticed a difference between the original fuel gauge in the plane, and my gauge.

When the "fuel and payload" menu says 340 lbs remaining,

I calculate that is:

0.45359237 x 340 = 154.22 kg

my gauge gives the same value.

But the fuel gauge in the plane does something like:

0,521 x 340 = 177 kg


I have not looked inside that gauge to see why exactly.

The 0.521 is just a value I found by dividing the shown value (177kg) by the value in the fuel and payload menu (340lbs).

The fuel flow rate in that aircraft is also higher then the one my gauge shows.


I did two test flights to destination (360 NM).

The fuel flow and speed fluctuate a lot during takeoff and climb.

For example:

*Fuel flow lbs/min drops with altitude (even with automixture off). Result is that at start of climb required fuel is overestimated.

*Speed slow because of flaps/gear leads to high kg/NM value, and overestimates required fuel when low down.

*Adding thrust increases fuel flow fast, but speed takes a while to increase. So for a while the fuel consumption (and required amount) are overestimated.

*reducing mixture during climb reduces fuel consumption. Makes required amount lower.


When flying at constant speed in cruise, and engine/speed settled, the readings start making more sense.

When stable in cruise you will get something like (fictitious numbers):

start of cruise - on board: 300 kg -- required: 250 kg

halfway - on board: 175kg -- required 125

at destination - on board 50kg -- required 0 kg


So the estimated fuel remaining when reaching destination stays 50kg at each point in time.

It's not actually that precise, but it works quite well.


During the test flight I did not descend to destination, but stayed at cruise altitude. I kept the same speed throughout the flight. (even unplugged the joystick so the thrust would stay steady.)

Normally during descent you would save some fuel.

My gauge does not account for reducing the thrust during descent. So if it says you'll reach the destination with 10 kg remaining, you should actually have more then that on landing.

(of course you also use some extra fuel if you need to fly the pattern, or go around.)


Some images. Each image followed by image of fuel and payload menu at same time.

(flight in Cessna C172, both shots in cruise level, at constant speed (full throttle at 22.000 ft))













Link to comment
Share on other sites


I placed your macro at the start of the gauge, but saw no difference.


My issue is that, only when the gps/nav switch is set to gps,

does my gauge show the distance to destination (or actually to first waypoint.).


I would like my gauge to always show distance to destination (or first waypoint), no matter if the nav/gps switch is in NAV or GPS setting.


I had a look at the code in the fsx default GPS 500, but the code made absolutely no sense to me. I did notice the same macro names were in there.


Could you explain how to use that macro? Or is this something that would take take weeks to learn and go too far?

Link to comment
Share on other sites

Hi il88pp


Below is a sample containing code that I use .

This is GPS based it obtains data from the GPS module .


NOTE the below code is in FS9 syntax ,

while the Macros I provided earlier are in FSX syntax .

Do not mix the two syntax in one gauge .


Create a gauge containing the following ,

1. GPS macros (this accesses the GPS module )

2. an element containing the below code .


Test fly with either a Direct to or a saved flight plan .

%((A:GPS WP PREV ID, string))%!s!%>%((A:GPS WP NEXT ID, string))%!s!%

\n%((A:GPS FLIGHT PLAN WP INDEX, number))%!02d!%-%((A:GPS FLIGHT PLAN WP COUNT, number) 1 -)%!02d!% * %BRG %((A:GPS WP BEARING, degrees) d360)%!03d!%

\n%((A:GPS WP DISTANCE, nmiles))%!04.1f!% NM%

\n%((A:GPS WP ETE,seconds) 3600 / int )%!02d! : %((A:GPS WP ETE,seconds) 3600 % 60 / int flr 60 %)%!02d! : %((A:GPS WP ETE,seconds) 60 % int flr 60 %)%!02d!%




PS - re shot

the code provided above results in text data seen in the mini MFD built into the right of the autopilot .

PS (again )

all above code variables are from the GPS SDK .


Link to comment
Share on other sites


I put this at the top (copied from the fsx default gps):



And this is the element.

\n%((A:GPS WP DISTANCE, Nautical miles))%!04.1f!% NM%


But still, the distance only shows when nav/gps swithch is set to nav.


To me it feels as if something important is still missing. "It can't be that easy" -feeling.

Link to comment
Share on other sites

Hi il88pp


I have no idea why it is not returning distance information , it should regardless of the GPS/NAV switch position .


If you want to pursue this further , below is the full code for a flight plan listing gauge ,

copy ALL the code and paste into a xml , name that xml , then test fly it with a saved flight plan .

No background bitmap required for this instrument .

Check that it steps through the flight plan legs and that the distances are changing as you fly the flight plan .

This flight plan listing is similar to that shown at right of my screenshot .





Full instrument code .

[quote]      Type="AceXML"
AceXML Document





(@c:FlightPlanIsActiveFlightPlan) (@c:FlightPlanIsLoadedApproach) and

@FPLEnrouteHeader +
(@c:FlightPlanIsActiveFlightPlan) if{ (@c:FlightPlanWaypointsNumber) + }

 (@c:FlightPlanIsActiveApproach) if{
 (@c:FlightPlanIsActiveFlightPlan) if{ (@c:FlightPlanWaypointsNumber) }
} els{
@FPLEnrouteHeader +






















@ThumbMaxHeight 15 * (@c:FlightPlanWaypointsNumber) 15 max /


@ThumbMaxHeight<br />
1 15 (@c:FlightPlanWaypointsNumber) / - *<br />
(@c:FlightPlanWaypointsNumber) 15 - /<br />
(L:ListInitialVis) *



  %((L:ListInitialVis) 15 + (@c:FlightPlanWaypointsNumber) min s2)
   %{if}%((L:ListInitialVis) sp1)
  %(l1 (>@c:FlightPlanWaypointIndex))
	  \t%((@c:FlightPlanWaypointMagneticHeading,degrees) d360)%!03d!
  %(l1 ++ s1 l2 	 %{next}



%TKE %((A:GPS IS ACTIVE WAY POINT, bool))%{if}%((A:GPS WP TRACK ANGLE ERROR, degrees))%!d!°%{end}


%XTK %((A:GPS IS ACTIVE WAY POINT, bool))%{if}%((A:GPS WP CROSS TRK, nmiles) s1 abs d s0 100 >=)%{if}%!d!%{else}%(l0 10 >=)%{if}%!.1f!%{else}%!.2f!%{end}%{end}\{dpl=nm}%(l1 100 * near s0 0 >)%{if}>%{else}%(l0 0 


\tSEQ\tWPT\tDTK \{dplo=M}\tDIS \{dpl=nm}\tTOT \{dpl=nm}\n%


%((@c:FlightPlanWaypointsNumber) 1 - (>@c:FlightPlanWaypointIndex))%((@c:FlightPlanWaypointRemainingTotalDistance,nmiles) s0 0 !=)%{if}%(l0)%!d!%{end}


%((A:GPS FLIGHT PLAN WP COUNT, number) 1 -)%!02d!

(@c:FlightPlanIsActiveFlightPlan)  0 ==





(M:Event) 'LeftSingle' scmp 0 == if{<br />
(M:Y) (>L:DownY)<br />
}<br />
els{<br />
(M:Y) (L:DownY) -<br />
@ThumbMaxHeight / (@c:FlightPlanWaypointsNumber) *<br />
(L:ListInitialVis) +<br />
(@c:FlightPlanWaypointsNumber) 15 - min 0 max (>L:ListInitialVis) }



Link to comment
Share on other sites

Thank you for that! Even though that's for fsx it may help to understand. I can then adjust to keep my gauge fs9 compatible.

Small issue, I can't get the gauge to show.

I ran the code through Firefox, Smiley edited out, but keep getting a

parsing error.

In line 153, column 16

%(l1 ++ s1 l2


Link to comment
Share on other sites

I think I have it now.


I removed the


After that I got a different parse-error. Now in line 171 column 113


%TKE %((A:GPS IS ACTIVE WAY POINT, bool))%{if}%((A:GPS WP TRACK ANGLE ERROR, degrees))%!d!ï¿¿%{end}



The 'FFFF' symbol showed up when copy pasted as a degree symbol.

I replaced the degree symbol with the word: deg


Now there is no parse error.


I'm not sure if removing the

(And shows distance to, after creating a direct-to flightplan.)

I had no time yet to test further.

Link to comment
Share on other sites

It works now. My gauge is showing total distance of all waypoints now. Even when in nav/gps switch in nav-mode.


I'll stare at it more later.

What I did was: I had earlier added the start of the fs9 gps xml (everything that cam before the last


That gave a non-showing gauge.

I now checked the parse. Again deg symbols were the issue. These are in gps500.xml as well.

I now edited it and changed the deg signs into the word: deg


then I used one line from what you posted:

%((A:GPS WP DISTANCE, Nautical miles))%!04.1f!% NM%


It now works great!


looking back, that's pretty much the same I did earlier.

Not sure why it didn't work that time. Perhaps because of the deg-symbol.

(it wasn't the /n

that makes it show up on the next line, as I had deduced already from your complete gauge. But in my gauge it doesn;'t completely drop out of view because of that.)


Thank you again. Lots to think about.:D

Link to comment
Share on other sites

I didn't want to just blindly copy everything from the default gps500.xml file.

I thought a short while, then deleted everything except:





(and used the same Element as in previous post).


and it just works!


Not sure why. I'm starting to think it was alright all along, and that the error was in the panel.cfg file.

Maybe renamed, and panel.cfg not updated accordingly.

Or gauge9= instead of gauge09=

Link to comment
Share on other sites

I did a small test gauge for you .

It consists of ,

- Waypoints Idents

- Waypoint index numbers

- Bearing

- Distance

- Time

- Track error angle

- Track error distance


I tested it and it works regardless of GPS/NAV switch position .

It is created in FS9 syntax .





Full gauge code ,


%Waypoint Data%

%WPT Ident From - To%
		        \n%Index # From - To%  
				\n%BRG to Nxt WPT %
				\n%Dist to Nxt WPT%
				\n%Time to Nxt WPT%
				\n%TKE angle%
				\n%XTK distance%

%((A:GPS WP PREV ID, string))%!s!%>%((A:GPS WP NEXT ID, string))%!s!%
		        \n%((A:GPS FLIGHT PLAN WP INDEX, number))%!02d!%-%((A:GPS FLIGHT PLAN WP COUNT, number) 1 -)%!02d!%  
				\n%((A:GPS WP BEARING, degrees) d360)%!03d!%\{dplo= } %
				\n%((A:GPS WP DISTANCE, nmiles))%!04.1f!% NM%
				\n%((A:GPS WP ETE,seconds) 3600 / int )%!02d! : %((A:GPS WP ETE,seconds) 3600 % 60 / int flr 60 %)%!02d! : %((A:GPS WP ETE,seconds) 60 % int flr 60 %)%!02d!%
				\n%((A:GPS IS ACTIVE WAY POINT, bool))%{if}%((A:GPS WP TRACK ANGLE ERROR, degrees))%!d!°%{end}%
				\n%((A:GPS IS ACTIVE WAY POINT, bool))%{if}%((A:GPS WP CROSS TRK, nmiles) s1 abs d s0 100 >=)%{if}%!d!%{else}%(l0 10 >=)%{if}%!.1f!%{else}%!.2f!%{end}%{end}\{dpl=nm}%(l1 100 * near s0 0 >)%{if}>%{else}%(l0 0 

Link to comment
Share on other sites

Wow, my cup overfloweth!:D Thanks for the new gauge! I'll check that out later.

Lots to think about.


What I'm wondering, what does this do:





It's not enough to define a macro.

Does it call a macro, that is part of fsx.exe somehow?

Or does it call (and require presence of) the gps500.xml file? (call a macro in there.)


I also don't get the @variables.

can you refer me to a document/thread that shines some light on those @variables?


Thank you again.:) Distance showing even though nav/gps switch to nav really completes it all. Yeah!



Link to comment
Share on other sites

Hi il88pp


You are welcome , hopefully it provides code snippets that you can adapt for your own purposes .


Regard those two macros , I'm not sure what they achieve , I assume that they help the instrument to recognise and access the " GPS module " .


The following are how I define matters , they are not necessarily accurate , and I might be wrong .


1. gps500.xml

This is just a very complex instrument , it accesses the GPS module and uses capabilities within that module , it also accesses the sim database , the xml instrument then presents data as both text and graphics in a useable format for the pilot's use during flight .


2. GPS module

This is a complex module that comes with the sim ( FS9 , FSX .... etc ) , essentially it's a " black box " of code and algorithms burried in the background of the sim .

We take forgranted the sim that we use , in actual fact it is a massively complex and capable programme .

We have about 24,491 airports available many with multiple runways , taxiways , ILS , VOR's , NDB's , approaches ,

Intersections , anywhere on earth you have a location that has a Latitude/Longitude and elevation .

Add to this Flight planning capabilities .

Now with this massive database available the module allows you to access it with a xml instrument in a myriad of ways depending on how you code your instrument .

You create your instruments at the level of complexity that suits you , simple , complex , or extremely complex ,

also you create it to achieve the function , capability , or purpose that you desire or need .

Bob did a fantastic GPS module handbook that is referred to and pinned here at this forum , be warned that initially the subject matter can be a little overwhelming , but you can create magnificent instruments with it .


Regards macros .

Often a macro will contain code which at times can be long and complex it is wrapped in a title .

That title can be called by use of " @variable " within code in a subsequent Element section .

The @ variable basically inserts the complete code that was in the macro into your String .




Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...