DAS Trader hotkeys: understanding the script before pressing the key

Three official guides, three different jobs

These versions were checked against the official DAS document directory and PDFs on October 2, 2026. The directory’s July 6, 2026 update does not date every PDF. The basic guide still says “Updated May 2025” on its cover; the table uses its Last Updated footer. Document dates are not minimum client build numbers.

Start with basic commands, then the Advanced guide’s objects and state, and finally V2. Beginning with the shortest possible order string makes its background settings easy to miss. This is independent educational commentary; the exercise has not been execution-tested in DAS or with a broker.

First separate Load, Send and omitted fields

Montage is an important window for quotes and order preparation. The official Order Script Wizard explanation distinguishes BUY=Load from BUY=Send: Load prepares the ticket, with Enter in Montage sending it afterward; Send submits it directly. Loading already changes the ticket. It is not a read-only preview.

The same explanation says omitted fields fall back to information in Montage. When reviewing a hotkey, look beyond the written Price and Share values. Establish where its symbol, account, side, route and time in force come from. A button named “Preview” is not evidence that its script only previews.

If Market, Limit and Stop still blur together, read the order-type guide before the Load-before-Send lesson. Understand what a field constrains before writing it.

Learn variables and conditions with a spread calculation

Leave live quotes and order controls out of the first exercise. Suppose the bid is $12.40 and the ask is $12.46: the spread is $0.06. The teaching example below uses documented syntax to assign global variables and display a result. Advanced scripting must first be enabled as described on page 3 of the Advanced guide.

$DASIntroBid = 12.40;
$DASIntroAsk = 12.46;
if ($DASIntroBid <= 0) {
  MsgBox("Check bid");
  return;
}
if ($DASIntroAsk < $DASIntroBid) {
  MsgBox("Check quote order");
  return;
}
$DASIntroSpread = $DASIntroAsk - $DASIntroBid;
MsgBox(Round($DASIntroSpread, 2));

A name beginning with $ holds a value; = assigns it; if chooses whether to run a block; return exits early. Assigning inputs at the start avoids relying on a previous run. These two checks serve this fixed-number exercise only. Live data requires additional handling for missing values, source, observation time and changing quotes.

Calculate 12.46 − 12.40 yourself and compare the displayed result with 0.06. Change the ask to 12.39: the quote-order check should stop the calculation. Change the bid to zero: the earlier check should stop it. You are checking three specific paths, not treating any popup as proof that everything works.

To compare spreads across stock prices, state the denominator too. Relative to the bid, this example is about 0.48%; relative to the midpoint, the convention differs. Read Bid, Ask and Spread for the trading context and conditions and shared state for the scripting details.

Objects: which stock, window and account?

Think of an object as a reference with properties and available operations. DAS exposes window, quote and account objects: GetWindowObj locates a window, GetQuoteObj gets a symbol’s quote object, and GetAccountObj gets an account object. See Advanced pages 10–17.

Imagine two symbols open on the desktop. You intend to read A, but you last clicked B’s window. A command relying on focus can have a different target from an operation directed at a named window. Stable window names help, but a stable name does not guarantee that the symbol inside never changes.

Record the symbol, window name, account and observation time alongside the value. “BP was this” or “Ask was that” is hard to investigate later without context: did the target change, or did the data change? Continue with windows and execution context.

Chart values carry a time interval and settings

GetStudyVal reads a configured, named chart study; GetBar accesses displayed chart bars. See Advanced page 36. Neither function name establishes the symbol, interval or study settings for you.

The latest bar on a one-minute chart and the latest bar on a five-minute chart describe different intervals. A forming bar can still change. Treating “the value I just read” as “the previous completed bar” creates discrepancies between observation and review. Sequential field reads should not be assumed to represent exactly the same instant.

Write down the chart, interval, extended-hours setting and study name before recording results. The chart-data exercises examine these distinctions. The premarket and after-hours guide explains the session context.

Timers and loops: repeated work needs a stopping rule

The official guide describes Timer Event as running once a second and advises against imitating it with a while loop and waits. Use loops for a bounded set of work; use an event for successive observations. See Advanced pages 18–19.

Consider a practice spread alert with a hypothetical $0.10 threshold. Three successive readings of $0.12 satisfy the condition three times. That does not tell you whether you want three alerts. Decide separately whether to report only the first crossing, wait before repeating, or rearm after the spread narrows. This threshold illustrates program behavior, not a trading rule.

Write initialization, one observation, stop and reset before adding automatic repetition. A one-second schedule does not establish precise timing, fresh quotes or uninterrupted operation. Continue with timers and time boundaries and the spread-observer project.

Exec, ExecHotkey and GetHotkeyScript: reading versus running

See Advanced pages 37–38 for these distinctions. In practice, a one-line call can conceal many operations in another hotkey. Follow the name and read that body too, especially for account changes, quantity changes, submission or cancellation.

A maintainable arrangement separates input preparation, checks and reporting, with clear names and expected results. After changing a shared helper, revisit every entry point that calls it. The script-modules lesson develops that approach.

Order Objects V2: shorter writing, complete inspection

An order object separates construction from submission. V2 adds a compact notation, but fills some omitted information from the default Order Template and documents default side/type behavior. See V2 pages 1–2. Copying a short script into a differently configured installation can therefore produce a different order.

Expand the full intent during review: account, symbol, side, quantity, route, type, relevant prices and time in force. “It should use the default” is not a completed check. Changing the account before sending and changing it afterward are materially different; V2 page 5 specifically places account assignment before submission.

Continue with V2 and template inheritance. Also distinguish submission, acknowledgement, partial fill and full fill. Reaching the last line of a script does not prove execution or an active linked protection order; the order-lifecycle lesson examines those stages.

A hotkey cannot remove the conditions of a trade

When learning order scripts, it is tempting to classify every failure as syntax. Session, routing, account permissions, borrowing, price restrictions or a halt can also matter. Read the returned message before deciding which layer failed.

For short-sale preparation, read Locate alongside SSR. A borrowing arrangement does not establish that an order can execute at any price, and a written sell instruction does not establish account eligibility. For LU, LD or a volatility pause, consult LULD bands and pauses instead of diagnosing the situation by repeatedly firing the same hotkey.

The FennEdge glossary is a quick reference for these terms. They explain context; the broker and trading system’s current responses determine what happened to the specific order.

Put DAS inside the wider trading workflow

Before preparing a hotkey, establish why a stock deserves your attention. Start with FennEdge Scanner to find candidates for further research, then use FennEdge Research to examine news, disclosures and company context. Keep facts, source times and unanswered questions together.

As you organize observations in FennEdge Desk, retain the script name, version and important settings too. Actual order operations take place in DAS. Afterward, compare broker records with your original intent to distinguish a research judgment from an order-parameter or execution problem.

Use the trade-record and review approach in FennEdge Journal with its currently supported data inputs. This article does not imply automatic DAS synchronization or script execution by FennEdge. The day-trading workflow guide explains the roles of the different tools.

A first week that produces something useful

First, complete the fixed-number exercise and record its normal and two invalid-input cases. Next, name a window and inspect the symbol its object points to. Then examine prepared ticket fields in simulation. Add a stoppable observation event afterward, and approach order objects last. Introduce one behavior-changing factor at a time.

Keep a short experiment record: client version, account environment, script, dependent settings, expected outcome and observed outcome. Include window switching, repeated runs and restart behavior. When something goes wrong, that record gives you a specific place to investigate.

Begin with building your scripting workspace or consult the DAS API reference for a particular entry point. The first two FennEdge lessons are open to read; the remaining full lessons require sign-in. Build a small tool you can explain and inspect, then extend it.