Hi,

I have a wired behavior in my code: The script executes well, but not my DLL which is added to the script when started as backtest but not when executed automatically

Running

Open Strategy in strategy window -> Backtest

Not Running

Strategy Monitor -> Run this strategy now / or activate strategy

For sure i can debug my my file, but i am really wondering how it can be that the script run as backtest IS also executing my DLL well, but when the script is run from strategy monitor, it is not.

Hi Mathias,

Please correct me if I'm wrong. Some unknown black box code is not running "well" if it's executed "automatically" in the SM. Either that's outside my area of expertise or my crystal ball is broken. ;) Seriously, there are simply too many unknowns.

P.S. Topic title has been edited:

WAS: Customized DLL not running automated but as backtest
IS: Custom DLL runs in SM differently than in Strategy window

Hi Eugene,

The point is that the code compiles perfectly and that i dont see a difference from compiling point of view from running in strategy window and SM..? Why should there be any difference? So if there is a bug in my code, it should not run at all. right?

To give you one example i could find: one error i did was concatenating a string with and without @ when i removed a wrong placed @, it worked in the Strategy Window, too. But it still worked when directly forced to run with pressing on backtest.

So either there IS a difference between those two or you (WL) is caching somehow these files differently?

br,
matthias

The Strategy Monitor operates with its own cached copy.

Quoting the User Guide > Strategy Monitor:

QUOTE:
The Strategy Monitor obtains its copy of the compiled strategy when it is opened. Edits in a Strategy Window do not affect strategies until the Strategy Monitor is closed and re-opened.

thank you, but this still does not explain why WL behaves different.

The Hello Dialog appears when started with backtest, but not when started from strategy monitor. Why?

That's by design. Cosmetic methods are suppressed in the Strategy Monitor and Combination Strategies to speed up execution. This includes .NET calls to methods like MessageBox and many WealthScript entities like ChartPane or PrintDebug() calls.

Hello Eugene,

I have added my WLHelper.dll incl. source. The problem is reproducable. My steps:

1. Copied WLHelper.dll to WealthLab Folder (C:\Program Files\MS123\Wealth-Lab Developer 6)
2. added the content to injectToWL.txt to my strategy code and called writeToFile() within end of Execute()
3. added using WLHelper; to my strategy code
4. added the WLHelper.dll as reference (References.. -> Other assemblies to reference -> Add a reference...)
5. saved & compiled to code (compiled well)
6. removed the strategy from strategy window, reloaded again into strategy window.

the files are written when started with backtest, but not when started from strategy monitor.

very wired..

matthias

Matthias, let's approach it from a different angle to make sure we're troubleshooting WL and not your DLL. From the QuickRef, take the Strategy code example for Alert object > AlertDate Property. It does exactly what you're trying to do: saves alerts to a disk file in Environment.SpecialFolder.Personal. Run it without modification. The code works in the SM.

Hi Eugene,


1. As we have several strategies running, we need one DLL - otherwise i would have to copy the same code for each strategy..
2. if i am using string fullpath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Personal "Alerts(" + "Test" + ").csv"); a file is written but with the same logic: the file appears if it is run as backtest, but not in SM. interestingly i see that the alerts just not appear in SM (although 6 trades appear)

br,
matthias

I don't know what "noalerts.png" should demonstrate me as the QuickRef strategy is parameterless and the screenshot indicates a different, custom strategy which is not subject for troubleshooting here. I'm just trying to suggest that "our" code works when it should.

we also so that even with closing and reopening the file, the cache seems not to be cleared. how can we force that?

i was using your code, but just put in in a DLL. if put in a DLL, it only works if run as backtest.

QUOTE:
we also so that even with closing and reopening the file, the cache seems not to be cleared. how can we force that?

1. What "cache" and what is the "file"?
2. Where (in what tool) you reopen it?
3. Why the need to reopen it?
4. What's the point in clearing that cache?

QUOTE:
i was using your code, but just put in in a DLL. if put in a DLL, it only works if run as backtest.

I've compiled the QuickRef example code as DLL and ran it in the Strategy Monitor with "Run this strategy now" on the DAX DataSet by Wealth-Data. It executed as expected, with Alerts.csv full of alerts showing up on my desktop. I cannot reproduce what you're saying. I'd focus on looking for the culprit in your environment, not Wealth-Lab.

thank you eugene, we will step back from using custom dlls. it just does not work as expected and debugging is too painful if you have code which compiles in C# in visual studio but behaves differently in WL.

Don't give up yet. In my experience, there were times when I noticed different behavior of debug and release builds (for example) and bashed my head against the wall until I found it out. It doesn't matter now to what it was attributed: an old version of Visual Studio here, a 3rd party component author's vision there. The idea is that you might take some time to experiment with your workflow including Visual Studio settings. Like I said in post #13, that QuickRef example compiled just works for me as it should in the SM.

P.S. Be very careful with the proper usage of static methods and variables. For example, I noticed them in your WLHelpy.cs class.