Home >> Support Board

Support Board

Date/Time: Sun, 18 Oct 2026 11:12:15 +0000

How to Post a Message for Support

[Programming Help] - ACSIL Study for Automated Trading kicked off more than safeguard allowed

View Count: 732

[2026-09-02 21:48:07] #1 [Go To First Post]
User158823 - Posts: 40
The study contains many safeguards, the main of which is only ever allow 1 open trade at a time. I just went live with it today. At ~3:43 PM EST today, 02-SEP-2026, it shot off a 12 contract limit trade when it is only coded to ever fire market orders with stop and target brackets and only 1 trade3 at a time, but these were not market orders and they sat until price pulled back to them and they were triggered. I had the auto trading strategy running on one instance, while I was manually working in the same contract on my main instance. I'm looking to understand why multiple sitting orders were fired off from my strategy rather than market orders? Why 12 orders were allowed to kick off? Why many more orders were initiated but rejected? And what I can do to avoid this in the future. I'm running SC on Windows 11 Pro. Please let me know if you need me to provide additional material. Thank in advance. Regards, Gary Francis Mohamad [Phone Number Removed for Privacy] Date Time Of Last Edit: 2026-09-02 21:53:29

[2026-09-03 02:20:59] #2 [Go To First Post]
User158823 - Posts: 40
So, I investigated this further. My strategy's own logic could not have generated it — Trend-Follow was disabled, Fade mode requires price near session high/low (it wasn't), and I did not trigger the strategy's manual test-order feature. I believe this originated from orphaned/duplicate resting orders left over from an earlier rate-limit rejection cascade, compounded by running 3 Sierra Chart instances live on the same account and two on the same symbol simultaneously. I'm not sure what happened but it should be investigated. Again, please let me know how I can assist. Regards, Gary

[2026-09-03 08:40:54] #3 [Go To First Post]
User431178 - Posts: 909
I am not support, just another user. The study contains many safeguards, the main of which is only ever allow 1 open trade at a time. I just went live with it today. At ~3:43 PM EST today, 02-SEP-2026, it shot off a 12 contract limit trade when it is only coded to ever fire market orders with stop and target brackets and only 1 trade3 at a time, but these were not market orders and they sat until price pulled back to them and they were triggered. So your safeguards do not work as intended. Are you certain that there is no programming/logic error? I'm looking to understand why multiple sitting orders were fired off from my strategy rather than market orders? Why 12 orders were allowed to kick off? Why many more orders were initiated but rejected? And what I can do to avoid this in the future. Do you have the code, or someone wrote it for you and only gave the dll? Date Time Of Last Edit: 2026-09-03 08:41:16

[2026-09-03 13:51:36] #4 [Go To First Post]
User158823 - Posts: 40
Hi User431178, Thanks for reaching out. Please find a santized version of the strategy/study attached. I designed it, performed code walk through and vetted code logic, tested it, and QC'ed it. I had an AI Chat Agent develop it. Please know ... The order that was placed was a Trigger Buy Limit order with bracket, not a market order with brackets. I saw the order "sit" on the DOM, the orange open badge and trigger (also orange badge), with brackets. I tried cancelling with Alerts firing off incessantly but the cancel had no effect. Watched it hit and I guess the rate limiter finally throttled, as I was able to flatten the trade for a small profit, thankfully. My code will only fire a market order. This order was the exact setup from my chart and DOM trade window but what seemed like a OOTB initial trigger off of price.


Gary Strat.txt - Attached On 2026-09-03 13:51:30 UTC - Size: 18.14 KB - 39 views

[2026-09-03 17:52:01] #5 [Go To First Post]
cmet - Posts: 743
While you're waiting for User431178, check your Trade Activity Log, specifically the Order Action Source. Look for the triggered limit orders. Should give you an idea where those came from. Not sure what was removed from your posted code, but nothing in there explains what happened. There is no submission path for those limit orders.

[2026-09-03 18:02:09] #6 [Go To First Post]
User431178 - Posts: 909
Yes, do as cmet says and check the logs, that will give you good info. The way you describe in your last post does not seem to track with what you wrote earlier either. I had the auto trading strategy running on one instance, while I was manually working in the same contract on my main instance. I believe this originated from orphaned/duplicate resting orders left over from an earlier rate-limit rejection cascade, compounded by running 3 Sierra Chart instances live on the same account and two on the same symbol simultaneously. The order that was placed was a Trigger Buy Limit order with bracket, not a market order with brackets. I saw the order "sit" on the DOM, the orange open badge and trigger (also orange badge), with brackets. I tried cancelling with Alerts firing off incessantly but the cancel had no effect. The item cmet says will help narrow it down.

[2026-09-03 18:53:35] #7 [Go To First Post]
User158823 - Posts: 40
According to the TAL, they were all opened with Limit orders and closed with one market order, which was the Flatten I initiated. I don't think trigger prices show on the TAL but either way, there was no 'Price 2'. Also, for each of the 12 single lot orders, the value for IsAutomated is EMPTY. The Trade Service Log was inundated with logs at this time, especially 345 pairs of rejection and rate limit reached log entries of this type: ------------------------------------------------ 2026-09-02 15:44:03.887 \| Teton CME Routing (Order reject). Info: There is no parent order for child OCO order. Internal Order ID: 1294. Service Order ID: (none). Symbol: ESU26_FUT_CME. Account: xxx * 2026-09-02 15:44:04.143 \| Teton CME Routing (Order reject). Info: Message rate limit reached. Internal Order ID: 1295. Service Order ID: (none). Symbol: ESU26_FUT_CME. Account: xxx * ------------------------------------------------ Let me know if you'd like me to share. The only thing I removed from that code was the logic for identiying Long and short opportunities. Gary. Date Time Of Last Edit: 2026-09-03 20:03:45

[2026-09-03 20:49:07] #8 [Go To First Post]
cmet - Posts: 743
Post Trade Activity Logs for all 3 live instances (with all columns) during the time this took place.

[2026-09-03 20:56:32] #9 [Go To First Post]
User158823 - Posts: 40
Thank you — the study has been cleared and its submissions are hard-coded market orders, which the Trade Activity Log confirms: every entry in the burst was a Limit order, which this study cannot submit. The burst instead consisted of limit parents tagged '1 ES with Auto BE+3Trg5.twconfig'; the IsAutomated column is blank for all of them (i.e., none are flagged as submitted by an automated trading system). The Trade Activity Log confirms the surviving orders were 12 separate 1-lot parents — not one 12-lot: Internal IDs 590, 593, 596, 599, 602 at 7679.00 (filled 15:46:09), then 1298–1316 at 7678.75 (filled 15:46:15), each parent carrying attached stop/target legs. The exit was a single 12-lot market order (Internal ID 1370) at 15:46:31. Two additional observations that may help locate the mechanism: 1. The rejected submission storm (Internal IDs 605–1369) repeated at a metronomic ~250ms cadence for ~9 seconds — parent rejected with 'Message rate limit reached,' then its two attached orders rejected with 'There is no parent order for child OCO order' — repeating in clusters of three. This signature suggests an automated retry loop, not manual input. No input automation was active during the window. 2. Normally, Buy/Sell Triggered Limit orders and plain limit orders display red or green once placed; orange appears only during the trigger-leg setup phase, before an order is confirmed. Yet these orders displayed as ORANGE badges on the DOM (at 7678.75 and 7679.00) while resting and while filling. This suggests the Trade Window treated them as orders stuck in an incomplete trigger-setup state. I therefore suspect the resubmission loop originates from the Trade Window's Triggered Limit / attached-order (Auto-BE) path retrying an order whose setup never reached a confirmed state after a 'Message rate limit reached' rejection. Questions: 1. What Sierra Chart mechanism resubmits a rejected Trade Window parent + its attached OCO children on a ~250ms timer? 2. Is there a setting or fix in the Trade Window attached-order / Auto-BE handling to prevent bracket-resubmission loops after a 'Message rate limit reached' rejection — and if it's a fix, which build includes it? Attached: Trade Service Log, Trade Activity Log>Trades and Trade Activity Log>TradeActivity for 02-SEP-2026. Thoughts? I just want to understand what may have triggered for this unexpected, unweldcomed event. Thank you so much for your patience and efforts. Kind regards, Gary Francis Mohamad


TradeServiceLog_2026-09-02_burst_SANITIZED.txt - Attached On 2026-09-03 20:55:28 UTC - Size: 156.77 KB - 33 views TradesTab_ESU26_2026-09-02_pnl_SANITIZED.txt - Attached On 2026-09-03 20:55:45 UTC - Size: 3.54 KB - 31 views TradeActivityLog_ESU26_2026-09-02_fills_SANITIZED.txt - Attached On 2026-09-03 20:55:58 UTC - Size: 5.58 KB - 37 views

