Is there a way to clone a strategy (under a different name) with the Save As operation while preserving the Preferred Values settings of individual symbols? If this is not possible with WLP 6.8.10.0, is there a workaround?

Some other issues since the cloned strategy will be a little different:
1) If a new Preferred Value is added to this cloned strategy, will its value automatically default as expected until a specific value for that symbol is set?
2) If some older Preferred Values are removed from the cloned strategy code, will they automatically be removed from the XML file as expected with the Save As (or subsequent Save) operations?

I do appreciate that, since the cloned strategy is a little different than the original strategy, some of the original Preferred Values may need updating. But the original values can be used as a starting point for such an update.

I can imagine an awkward workaround:

1. Close WLP
2. Find the strategy's XML file
3. Copy it under a different name
4. Open the copy for editing
5. Generate a new Guid sequence using the enclosed tool:

CreateGuid.exe

6. Paste it into the <ID> field, substituting the original Guid
7. Save and start WLP

I got the zip file okay. Thanks!

It would be nice to have the Save As command support this cloning automatically in a future release. What about the answers to my other questions, or if this cloning operation is currently unsupported, then perhaps these answers are unpredictable/undefined at the moment?

QUOTE:
Some other issues since the cloned strategy will be a little different:
1) If a new Preferred Value is added to this cloned strategy, will its value automatically default as expected until a specific value for that symbol is set?
2) If some older Preferred Values are removed from the cloned strategy code, will they automatically be removed from the XML file as expected with the Save As (or subsequent Save) operations?

This procedure creates an exact duplicate of the original Strategy (except the Guid of course).

So if I add a new Preferred Value to the clone (or any strategy for that matter), do all the symbols take on the default value of this new parameter until they are set differently?

If I delete an established Preferred Value for the clone (or any strategy for that matter), is the existence of that parameter removed from the XML file automatically?

The User Manual doesn't address how added or orphaned Preferred Values are managed by a strategy (cloned or not).

1 - I'd assume it to be the case. Is your experience different?

2 - Well, it'd be a zombie PV if it kept being applied after removing as it'd defeat the purpose of its deletion.

See steps 1-5 discussed above for cloning a strategy with "private" (non-default) Preferred Values defined inside.

QUOTE:
6. Paste it into the <ID> field, substituting the original Guid

In addition to Step 6, let's add a Step 6a that sets the <Name> tag (or field) to the new file name. If you skip this step, there will be two strategies showing with the same name.

----

After some experimenting, I can report:

1) Yes, when one adds a new model parameter to any strategy, all symbols take on its default value (as expected) including symbols with saved "private" Preferred Values.

2) No, it's not deleted. If a model parameter is either deleted or its description string is changed, any saved "private" Preferred Values for that parameter become a zombie attribute permanently saved within the strategy file. (However, it's not applied since the strategy code doesn't reference any parameter with that zombie description.)

That brings up a tougher question: Is the behavior in 2) good or bad? Well, if the strategy is still under development and a parameter is temporarily deleted (or description changed), then later reinstated, it's good because those zombies can be resurrected. But retaining the zombies is bad for mature strategies.

So how might Wealth-Lab be improved?

A) To address the behavior in 2), have Wealth-Lab check for zombie parameter descriptions with each Save operation. If it finds any, have it present a dialog box with check boxes besides each zombie parameter description. The user can then check which zombies he wants to delete and leave unchecked which zombies he may want to resurrect later.

B) Currently, WLP 6.8.10.0 saves all "private" PVs--including those using coded default values. This is true even if all PVs are set and saved to their default values for a given symbol; there's no mechanism to remove them. It would be best if WL only saved PVs that were different from the coded defaults. This would save parsing time and file space. Moreover, if the strategy and its parameter defaults were later modified, all symbols would be able to adopt the new default values immediately.

Thanks for your suggestions.

Re: 2. Since the zombie string is not applied as you said, I see no problem with this in the actual usage.

QUOTE:
Re: 2. Since the zombie string is not applied as you said, I see no problem with this in the actual usage.

I agree. It just clutters the XML strategy file.

Also, I'm wondering if the zombie deletion dialog box should only be presented in special cases since the standard Save operation is done so often. Perhaps it should only appear if (1) there are many instances of zombie parameter descriptions, or (2) when cloning with the Save As operation.

Currently, the WLP 6.8.10.0 Save-As operation strips out all saved PVs, thereby minimizing the zombie parameter description problem. But if users start cloning strategies with the procedure here, the zombie problem will become more apparent.

In practice, I think most users start a new strategy with the Save-As operation from an existing strategy with all PVs stripped out. Maybe a check box should be added to the Save As dialog asking if "private" symbol-dependent PVs should be retained or not. If so, then the zombie deletion dialog can presented (if zombie descriptions exist in the strategy being cloned).

QUOTE:
Also, I'm wondering if the zombie deletion dialog box should only be presented
Maybe a check box should be added

Sorry for not being clear. When I said there's no problem in the actual usage, I meant that there's a snowball's chance in hell of adding an option because it's not required. Arcane options and dialog boxes are a no-no as Wealth-Lab's design is about simplicity. We try to not confuse the end user, keeping this in mind:

I agree with the sentiment that the UI should be made as simple as possible and that the application should work as expected with minimal fuss. (I'm also a stockholder in Apple, and that's not just because it's a good stock.)

There's always a tradeoff between simplicity and usability that must be carefully weighed with any program design. As Einstein said, "Make the design as simple as possible, but not too simple." And every engineer should post that quote above his workstation.

My computer science and engineer colleagues carry Android phones instead of Apple phones because they don't mine a little complexity for greater customization. But the iOS remains very popular with many non-techies, in spite of some restrictions. But not everyone is happy with those restrictions; that's why there are Android phone owners.

Likewise, I don't think technical stock analysis is right for everyone. And honestly, with its nonlinear discontinuous behavior, I think it's the toughest fuzzy-system programming problem I've ever encountered. (Most fuzzy-system problems are based on physical phenomena, which behave without discontinuities.) So we can assume we are dealing with a more sophisticated audience here; however, we still need to think like Einstein: We want simplicity to prevail, without sacrificing too much functionality.

Letting zombie parameters build up in the strategy file because someone decided to rename their description tag is poor programming. That automatically invalidates all the previously saved parameters (under the old description)--bad idea. Apple's approach would be to purge the zombie parameters without asking. Google's approach would be to ask first, but only under the Save-As operation when required so as to "hide" the underlining complexity. My "guess" is that most technical analysis traders carry Android phones instead of iPhones. Google's approach gets the popular vote here.

But the Apple's approach is better than just letting obsolete zombie parameters build up from years past. Consider purging without notification if you want to maximize simplicity. Are you an iPhone user? :-)

Although I'm an Android user, I agree with what you exemplify as Apple's approach i.e. to purge the zombie parameters without asking. I do not assert that those zombie strings is a bug at all (I don't know now) - rather that this approach would look preferred to me because it doesn't confuse the end user and/or introduce any unneeded options. The thing is, the scale of the "issue" will probably make it hang in the queue for a few years with low priority until it gets deferred.

Ha ha. An Android user that prefers an Apple approach. That's interesting.

-------

I've just taken inventory on my strategy files. (Have you looked inside yours lately?) I've discovered numerous zombie parameters that were created when I renamed their descriptions, and thereby unknowingly lost their associations. I asked myself: How could this have been avoided with better program design?

The solution is to bring up a dialog box upon a Save operation whenever a "new" zombie parameter is created. For each zombie parameter description I would give the user three choices:

1) Allow him the opportunity to reassociate the old parameter description with an existing parameter description. This allows him to redeem old parameter values immediately following a renaming session. This must be educative (include a tool-tip popup) because he may not realize renaming parameter descriptions broke his PV customizations, which is my situation.)

2) Allow him to retain the zombie parameter for later resurrection.

3) Delete the zombie parameter as no longer relevant.

The dialog box would only appear once--immediately--after a new zombie parameter was detected on a Save. This is to quickly educate the user that he did something confusing, and to be aware of it. Yes, this is a Google solution because it educates and provides choices. But I think most Wealth-Lab users carry Android phones, so offering some choice is okay.

Just in case you were wondering, I'm an Android phone user too. :-)

QUOTE:
I've just taken inventory on my strategy files. (Have you looked inside yours lately?) I've discovered numerous zombie parameters that were created when I renamed their descriptions, and thereby unknowingly lost their associations. I asked myself: How could this have been avoided with better program design?

Thank you for the feedback. Actually, Wealth-Lab identifies PVs by the key string which is the StrategyParameter label. When you rename it, Wealth-Lab loses track of it. Taking into account the change of the label when it gets renamed would probably be an undesired complication, that's why it is the way it is. As zombie parameters do not affect anything, I believe this is a non-issue.

QUOTE:
Wealth-Lab identifies PVs by the key string which is the StrategyParameter label.

This behavior should be highlighted or emphasized in the User Guide. After carefully assigning PVs, a user may decide on a better label for the StrategyParameter, not realizing that changing the label loses all those carefully assigned PVs.

I like the way Wealth-Lab uses the parameter description (key string) to identify "private" symbol parameters (PVs). Please don't change that.

I'm concerned with making the User Guide too long and complicated (Gee, I haven't finished reading it myself, and I've been using WL for five months now.), but I have to agree with LenMoz that some mention of this Preferred-Value description association (key string association) in the manual is worthwhile.

Honestly, when the WL manual said the "private" PVs were stored in the strategy source file, I asked myself "How is that possible?" because I don't see them in there. I just assumed WL had a special registry (database) or used the Windows registry to store them. It was only later (after reading this forum) that I realized the source was an XML file, and not a C# file. Perhaps that should be mentioned in the WL manual too (although that mention might just confuse other readers).

I'm a big believer in the Google approach to program design and documentation. Make the manual as short as possible (which means not documenting this behavior because it's confusing), but provide documentation on-the-fly as discussed above (through a dialog box) when it's timely. But I also realize the "Google approach" verses the "Apple approach" are religious issues; there's a large customer following for both approaches.

As I said, I'm an Android phone user. :-)