Detecting SuperDOM window focus from an Indicator, SuperDomColumn, or AddOn

Desktop SDK - Indicators
1

Objective: to replicate the native “Move Stop to Breakeven” hotkey - plus a configurable tick offset. (feature first requested 2017). Acting on whichever SuperDOM has focus.

I’ve tried three different approaches, each hitting a different wall:

1. SuperDomColumn
From a custom SuperDomColumn, I can read SuperDom.Instrument and SuperDom.Account directly (confirmed working). But I’ve found no way to determine whether that specific SuperDOM window currently has focus:

  • this is not a DependencyObject — Window.GetWindow(this) fails to compile with CS1503.
  • SuperDom is a SuperDomViewModel, also not a DependencyObject — same CS1503 failure.
  • The official Language Reference for SuperDomColumn lists only six methods (OnMarketData, OnOrderUpdate, OnPositionUpdate, OnPropertyChanged, OnRender, OnRestoreValues) — no mouse-click or focus-related handler at all.

2. AddOnBase + Control Center menu
Separately (for a settings UI, not focus detection), I found that ControlCenter.MainMenu.Items fails to compile with CS0122 (“inaccessible due to its protection level”) — MainMenu returns an internal type. Walking the visual tree via VisualTreeHelper from ControlCenter downward does work for finding menu items by matching on visible Header text, and FindFirst("ControlCenterMenuItemNew") (an automation ID) also works reliably for attaching a custom menu item. So automation-ID-based lookups succeed on ControlCenter, but the two techniques above for identifying “which window has focus” don’t have an equivalent I’ve found for SuperDOM windows.

3. Regular Indicator applied to a SuperDOM
I found a past support answer to a similar question suggesting: “grab the window itself, find the SuperDom object, and access SuperDom.Account.” Based on that, I built an indicator that enumerates Application.Current.Windows (independent of the object itself, avoiding the DependencyObject problem) looking for a SuperDOM window matching the indicator’s own Instrument. Tested live: Application.Current.Windows.Count returns 0, consistently, even though real windows are open (Control Center, the SuperDOM itself, Charts, confirmed via other diagnostics), and even when the check runs on the UI dispatcher thread via Application.Current.Dispatcher.InvokeAsync.

My specific questions:

  1. Is there any supported, public way — from a SuperDomColumn, a regular Indicator applied to a SuperDOM, or an AddOnBase — to determine which SuperDOM window currently has focus?
  2. Why does Application.Current.Windows return an empty collection when queried from indicator/add-on code, even on the UI thread, when NinjaTrader’s own windows are demonstrably open?
  3. Is the mechanism the native “Breakeven Position” hotkey uses to route to the focused DOM internal to the platform and not exposed via the NinjaScript SDK at all?

TIA
Kind regards,
Bruce

2

Hey Bruce,

Not 100% sure this’ll transfer cleanly to SuperDOM, but might be worth trying — I built something similar for chart windows and ran into the same focus-detection issue you’re describing.

On Q2: I’d guess Application.Current.Windows coming back empty is because NT’s windows aren’t being created/registered the way vanilla WPF expects. Rather than fighting that, you could try sidestepping enumeration entirely — AddOnBase.OnWindowCreated(Window window) hands you every NT window directly as it’s created. Worth a shot instead of relying on Application.Current.Windows.

On Q1: from there, you could try casting to whatever the SuperDom window’s actual type is:

var superDomWin = window as NinjaTrader.Gui.SuperDom.SuperDomWindow; // guessing at this name, would need to confirm

I’m honestly not sure that’s the right type name — you’d want to log window.GetType().Name in OnWindowCreated with a SuperDOM open to check.

If that does give you a real Window reference, focus detection might just be standard WPF from there:

  • superDomWin.Activated += ... to catch when it gains focus (this is what I hook for charts)
  • or check superDomWin.IsActive at the moment your hotkey fires

Both are plain Window members, so in theory they’d work the same on a SuperDom window as a Chart, but I haven’t actually tested this on a SuperDOM myself, so treat it as a starting point rather than a confirmed fix.

On Q3: given the above at least works for Chart windows in my case, my hunch is the breakeven hotkey isn’t doing anything exotic internally for SuperDOM either — probably just a focus check like this. But that’s speculation on my part, not something I’ve verified against NT’s internals.

Might be worth keeping a small registry (list of SuperDom windows, pruned in OnWindowDestroyed) so you can iterate and find whichever one’s active when your hotkey fires, rather than tracking a single reference.

1 Like
3

#ShawnJones - thank you so much.

2 positives: a way to explore forward on SuperDom, & if still hit a dead-end - confidence shifting to a Chart-based solution will be worth pursuing. I really appreciate it

Kind regards,

Bruce

1 Like