This article summarises the most important points of the previous articles about attributes in MultiCharts PowerLanguage. Follow the links to the different articles for more information and in-depth examples.

In this article:

Working with attributes in MultiCharts PowerLanguage

While most MultiCharts settings can be configured manually, a couple of features that can only be set programmatically. We define those settings with attributes. A PowerLanguage attribute is a keyword that enables or disables a certain script feature. Their usage looks like this:

Example location of MultiCharts attributes in a script

PowerLanguage attributes can be placed anywhere in the script, although their typical location is at the beginning of the script’s code. Other similarities of the MultiCharts are (e.g., TradeStation, 2007; MultiCharts Wiki, 2014):

  • An attribute only affects the script in which it’s used – it doesn’t affect other scripts that are on the same or a different chart.
  • Attributes can be set to true or false, and each attribute needs to be placed on a separate line between two square brackets ([ and ]).
  • Furthermore, all but the IntrabarOrderGeneration attribute have no manual equivalent setting in MultiCharts. That means adding the attribute to the script’s code is nearly always the only way to enable or disable the attribute’s feature.
  • The script feature that’s toggled by an attribute is applied when the script compiles and cannot be changed during run-time. And so once we’ve added an attribute to the script, we can only change the feature that’s set by the attribute by changing its value (from false to true or vice versa) and then recompiling the script.

We can divide the different MultiCharts PowerLanguage attributes in two groups:

Let’s look at each of these attributes briefly.

ProcessMouseEvents: programmatically working with mouse clicks

The ProcessMouseEvents attribute makes programmatically processing mouse clicks possible (MultiCharts Wiki, 2012a). We enable this feature as follows:


[ProcessMouseEvents = true];

This doesn’t mean, however, that MultiCharts processes every mouse click: clicks that happen on the chart’s status line, time axis, price axis, or that happen in an indicator’s subchart are ignored. And so clicks happening in the grey areas in the image below cannot be processed in PowerLanguage:

Mouse click areas that aren't processed in MultiCharts PowerLanguage

Also, ProcessMouseEvents only works in the context of a trading chart – clicks in the Scanner/Watchlist or Portfolio Trader cannot be processed by a script.

A script is also not recalculated following a registered mouse click when the ProcessMouseEvents attribute is set to false or missing from the script’s code.


[ProcessMouseEvents = false];

RecoverDrawings: prevent automatic removal of intra-bar drawings

The RecoverDrawings attribute defines whether intra-bar drawings are kept on the chart or removed after the next script calculation (MultiCharts Wiki, 2014a). These drawings are arrows, text boxes, and trend lines that are made programmatically – drawings made manually aren’t automatically removed by MultiCharts, regardless of the RecoverDrawings setting.

By default, MultiCharts removes any drawing that’s made during an intra-bar script calculation while drawings that are made on bar close do persist on the chart. This gives the odd behaviour whereby a script makes a drawing and a second or so later this drawing automatically disappears. Luckily, we can make any drawing persist on the chart by setting the RecoverDrawings attribute to false (MultiCharts Wiki, 2014a):


[RecoverDrawings = false];

When this attribute is set to true or not present in the script’s code, then MultiCharts removes all of the script’s intra-bar generated drawings automatically (MultiCharts Wiki, 2014a).


[RecoverDrawings = true];
Tip: Always set RecoverDrawings to false when creating arrows, trend lines, and/or text boxes programmatically. That way drawings will remain on the chart when your code makes them, which also helps to identify inefficient code (like a coding but that creates an arrow repeatedly).

LegacyColorValue: working with the old, pre-RGB colour scheme

The LegacyColorValue attribute specifies which colour scheme is used for interpreting numerical colour values (MultiCharts Wiki, 2012b). With this attribute set to true, the script uses the old colour scheme with 16 different colours:


[LegacyColorValue = true];

When LegacyColorValue is set to false or not present in the code, then RGB colours are used (MultiCharts Wiki, 2012b). That colour scheme contains millions of different colours, made by combining different shades of red, green, and blue.


[LegacyColorValue = false];

Besides using colour PowerLanguage keywords to apply a certain colour, these keywords also return a number. When LegacyColorValue is set to true, that number will be between 1 and 16. And when the attribute is set to false or missing from the script, then a RGB value is returned.

The colour keywords have the following legacy and RGB values (TradeStation, 2007):

Colour keyword Legacy value RGB value
Black 1 0
Blue 2 16711680
Cyan 3 16776960
Green 4 65280
Magenta 5 16711935
Red 6 255
Yellow 7 65535
White 8 16777215
DarkBlue 9 8388608
DarkCyan 10 8421376
DarkGreen 11 32768
DarkMagenta 12 8388736
DarkRed 13 128
DarkBrown 14 32896
DarkGray 15 8421504
LightGray 16 12632256

This means that, instead of using a colour keyword, we can also use a number to specify a colour (MultiCharts Wiki, 2012b). For example, with LegacyColorValue enabled the colour of the first plot is set to dark red with SetPlotColor(1, 13). This features makes it possible to calculate with a number: when LegacyColorValue is enabled, then 4 refers to green but adding 2 give us red.

IntrabarOrderGeneration (IOG): react to price changes happening inside a bar

The IntrabarOrderGeneration attribute enables a signal to calculate and generate orders intra-bar (MultiCharts Wiki, 2012c). When this feature is enabled, a strategy script can react to price changes happening inside a price bar.


