One of my library routines, Ownership(), will throw an error if a file it requires isn't found. The error is thrown within its constructor, and that works as expected. But the weird thing is that this error is thrown when Wealth-Lab starts up before I've even opened any strategy. Take a look at where Ownership() is placed below.

CODE:
Please log in to see this code.

So is Ownership() instantiated by Wealth-Lab upon program startup before any strategies (Chart windows) are open? Is this by design? Does this happen for every strategy stored in WL?

It's actually nice WL alerts me of the missing file Ownership() requires upon WL startup, but I was expecting the error message after starting the strategy that calls Ownership(). What am I missing about the WL startup process? Note that my default workspace has no strategy windows open on WL startup.

You know, to throw an exception it takes to run a program. But WL doesn't even compile its strategies in XML on startup - that would impose a serious delay when there are hundreds of strategies. Maybe the behavior is different for compiled strategy libraries when a dependency DLL is absent, I don't know.

P.S. If one's strategy XML file is corrupt he'll get an "Strategy could not be loaded due to an error in the XML source file" warning message.

CODE:
Please log in to see this code.

Are you sure about that?

I vaguely recall a years-ago issue with Wealth-Lab startup? when a strategy XML file was corrupt. As Eugene said, this error is handled, but I don't know precisely how it's detected - it could be a compiler error.

Compiling hundreds of strategies would be noticeable, I guess.

Anyway, I did try to save a strategy (in XML) that throws an Exception in ctor() of a custom class. Predictably, it did not throw it on startup. Unless I set it as default Workspace which is a different story, of course.

Neither did the compiled strategy library (DLL) when I put the exception-producing ctor() in one of its classes. Not reproducible.

QUOTE:
You know, to throw an exception it takes to run a program.

That's what I was thinking. I'm perplexed, which is why I posed this question.

QUOTE:
But WL doesn't even compile its strategies in XML on startup ....

WL definitely does something will all the strategies, which is why it takes longer to startup if you have more strategies installed in WL. But I'm not sure what that is. WL "probably" processes some of that XML in order to populate the Open Strategy dialog window. Perhaps there's a JITed copy of the last strategy open it executes automatically.

QUOTE:
Maybe the behavior is different for compiled strategy libraries when a dependency DLL is absent, I don't know.

This isn't a per-compiled strategy; rather, it's an XML strategy instead.

So in reading your answers, I'm concluding this behavior is unexpected. I'm concluding that the default workspace is calling this strategy even though it doesn't appear in a Chart window as part of the workspace--weird. I'll play with this more after the market closes.

QUOTE:
But I'm not sure what that is. WL "probably" processes some of that XML in order to populate the Open Strategy dialog window.

This is a later addition that makes syntax check, warns about "Strategy could not be loaded due to an error in the XML source file", and disables the corrupt XML file. But it does not execute any WealthScript code, compiled or XML.

QUOTE:
I'm concluding that the default workspace is calling this strategy

No. I said that unless I add your strategy to the Default workspace which executes it by design, I positively could not reproduce no exception.

The only remaining difference is the DLL dependency - a scenario I haven't tested:

<<One of my library routines, Ownership(), will throw an error if a file it requires isn't found.>>

Nothing weird so far.

QUOTE:
The only remaining difference is the DLL dependency - a scenario I haven't tested:

Yes, but if the strategy employing the Ownership() object is never executed, then Ownership() shouldn't be executing either. We are looking in the wrong place for the answer.

QUOTE:
... unless I add your strategy to the Default workspace which executes it by design ...

I wonder if there's a way the default workspace could be executing a strategy without displaying its Chart window? Can I place a PrintDebug("Hello world") call in the strategy's constructor?

Below is some of the Ownership() code. In its constructor, it calls the private ReadXMLDataSet() member function which invokes the throw operation. That works as expected: If the file isn't there, it throws the error; otherwise, it executes normally. This routine works well.

CODE:
Please log in to see this code.

I'm going to try simply declaring a pointer for the Ownership() instance in the strategy field variables area, then actually create the instance in the strategy's constructor instead (which is not how I did it in Post# 1). I'll try this after the market closes, but I don't think the behavior will be different.

Indeed, instantiating the Ownership class produces an exception on compilation i.e. a System.Reflection.TargetInvocationException. But that's expected since you put a code into its constructor that tries to access the file that does not exist on my drive.

As for the startup error, of course it still cannot be reproduced.

The strategy must be part of your default workspace or Strategy Monitor. Not seeing a way to get it compiled otherwise.

QUOTE:
The strategy must be part of your default workspace or Strategy Monitor.

The strategy in question is indeed part of Strategy Monitor, and SM does open its window as part of the default workspace. Are you saying SM executes (or at least instantiates) each strategy installed in its window even though none have been told to actually run? If so, that would explain the behavior. I didn't know that.

I kind of thought SM only executed a strategy when you selected the Run this strategy now choice, which is how I run my strategies before market open. Hmm. Perhaps I should remove strategies out of SM that I'm not using to save memory. I didn't know about that either. Thanks for the clarification. This has been interesting.

Yes, the SM works with its own compiled copy of the strategy (as per the User Guide).