DAS Hotkey Load vs Send: Every Order Field Explained
A complete order intent includes more than price and shares.
An order has an identity
Before reading a trading script, list account, symbol, side, quantity, order type, route, price and time in force (TIF). Missing fields may inherit the Montage's current inputs. Review inherited values as carefully as explicit ones.
A deliberately incomplete preview
Legacy command fragment · changes UI · does not submit by itself. Focus a simulator Montage with its account and symbol confirmed. The numbers are fictional. This is a field-loading exercise, not a complete order template.
Price=12.50;
Share=10;
BUY=Load;
Inspect the resulting fields, side, route and TIF without pressing Enter. Account, symbol, route and TIF are deliberately omitted so you can identify inherited state. Do not promote this fragment to an execution script.
| Token | Effect to review |
|---|---|
Price |
Writes the intended price; meaning depends on order type |
Share |
Sets order quantity, not current position |
ROUTE |
Must match the broker/account's supported route |
TIF |
Controls order duration/session eligibility |
BUY=Load |
Loads the order information for manual submission |
BUY=Send |
Submits a buy order; a materially different action |
Lab: expose defaults
Record the ticket before and after loading. Change the existing TIF, load again, and check which field carries over. Use your build's Order Script Wizard to generate a full simulator template, then annotate every field and every inherited dependency. Route availability and session handling require broker-specific verification.
Move from a fragment to a complete draft
A complete draft answers eight questions: account, symbol, side, quantity, order type, route, price fields and TIF. Mark each as explicitly assigned or inherited from the interface; leave no blank cells.
Load versus Send is more than a final word. Load leaves interface state that a user can submit; Send adds an external request. Both require the intended account and window, and neither guarantees broker acceptance of a field combination.
Worked answer
Changing the existing TIF before rerunning the fragment exposes a dependency: the fragment never sets TIF, so it cannot claim independence from prior state. Observe the actual inheritance behavior. Remove the dependency with a complete locally generated Wizard template or the next lesson's Order-object draft, assigning fields explicitly and inspecting them with ShowObject.
Replacing 10 with a variable does not make a draft more complete. A stale or wrong-account variable merely hides the dependency. Establish its unit, source and validity before using it in a draft.