[IntrabarOrderGeneration = true];

When IntrabarOrderGeneration is set to false or when this attribute isn’t in the script’s code, then intra-bar order generation is disabled and the signal submits an order at most once per bar.


[IntrabarOrderGeneration = false];

The importance of IntrabarOrderGeneration is the following. With this attribute enabled, orders can be submitted when the price bar hasn’t closed yet. That gives the signal the opportunity to respond to price action happening inside the bar. The benefit of disabling IntrabarOrderGeneration, on the other hand, is that the script runs more quicker.

Note that, although this attribute is named intra-bar order generation, IntrabarOrderGeneration affects anything that’s done programmatically by the signal, whether it’s submitting an order, drawing a trend line, triggering an alert, or outputting data. All of that is can be done repeatedly for each bar when IntrabarOrderGeneration is enabled.

AllowSendOrdersAlways: send orders regardless of the calculation reason

The AllowSendOrdersAlways attribute, when set to true, allows a signal to always submit orders – even when the bar status of the primary data series is undefined (MultiCharts Wiki, 2014b).


[AllowSendOrdersAlways = true];

By default, MultiCharts does not submit orders during an ‘undefined bar status’ meaning that orders aren’t always submitted when the script calculates.

A data series’ bar status indicates how the price that’s currently processed by MultiCharts relates to the price bar. These bar statuses can be the bar’s opening tick, its closing tick, or a tick that falls inside the bar’s body (MultiCharts Wiki, 2014c). Sometimes, however, a bar status can be ‘undefined’. That happens when (e.g., Henry MultiCharts 2015a, 2015b):

  • The price bar closes, but a periodic recalculation happens due to the RecalcLastBarAfter() keyword.
  • The price bar closes, but the strategy recalculates due to a broker event (like an order filled or a market position change).
  • The price bar closes, but the script calculates to process price bars from additional data series.
Tip: Always enable the AllowSendOrdersAlways attribute in your signal scripts. That allows the signal to submit orders regardless of what caused the script calculation, and this also prevents unfilled orders from being briefly cancelled whenever an undefined bar status occurs.

When the AllowSendOrdersAlways attribute isn’t in the script code or when it’s set to false, then orders are only generated during price updates that fall inside the price bar or during the bar’s opening and closing tick (MultiCharts Wiki, 2014b).


[AllowSendOrdersAlways = false];

SameExitFromOneEntryOnce: reuse exit orders when scaling out

The SameExitFromOneEntryOnce attribute affects whether or not a signal script can reuse its exit orders. With this attribute set to false, a filled exit order can be generated again and applied to the same position (MultiCharts Wiki, 2013).


[SameExitFromOneEntryOnce = false];

So with this attribute set to false we only need to code one exit for each scaling-out order, and can then simply reuse that order once we’ve submitted it for the first time. This reduces the amount of code that we need to type and also makes the programming code clearer.

Now when the SameExitFromOneEntryOnce attribute isn’t added to the script or when it’s set to true, then the signal cannot reuse an exit order to close part of the same position (MultiCharts Wiki, 2013).


[SameExitFromOneEntryOnce = true];

MultiCharts by default doesn’t allow reusing exit orders (MultiCharts Wiki, 2013), and so we typically need to program each exit order separately.

This concludes the chapter on PowerLanguage attributes. See all MultiCharts programming articles to learn more about other topics.


References

TradeStation (2007). EasyLanguage Essentials Programmers Guide. Retrieved from https://www.tradestation.com/~/media/Files/TradeStation/Education/University/School%20of%20EasyLanguage/Books/EL_Essentials.ashx

Henry MultiCharts (2015a, January 26). closing status of a bar sometimes takes too long – forum discussion. Retrieved on November 26, 2015, from http://www.multicharts.com/discussion/viewtopic.php?f=1&t=10642#p112902

Henry MultiCharts (2015b, January 30). closing status of a bar sometimes takes too long – forum discussion. Retrieved on November 26, 2015, from http://www.multicharts.com/discussion/viewtopic.php?f=1&t=10642#p113092

MultiCharts Wiki (2012a, February 24). ProcessMouseEvents. Retrieved on January 31, 2016, from http://www.multicharts.com/trading-software/index.php/ProcessMouseEvents

MultiCharts Wiki (2012b, February 19). LegacyColorValue. Retrieved on January 7, 2016, from https://www.multicharts.com/trading-software/index.php/LegacyColorValue

MultiCharts Wiki (2012c, August 31). IntrabarOrderGeneration. Retrieved on November 28, 2015, from http://www.multicharts.com/trading-software/index.php/IntraBarOrderGeneration

MultiCharts Wiki (2013, June 7). SameExitFromOneEntryOnce. Retrieved on February 10, 2016, from https://www.multicharts.com/trading-software/index.php/SameExitFromOneEntryOnce

MultiCharts Wiki (2014a, January 23). RecoverDrawings. Retrieved on February 8, 2016, from http://www.multicharts.com/trading-software/index.php/RecoverDrawings

MultiCharts Wiki (2014b, December 26). AllowSendOrdersAlways. Retrieved on November 26, 2015, from http://www.multicharts.com/trading-software/index.php/AllowSendOrdersAlways

MultiCharts Wiki (2014c, August 12). BarStatus. Retrieved on November 26, 2015, from https://www.multicharts.com/trading-software/index.php/BarStatus