[2026-09-03 22:05:15] #10 [Go To First Post]
Sierra_Chart Engineering - Posts: 25206
Questions: 1. What Sierra Chart mechanism resubmits a rejected Trade Window parent + its attached OCO children on a ~250ms timer? 2 There is no such functionality in Sierra Chart to resubmit an order. Only your trading system could do that. To determine the origin of an order, refer to: Trade Activity Log Analysis: Determining the Origin of a New/Modified Order No, this does not exist. Your trading system must not be repetitively submitting orders: 2. Is there a setting or fix in the Trade Window attached-order / Auto-BE handling to prevent bracket-resubmission loops after a 'Message rate limit reached' rejection — and if it's a fix, which build includes it? And this whole thread, gives us very great concern. We are requesting that you stop what you are doing and only test with Trade Simulation Mode. You are running the risk of financial penalties from the exchange with what you are doing with live trading. They will impose penalties, we have seen it before. You are doing something that is inherently unsafe. And we do not know what you are doing in the trading system to cause this condition: 2026-09-02 15:44:03.887 \| Teton CME Routing (Order reject). Info: There is no parent order for child OCO order. Internal Order ID: 1294. Service Order ID: (none). Symbol: ESU26_FUT_CME. Account: xxx * It should not be possible for that condition to exist where there is a child OCO order with no parent. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2026-09-03 22:07:11

[2026-09-03 22:12:06] #11 [Go To First Post]
cmet - Posts: 743
Those don't show the actual order submission. Trade Activity > All Activity > Export Good advice from Engineering. Something is creating those orders.

[2026-09-04 01:53:05] #12 [Go To First Post]
User158823 - Posts: 40
Hi <I wish I had a name :-) The strategy had been disabled by me in the midst of that single hectic occurrence and I have had it running on SIM starting a few hours after the incident. This has been the first timne I had ever experienced this sort of hiccup. The strategy was running on daily including overnight on SIM for a couple of weeks before I turned it live. Please know, it gave me pause, grave concern too, and quite likely more gray hair, which is why I reached out immediately to you to make you aware and seek the guidance of a critical eye, as you have been doing, and for which I am grateful. Please let me know what else I can do. The 1st step towards that end is having that study (trading system) on SIM ONLY .... DONE! I wasn't planning on turning that auto trading strategy live or any other for that matter until I got to the heart of the matter: the cause of the incident. I am consevative by nature. I wouldn't purposely do anything inherently unsafe with a system that is shepherd to my money, nor any other reason. That said, I have followed the link above, and, as well, cmet's instructions and attached the 'All Activity' export. I limited it to the day of the issue, 02-SEP-2026 but will gladly expand, export and forward as needed. I am also providing the full study .cpp and the .dll. Aside from that, may I know if there is an issue having multi-instances open, one for 2 chartbooks, ES and MES, the other also for 2 chartbooks, NQ and MNQ, both using the same live account? Also, for automated strategies, should they not run on the same symbol that one is manually monitoring on an differnt instance? When this happened I was manually monitoring ES on my main instance and turned the study LIVE at 2:30 PM EST 02-SEP-2026 on subinstance 3. The issue kicked off about 3:43 PM EST 02-SEP-2026. No signals surfaced via the automated study during that time window. I confirmed that after the fact that evening backtesting. Initially, I thought it was the automated study that issued the orders but after digging I saw IsAutomated as "N" or BLANK and observed (made sense) that the orders were LMT orders not market orders. Additionally, I use AutoHotKey scripts for the purpose of setting single keystrokes for trading shortcuts that in effect simply call specific SC keystroke shortcuts as customized via 'customize Keyboard shortcuts' under global settings using one single keystroke -- the numpad keys 0 - 9, ., =. I tested those single key shortcuts in SIM for weeks before I turned it on live and even then, I haven't used it for live trading because I haven't been trading much but when I do, I tend to use my mouse -- I am more or less filling out the end of my near 4 months of screen time for order flow DOM trading. I hope that makes sense. More info: I use a logitech mouse - M720 Triathlon I use a logitech keyboard - MX Mechanical I use logi options+ to program the mouse buttons and action ring. I am running SC on Windows 11 Pro My rig: Device name MSI Raider 2025 Processor AMD Ryzen 9 9955HX3D 16-Core Processor (2.50 GHz) Installed RAM 96.0 GB (93.6 GB usable) Graphics card NVIDIA GeForce RTX 5080 Laptop GPU (16 GB) AMD Radeon(TM) Graphics (2 GB) Storage 2 SSD's at 1 TB each System type 64-bit operating system, x64-based processor Monitors Laptop screen (3840 x 2400 at 200% scale) Dell (2560 x 1440 at 100% scale) Sceptre Ultrawide (5120 x 1440 at 100% scale) I am hard wired by ethernet CAT 6 to the internet. I occassionally log in remotely via Chrome Remote Desktop. I use Proton VPN (off when trading) but on when remote logging in via my phone Samsung Galaxy FOLD 7 I use Bit Defender as my AV software. Thank you kindly in advance. Looking forward to your informative response. Warm regards, Gary Francis Mohamad Date Time Of Last Edit: 2026-09-04 13:12:06


