Support Board
Date/Time: Tue, 29 Sep 2026 17:25:52 +0000
[Programming Help] - ACSIL: letting a custom study use a left-button drag without scrolling (Pointer/Hand tool)
View Count: 32
| [2026-09-29 13:22:04] |
| Fabio - Posts: 152 |
|
Hello SC support, I hope this email finds you well. My Sierra Chart version: 2953 WHAT I AM BUILDING A custom ACSIL order-entry study. The user arms it with a Custom Study Control Bar button, then on the chart presses the left mouse button at the stop price, drags, and releases at the entry price. The study sizes the position from the stop distance and sends the order. The active tool during normal use is Tools >> Pointer (or Hand). THE PROBLEM With Pointer or Hand active, the left-button drag scrolls the chart. The study does receive the pointer events (sc.ReceivePointerEvents set to ACS_RECEIVE_POINTER_EVENTS_WHEN_ACS_BUTTON_ENABLED, and also tried ACS_RECEIVE_POINTER_EVENTS_ALWAYS), but it cannot stop the chart from scrolling, so the price under the pointer never changes and the drag is unusable. With Tools >> Chart Values active, the same drag works perfectly (no scrolling). WHAT I TRIED 1. Switching the tool from the study to Chart Values when the button is pressed, and back to Pointer afterwards: - sc.SetChartDrawingTool(DRAWING_TOOL_CHART_VALUES) returns 1, but sc.CurrentlySelectedDrawingTool does not change. - sc.SetActiveDrawingTool(sc.ChartNumber, DRAWING_TOOL_CHART_VALUES, 0) returns 0. Same result with the last parameter set to 1. - Both were called on every normal study update for 1.5 seconds after arming, both with the Control Bar button enabled and after disabling it from the study. The tool never changed. - For reference, sc.CurrentlySelectedDrawingTool reports: Pointer = 0, Hand = 52, Chart Values = 2 (these differ from the DRAWING_TOOL_POINTER = 10 / DRAWING_TOOL_CHART_VALUES = 22 / DRAWING_TOOL_HAND = 23 enum values). 2. sc.BlockChartDrawingSelection = 1 while armed: prevents drawing selection but not scrolling. CURRENT WORKAROUND (works, but unsupported) While the study is armed, it subclasses the chart window (SetWindowLongPtr on sc.ChartWindowHandle): it swallows WM_LBUTTONDOWN / WM_LBUTTONUP and removes MK_LBUTTON from WM_MOUSEMOVE, so Sierra Chart never starts its own drag. The original window procedure is restored as soon as the study disarms, on sc.LastCallToFunction and on full recalculation. I would prefer a supported method. QUESTIONS 1. Is there a supported way for a custom study to take over a left-button drag on the chart (like the built-in drawing tools do), so the chart does not scroll, while Pointer or Hand is the selected tool? 2. What is the correct usage of sc.SetChartDrawingTool and sc.SetActiveDrawingTool to switch the active tool to Chart Values and back to Pointer? Are there conditions under which they are ignored (for example when called from a study, or while a Custom Study Control Bar button is enabled)? 3. If there is no supported method: is temporarily subclassing the chart window from a study safe, or are there known problems we should be aware of? Thank you very much for your help. Regards, Fabio. |
| [2026-09-29 16:39:50] |
| User719512 - Posts: 491 |
|
Maybe consider this design as an alternative to taking over left-button drag while Pointer/Hand is active. Instead of arming a custom study and dragging stop → entry yourself (which fights chart scroll under Pointer/Hand), lean on Sierra’s built-in Reward/Risk drawing tool for the geometry, then have a small ACSIL study turn that drawing into an order action. Flow 1. User draws a normal Reward/Risk chart drawing (stop / entry / target as usual). 2. User selects that drawing. 3. User right-clicks the chart and chooses a custom Chart Shortcut Menu item added by the study (e.g. “Execute Trade from Risk/Reward”). 4. On sc.MenuEventID, the study calls sc.GetSelectedUserDrawnDrawingFromChart(sc.ChartNumber, ChartDrawing). 5. If ChartDrawing.DrawingType == DRAWING_REWARD_RISK, read the levels from s_UseTool and build/send the trade (or for a POC, just AddMessageToLog them). Reward/Risk field mapping (ACSIL) • BeginValue → Stop • EndValue → Entry • ThirdValue → Target Side can be inferred from entry vs stop (entry above stop → long, below → short). Why this may be simpler for order entry • No need to suppress chart scrolling, switch tools to Chart Values, or subclass sc.ChartWindowHandle. • Uses documented APIs: AddACSChartShortcutMenuItem / RemoveACSChartShortcutMenuItem, MenuEventID, and GetSelectedUserDrawnDrawingFromChart. • The user still gets interactive stop/entry/target placement with Sierra’s own drawing tool (adjust handles, labels, R:R, etc.). • The study only runs the “execute” step when the menu item is chosen. Tradeoffs vs your drag-to-order UX • Not a single left-drag gesture under Pointer/Hand. • Requires an explicit select + right-click menu step. • Relies on Reward/Risk being the selected user drawing when the menu item is clicked. If the goal is “define stop/entry/target visually, then fire a sized order,” this path avoids the unsupported window-subclass workaround. If the goal is specifically “armed Control Bar button + left-drag while Pointer stays selected,” then you still need an answer to your original scroll/tool questions — this is just a different product shape that sidesteps that problem. |
To post a message in this thread, you need to log in with your Sierra Chart account: