- ago
In WL6, we could test
CODE:
if (ChartStyle == null)

to determine if a strategy has an open Chart window. How do I do that in WL7? I this going to be a WPF operation?

I do a great deal of messaging (fundamental stats) on the Chart window itself because I step through my watch list with a Chart. But if the Chart window isn't showing, I don't want to execute all the messaging and fundamental code.
0
442
10 Replies

Reply

Bookmark

Sort
- ago
#1
Imagine how easier would the development get if only you had say a monthly subscription! :)
0
- ago
#2
QUOTE:
... if only you had say a monthly subscription!

I'll go for the premium subscription eventually. I wouldn't be coding and asking WL7 questions in the first place unless I was serious about WL7.

But none of my strategies will work until I convert all my code libraries. And they all have tricky and weird problems. Only some of those problems involve the WL7 interface.

And to do any "new" development with WL7 (like ScoreCards and Visualizers), I also have to learn WPF. So there's a great deal on my plate. But with the PreExecute() procedure of WL7, which empowers the simulation to scope the entire dataset for the very best opportunities, WL7 has great potential. And that advanced architecture kind of obsoletes 2 of 3 of my WL6 strategies.
1
- ago
#3
Anyway, what about the answer to my original question (of two years ago)? How can I determine if a Chart window is open or not? The code below works when the strategy is in single-symbol mode fine. But when I step through a stock dataset one-stock-at-a-time while in Portfolio Backtest mode, it doesn't return "true" when the Chart window is open. How should I correct the If statement (below) to fix that? I want it to work like it does in WL6 of the original post.

CODE:
   if (ExecutionDataSetName == null) //only show Chart stats in single-symbol mode    {       . . .    }
0
Glitch8
 ( 7.81% )
- ago
#4
Use the Backtester.ExecutionMode property.
0
- ago
#5
Can I assume the Backtester.ExecutionMode property and UserStrategyBase.ExecutionMode property are one of the same?

If the (UserStrategyBase.ExecutionMode == StrategyExecutionMode.Strategy) is true, does that automatically mean the Chart window is open for the one stock in the dataset that's being currently displayed? And false for all the other stocks in the dataset?
0
- ago
#6
The code below isn't working.
CODE:
   if (Backtester.ExecutionMode == StrategyExecutionMode.Strategy)    {       WriteToDebugLog("Chart window opened");    }
When I run the strategy in Portfolio Backtest mode, it trips on every stock in the dataset when I only want it to trip on the stock with an opened Chart window. How do I fix this? It should work like it does in WL6 (original post).
0
Glitch8
 ( 7.81% )
- ago
#7
There's no way to determine which particular chart symbol is open. WL8's backtesting system is decoupled from the UI.
0
- ago
#8
QUOTE:
WL8's backtesting system is decoupled from the UI.

I appreciate that WPF runs on a different "thread" (i.e. different dispatcher process) than the client application. But can't you query WPF for its state to see what stock is loaded onto the Chart?

When you step through the stocks in a dataset, is that strictly under the control of WPF code without the involvement of the application code?

I use the Chart to display a lot of fundamentals, which are not part of the strategy itself. I want to avoid querying the event servers for this data unless I'm looking at it.
0
Glitch8
 ( 7.81% )
- ago
#9
Yes it’s completely decoupled. I’m sorry but the level of integration between the backtesting engine and the UI is just not supported.
0
- ago
#10
So it's way too complicated to do with the backtester. Well, thanks for the clarification. I guess I'll have to resort back to the Reply# 3 way then. Bummer. :(

For WPF, Microsoft wanted to put it on a real-time dispatcher so it could make GUI updates in real-time from a real-time network I/O feed. You can see this in Active Trader Pro (ATP) where all the controls update in real-time independent of the ATP application. It's a neat approach, but decoupling WPF from the application has its drawbacks.
0

Reply

Bookmark

Sort