TradeActivityLogExport_for_2026-09-02 for account 225028.txt - Attached On 2026-09-04 01:28:05 UTC - Size: 691.48 KB - 32 views AdaptiveRegimeStrategyBACKUP.cpp - Attached On 2026-09-04 01:28:30 UTC - Size: 39.49 KB - 42 views Private File

[2026-09-04 02:55:56] #13 [Go To First Post]
User158823 - Posts: 40
Hi again, For transparency and completeness, please find attached two files: (1) AdaptiveRegimeStrategy_64_INCIDENT_REBUILD.dll — a fresh build compiled from the exact incident-era source (AdaptiveRegimeStrategyBACKUP.cpp, already provided) and (2) a screenshot of the build-service output confirming that build. To be fully transparent: the .dll in my earlier message was mistakenly a later post-incident build, and the original deployed binary was overwritten during post-incident development, so this attached rebuild replaces it. Please disregard the earlier .dll. The .cpp remains the authoritative artifact for review. Thanks. Kind regards, Gary


Private File AdaptiveRegimeStrategy_INCIDENT_REBUILD screenshot 03-SEP-2.jpg / V - Attached On 2026-09-04 02:54:50 UTC - Size: 137.77 KB - 26 views

[2026-09-04 03:03:59] #14 [Go To First Post]
User158823 - Posts: 40
Hi Engineering, To be certain I fully comply: does your request apply to all live trading on this account — including my normal manual order-flow trading on the DOM — or specifically to the automated strategy and multi-instance setup pending identification of the cause? I will follow whichever you specify. Thanks. Gary

[2026-09-04 03:07:34] #15 [Go To First Post]
cmet - Posts: 743
These were user entered orders on chart #1. Too fast for a human, but not from your strategy. From what you've posted above, if you don't have any other programmed order entry on chart 1, my guess is it was due to your hot key setup/macros. ie: something mapped to Buy Limit was pressed/held/repeated very rapidly for that time period. Note: The chances a problem like this is due to the Sierrachart platform is effectively zero. No way something like this would make it into a release build. Date Time Of Last Edit: 2026-09-04 03:23:12

[2026-09-04 03:42:45] #16 [Go To First Post]
User158823 - Posts: 40
Thanks for quick response, cmet. Following up on the hotkey hypothesis, I'm attaching my complete automation footprint so everything can be reviewed in one place: 1. SierraChart_HotKeys_Master.ahk — my only hotkey script. Facts relevant to the held-key hypothesis: every hotkey is a single-fire mapping to one Sierra Chart customized keystroke shortcut (numpad 0–9, ., =). There are no loops, no timers, no Send/repeat constructs anywhere in the script. At the time of the incident I was not using the numpad layer — my manual trading is mouse-on-DOM. 2. Sierra Chart Desktop Switcher.ahk — manages virtual desktops and re-enables script 1 on focus changes. It contains no input injection into Sierra Chart (no Send/SendInput/ControlSend); its only timer is a 2.5-second one-shot tooltip cleanup, and its only PostMessage targets my own AHK script's suspend menu. 3. LogiKeepAliveActionsRing.ps1 — a watchdog restarting the Logi Options+ background agent (every ten min; set to five min at incident time) because the Actions Ring plugins hang. It only kills/relaunches named Logitech processes — no keystroke synthesis, no interaction with Sierra Chart. Along with the strategy .cpp/.dll already provided, this is everything running on my system. On cadence specifically: accounting for the OCO children (per the TAL, each retry is a parent + attached children tagged to my twconfig), the burst represents ~14 parent submissions per second sustained over ~9 seconds — faster than Windows key-repeat (~30/s ceiling on a held key, producing identical single events) and impossible for a mouse button, which does not auto-repeat. If review of these scripts shows anything that contradicts this, please, I want to know. If they're clean, my remaining lead is the Trade Window trigger-setup path — the resting orders showed as orange badges (trigger-setup color) rather than red/green placed-order colors, suggesting an incomplete trigger-arm transaction at the moment the burst began. I'm also happy to run a SIM session with all of these scripts exited if that would help isolate the cause. Thank you kindly. Warm regards, Gary Date Time Of Last Edit: 2026-09-04 03:58:25


