- ago
QUOTE:
... a strategy which uses several orders to open, enlarge, partially close and finally close a position it would be helpful to have such a "history" for a position ...

Thanks for the clarification. Fidelity's Active Trader Pro includes such a "position history" on the Chart itself. You can use Tooltips to get more information on each trading event on the ATP Chart.

It would be nice if WL7 Charts were "broker/position aware" like ATP Charts are for trading event history. (Perhaps we're talking about a different Feature Request.) Today, I have to run both WL7 and ATP side-by-side to get this information.
0
512
10 Replies

Reply

Bookmark

Sort
Glitch8
 ( 12.77% )
- ago
#1
WL is primarily a backtesting tool, and it's showing you the theoretical positions from a backtest run. Showing the actual broker trades would be a paradigm shift and we'd need to carefully consider how it fits in with the product scope.
0
- ago
#2
QUOTE:
Showing the actual broker trades would be a paradigm shift ...

Understood. The only time I like to see "actual portfolio" historical trades is when I go to sell a position. At that point, I like to see how much a position made (or lost) when I'm about to sell it.

Yes, I know, importing historical trading data is another way to analyze this behavior. I guess I prefer to analyze it at the point of placing the final selling trade instead. That's when I'm looking over my shoulder.
0
- ago
#3
What if... you made a stanalone app (or something). That is about live trading and execution. Or maybe some kind of API so that one could make it's own app and use WL7 strategies and the power of WL7 framework. Or just more power, more flexibility and more WL7 team efforts to the live trading capability withing WL7 app.
0
- ago
#4
QUOTE:
It would be nice if WL7 Charts were "broker/position aware" like ATP Charts are for trading event history.


I think the easiest solution for this without making a paradigm shift would be to develop a custom Event provider to read the position history from the broker. Here's the API:

https://www.wealth-lab.com/Support/ExtensionApi/EventDataProvider
0
- ago
#5
QUOTE:
What if you made a stand alone app ... that is about live trading and execution.

We have one. It's called Active Trader Pro (or whatever your broker uses). What's missing is integrating the WL broker plugin (or provider) to that ATP app. These brokerage apps are missing the Windows COM hooks to make local procedure calls into them. Without that, you don't have the integration between the WL and the brokerage app.

I have thought about talking to Fidelity about adding COM hooks into ATP so a robust WL brokerage provider could be written. But that's kind of at the bottom of my List of Things To Do. I would be motivated to write a WL brokerage provider for Fidelity if ATP had COM hooks.
0
Cone8
 ( 24.08% )
- ago
#6
If you ask, don't ask for COM (Microsoft's 28-year old Component Object Model), but something of a more modern API!
0
- ago
#7
QUOTE:
... don't ask for COM, but something of a more modern API!

I know about Unix Remote Procedure Calls (RPC), but I'm not familiar with the Win32 calls on Windows. Is there some kind of Local Procedure Calls on Windows (which are an alternative to COM and DCOM) that I should look into? I'm asking for suggestions.

Also, the suggestions need to be supported by Java and its virtual machine since ATP is based on that platform.

QUOTE:
I think the easiest solution for this without making a paradigm shift would be to develop a custom Event provider to read the position history from the broker.

That's an interesting idea. So the Event provider could post a "trading" event history and setup Tooltips for those events to describe them much like the ATP Chart does for trading history. That does seem like a doable solution to me. (But I'm not interested enough to pursue this as a programming project.)
0
Glitch8
 ( 12.77% )
- ago
#8
ATP is actually written in WPF, just like WL7. Unless they completely rewrote it since I left FIdelity a couple of years ago.
0
- ago
#9
QUOTE:
ATP is actually written in WPF

That's the front (display GUI) end. What about the back end? I thought that was written in Java (but I could have heard wrong). ATP is a one-click application (which is .NET based), so perhaps it's not Java (which isn't one-click). Hmm ... I could be wrong about ATP and Java. Does anyone know for sure?

Java is a good choice for ATP because it's real-time scheduling is more tide into the language itself making it more portable without .NET. Microsoft devised C# after it was spanked by Sun Microsystems for copying Java implementations.
0
Glitch8
 ( 12.77% )
- ago
#10
I’m sure it’s WPF. I did work there so I even saw the C# code.
1

Reply

Bookmark

Sort