Private File Private File Private File

[2026-09-04 03:57:59] #17 [Go To First Post]
User158823 - Posts: 40
One more batch coming and that is the last of my always running ahk scripts. 4. SetMainDisplay.ahk — a primary-display switcher. Six single-fire hotkeys (Ctrl+Alt+1/2/3, plus the numpad equivalents) each run one command-line call to MultiMonitorTool to set which of my three monitors is primary. No input injection, no timers, no loops, no interaction with Sierra Chart. 5. show SC Global Keyboard Shortcuts.ahk — Simply "shows, always on top/unshows" and increases/decreases size of jpeg, a cheatsheet of the SC shortcut key mappings. Date Time Of Last Edit: 2026-09-04 04:02:48


Private File Private File

[2026-09-04 04:02:22] #18 [Go To First Post]
User158823 - Posts: 40
6. Show Candlestick Cheatsheet 1 Win Shift j.ahk — Simply "shows, always on top/unshows" and increases/decreases size of jpeg, a Candlestick Cheatsheet 1 of popular candlestick patterns. 7. Show Candlestick Cheatsheet 2 Win Shift k.ahk — Simply "shows, always on top/unshows" and increases/decreases size of jpeg, a Candlestick Cheatsheet 2 of popular candlestick patterns. 8. Show Candlestick Cheatsheet 3 Win Shift l.ahk — Simply "shows, always on top/unshows" and increases/decreases size of jpeg, a Candlestick Cheatsheet 3 of popular candlestick patterns. That's all of mine productivity helpers. Gary Date Time Of Last Edit: 2026-09-04 04:03:18


Private File Private File Private File

[2026-09-04 04:06:24] #19 [Go To First Post]
User158823 - Posts: 40
Man, I'm pooped: going to bed. Thank you for bearing with me so graciously. Gary

[2026-09-04 04:07:35] #20 [Go To First Post]
cmet - Posts: 743
Those files are private. The "retries" you're referring to are new orders being created. In the end, something is creating new orders. I've looked into this as much as I can though. Perhaps someone else can dive deeper.

[2026-09-04 14:22:04] #21 [Go To First Post]
User158823 - Posts: 40
Hi Engineering, Bringing this to the fore :-) ... To be certain I fully comply: does your request apply to all live trading on this account — including my normal manual order-flow trading on the DOM — or specifically to the automated strategy and multi-instance setup pending identification of the cause? I will follow whichever you specify. Thanks. Gary

[2026-09-04 14:54:29] #22 [Go To First Post]
User431178 - Posts: 909
None of the orders are marked as Automated and all have the source as "User Order Entry", this suggests that they all come from trade window/chart interaction. I'd expect orders from your system to have both the Automated flag set in the activity log, and the the source (in the Order Action Source column) would begin with "Auto Entry:". If the orders weren't from the bot, the question then moves to the autohotkey scripts - are you 100% sure that there is no action that would continuously send keys that trigger some order action? Do you have any debounce requirement in the ahk script, so a stuck/held key or button cannot send multiple messages? If review of these scripts shows anything that contradicts this, please, I want to know. If they're clean, my remaining lead is the Trade Window trigger-setup path — the resting orders showed as orange badges (trigger-setup color) rather than red/green placed-order colors, suggesting an incomplete trigger-arm transaction at the moment the burst began. I'm also happy to run a SIM session with all of these scripts exited if that would help isolate the cause. The "orange badges" are most likely because the orders are sat pending (especially once you'd been rate limited). Date Time Of Last Edit: 2026-09-04 14:54:49

[2026-09-04 15:31:21] #23 [Go To First Post]
User158823 - Posts: 40
Hi User431178, I'm quite certain the autohotkey scripts have no loops, no timers, no send/repeat constructs anywhere in the script. At the time of the incident I was not using the numpad layer — my manual trading is mouse-on-DOM. Happy to paste the others .ahk codes here. They are short & to the point. There sole purpose is to ease manual entry as productivity boosters/helpers. This is the only one that directly interacts with Sierra Chart, meaning input-wise Hope it helps. SierraChart_HotKeys_Master.ahk #Requires AutoHotkey v2.0 #SingleInstance Force ; ============================================================================== ; HIGH-PRIORITY / LOW-LATENCY OPTIMIZATIONS ; ============================================================================== ProcessSetPriority("High") ListLines(False) KeyHistory(0) SetKeyDelay(-1, -1) SendMode("Input") ; ============================================================================== ; MASTER ON/OFF TOGGLE SWITCH (Exempt from Suspension) ; ============================================================================== #SuspendExempt ; All hotkeys below this directive are exempt from Suspend ^!Space::Suspend(-1) #SuspendExempt False ; Resume standard suspension rules for subsequent hotkeys ; ============================================================================== ; SIERRA CHART EXCLUSIVE HOTKEYS ; ============================================================================== #HotIf WinActive("ahk_exe SierraChart_64.exe") or WinActive("ahk_exe SierraChart.exe") ; --- SELL ORDERS (NUMPAD TOP ROW) --- Numpad7::SendInput("^a") ; Sell Market (Ctrl + A) Numpad8::SendInput("!a") ; Sell at Ask (Alt + A) Numpad9::SendInput("+a") ; Sell Limit at Cursor (Shift + A) ; --- BUY ORDERS (NUMPAD MIDDLE ROW) --- Numpad4::SendInput("^d") ; Buy Market (Ctrl + D) Numpad5::SendInput("!d") ; Buy at Bid (Alt + D) Numpad6::SendInput("+d") ; Buy Limit at Cursor (Shift + D) ; --- Sell AT ASK OFFSETS --- Numpad1::SendInput("^1") ; Sell at Ask + 1 (Ctrl + 1) Numpad2::SendInput("^2") ; Sell at Ask + 2 (Ctrl + 2) [Overrides ZoomIt Draw] Numpad3::SendInput("^3") ; Sell at Ask + 3 (Ctrl + 3) ; --- BUY AT BID OFFSETS --- Numpad0::SendInput("!1") ; Buy at Bid - 1 (Alt + 1) $NumpadDot::SendInput("!2") ; Buy at Bid - 2 (Alt + 2) NumpadEnter::SendInput("!3") ; Buy at Bid - 3 (Alt + 3) ; --- ORDER MANAGEMENT & PANIC --- NumpadDiv::SendInput("!``") ; Flatten Position (Alt + `) NumpadMult::SendInput("^``") ; Cancel All Orders (Ctrl + `) ; --- STOP & TARGET MANAGEMENT --- $Space::SendInput("^{Space}") ; Spacebar -> Move to Break Even (Ctrl + Space) ;Ins::SendInput("^{Space}") ; Insert -> Move to Break Even (Ctrl + Space) Up::SendInput("^{Up}") ; Up Arrow -> Move Stop Up 1 Tick (Ctrl + Up) Down::SendInput("^{Down}") ; Down Arrow -> Move Stop Down 1 Tick (Ctrl + Down) Right::SendInput("^{Right}") ; Right Arrow -> Move Target Up 1 Tick (Ctrl + Right) Left::SendInput("^{Left}") ; Left Arrow -> Move Target Down 1 Tick(Ctrl + Left) #HotIf ; End window restriction

[2026-09-04 15:34:32] #24 [Go To First Post]
User158823 - Posts: 40
If it will get be back to live trading, I'll kill all the .ahk scripts. That said, I can't believe I'm such a genius user leveraging autohotkey scripts to glean some sort of crude-edge. Gary

[2026-09-04 15:58:13] #25 [Go To First Post]
cmet - Posts: 743
Numpad6::SendInput("+d") ; Buy Limit at Cursor (Shift + D) Would be a prime suspect. Technically, these could have also generated Buy Limit parent orders: Numpad5::SendInput("!d") ; Buy at Bid Numpad0::SendInput("!1") ; Buy at Bid - 1 $NumpadDot::SendInput("!2") ; Buy at Bid - 2 NumpadEnter::SendInput("!3") ; Buy at Bid - 3 Key History was 0, so impossible to tell for sure what this was. If you are going to use these scripts, KeyWait is probably a good idea. To reiterate, something rapidly created new parent orders. Nothing in Sierra does that without user programming or interaction.

To post a message in this thread, you need to log in with your Sierra Chart account: