The-Analysis-Indicator-control-for-Analysis-Series-won-t-operate

The selection of indicators is working perfectly for me in PowerPack B47 by either:

1. scrolling the list
2. typing in a few characters
3. clicking on an indicator

In all these cases, indicators do update and the graph is rendered.

Okay, I upgraded everything including PowerPack and WL8 to Build 93. I still have the same problem. Any ideas?

Did you restart Windows? This looks like something on your end.

Restarting Windows didn't help. But when I switched to two different strategies, both worked fine. So it has something to do with the strategy I'm currently developing. That's weird. I wonder what I did with that particular strategy to break the GUI?

Well, I'll make a copy of it and start deleting lines and changing settings until I can get it to work again.

I finally got around to troubleshooting this Analysis Series control problem. The bad news is that it looks like a C# compiler problem. And I say that because if "Buy factor" is used instead of "Buy factor of NxtOpen" as the first parameter in the AddParameter method, the problem goes away (sometimes). The compiler isn't getting the string length right.

Try reproducing the problem with the WL code below. Afterwards, swap the AddParameter lines so the commented out version is active and the original AddParameter line is commented out. That change should make the problem go away.

I guess someone needs to look at the pseudo intermediate code of the compiler to figure out exactly what's going wrong. One needs to determine if it's the main compiler or the GIT compiler. Maybe the current (new) GIT compiler isn't supporting my old processor. :(

CODE:
using WealthLab.Backtest;
using WealthLab.Core;

namespace WealthScript5 
{
   public class MyStrategy : UserStrategyBase
   {
      Parameter buyFactor;

      public MyStrategy()
      {
         buyFactor = AddParameter("Buy factor of NxtOpen", ParameterType.Double, 1.005, 1.002, 1.008, 0.001);
         //buyFactor = AddParameter("Buy factor", ParameterType.Double, 1.5, 1.2, 1.8, 0.1);
      }

      public override void Initialize(BarHistory bars) { }

      public override void Execute(BarHistory bars, int idx)
      {
         if (HasOpenPosition(bars, PositionType.Long))
         {
            {
               //double stopPrice = bars.Close[idx] - atr22[idx]*sellAtrFactor.AsDouble; //turtle sell
               PlaceTrade(bars, TransactionType.Sell, OrderType.Stop, 1.0, "falling stop Sell");
            }
         }
         else
         {
            {
               //double stopPrice = nextSessionOpen[idx] * buyFactor.AsDouble; //1.005 = 0.5% above next session open
               PlaceTrade(bars, TransactionType.Buy, OrderType.Stop, 1.0, "breakout Buy");
            }
         }
      }
   }
}

The dropdown's control remains fully operational for me as stated in Post #1 with your code snippet.

Thanks for checking it. Microsoft made many optimizations to the GIT compiler when going to .NET 8.0, and I don't think my old processor or Windows 10 install is 100% compatible. At any rate, I don't see how this is a WL problem.

I was able to recreate the problem described in Post #1 using the code in Post #5 many times. I am using WL8 build 94 with all extensions up-to-date.

The problem was recreated using Windows 11 on a new laptop with an AMD 8845HS processor which was released H2 2023. All drivers are up-to-date.

Strategy settings:
Single symbol MARA (same issue with CLSK)
Data scale is daily
Data range is most recent N years
Number of years: anywhere between 1 to 5
Benchmark: tried SPY and QQQ
Retain NSF positions: checked
Starting capital: 100,000
Position size: percent of equity
Percent: 55

QUOTE:
I was able to recreate the problem described in Post #1 using the code in Post #5 many times. I am using WL8 build 94 with all extensions up-to-date.

Interesting. So you're telling us this isn't a hardware or Windows issue. I'm running an Intel(R) Core(TM) i7-4765T CPU on Windows 10 Pro running WL8 build 94.

Well, in that case something "within" the address space of the WL process is clobbering the executable. If the WL process tried to address something outside its execution space, the MMU (Memory Management Unit) would throw an access violation.

But it still doesn't tell us what it is. I'm totally baffled. I don't even know how to troubleshoot it to locate the cause. But it's not hardware or Windows.

We need to vote up the feature request add a command line switch to load WL without all the extensions. I think Paul and I have a WL extension that Gene doesn't have. https://www.wealth-lab.com/Discussion/Commandline-option-to-load-WL8-without-installed-extensions-11453

@superticker - I removed all extensions except PowerPack, because it is needed to produce Analysis Series. The problem was still present.

QUOTE:
I removed all extensions except PowerPack,... The problem was still present.

So you're suggesting Gene's load map for the WL executable is different than ours; therefore, Gene doesn't see the problem. I wonder if Gene installed the distribution copy of Build 94, if that would make a difference?

Also, Gene might be running the debugger and we aren't, and that would make "some" difference in the loading. There is a compiler switch to check array bounds on the indexes. That checking would slow WL down, but for debugging it would be worth a try. I think it's some kind of string buffer overrun problem, but I'm just guessing.

Still haven't been able to reproduce it in production Build 94 using your code and Paul's suggestions.

Re: Post #11, I was using the production build like Glitch did.

Using the above code and settings from my prior tests (above), I was able to recreate the issue on another machine with the following:

Windows 11 Pro with all drivers up-to-date except the AMD video card which is one driver behind.
AMD 5950x processor
64 GB memory
AMD Radeon RX 6600 video card
NVIDIA GeForce GT 730 video card
WL8 build 94 with all extensions up-to-date

I'll have to fly over Paul and do some debugging on your computer! :)

Well, I could share my WL session over the Internet.

But I don't know how you would find this problem? I suppose you could have the debugger monitor when the offending string parameter, "Buy factor of NxtOpen", was accessed and set a break point there.

But if it's really a software problem, why is it present on some systems and not others? Although the process environmental variables maybe different between installs, the virtual load map (which is what matters "I think") should be the same.

I'm looking through Windows Update, and I see many .NET 6.0 updates, but not any .NET 8.0 updates (which WL8 uses), so I think we are running the same .NET 8 version. I suppose I could go into Process Explorer and see what version of .NET 8 is being loaded by WL. Is that really necessary?

If I emailed you the strategy XML file, would that help? But wouldn't your XML strategy be roughly the same as Paul's who can reproduce the problem?

BTW, I'm backtesting SPY when reproducing this problem.

I took the code in Post #5 and popped it into my library. I built the library in release configuration, and copied the DLL over to the WL8 folder. I ran WL8, and then ran the compiled strategy. The same problem occurred. I built the library with the Debug config and the same problem occurred.

I use JetBrains Rider IDE and with it you can see the IL. There doesn't seem to be anything unusual in the constructor:

CODE:
 .method public hidebysig specialname rtspecialname instance void
    .ctor() cil managed
  {
    .maxstack 8

    // [10 9 - 10 28]
    IL_0000: ldarg.0      // this
    IL_0001: call         instance void [WealthLab.Core]WealthLab.Backtest.UserStrategyBase::.ctor()
    IL_0006: nop

    // [11 9 - 11 10]
    IL_0007: nop

    // [12 13 - 12 113]
    IL_0008: ldarg.0      // this
    IL_0009: ldarg.0      // this
    IL_000a: ldstr        "Buy factor of NxtOpen"
    IL_000f: ldc.i4.1
    IL_0010: ldc.r8       1.005
    IL_0019: box          [System.Runtime]System.Double
    IL_001e: ldc.r8       1.002
    IL_0027: ldc.r8       1.008
    IL_0030: ldc.r8       0.001
    IL_0039: call         instance class [WealthLab.Core]WealthLab.Core.Parameter [WealthLab.Core]WealthLab.Backtest.StrategyBase::AddParameter(string, valuetype [WealthLab.Core]WealthLab.Core.ParameterType, object, float64, float64, float64)
    IL_003e: stfld        class [WealthLab.Core]WealthLab.Core.Parameter WealthScript5.MyStrategy::buyFactor

    // [14 9 - 14 10]
    IL_0043: ret

  } // end of method MyStrategy::.ctor

If you want me to try some changes and test them, please let me know.

Some things I already tried:

Use a concatenated string for the label parameter.
Declare a local variable to hold the label value and then use the variable in the AddParameter call.
Removed the redundant scope braces in the Execute method.
Literally removed the problematic line and manually typed it.
Examined the characters of the problematic line - nothing unusual there.

So you're saying the buyFactor Parameter instance compiles correctly.

I don't think it has anything to do with the above Parameter instance itself. But changing the string description parameter in that Parameter instance shifts the load map in memory such that the "cause" corrupts the WPF control in Analysis Series.

What we need to find the "cause" that corrupts the WPF control, which has nothing to do with the buyFactor Parameter instance directly. What we need to do is set a break point for when the WPF control code gets clobbered, which is probably long before we even try to use that control. Gee, the WPF control might get clobbered when you load the strategy before it's even executed; we don't know.

While I babysat my trades, I tried this...

This code will cause the problem to occur:

CODE:
         buyFactor = AddParameter("Buy factor of NxtOpen", ParameterType.Double, 1.005, 1.002, 1.008, 0.001);

But with the parameter value changes as follows, it works ok...

CODE:
         buyFactor = AddParameter("Buy factor of NxtOpen", ParameterType.Double, 1.5, 1.2, 1.8, 0.1);

All I did was remove two zeroes from each parameter value.

For each test, I made sure that I went to the Strategy Settings tab and forced a reset of the Standard Opt Params by changing the numeric value and then pressing the Reset Values To Defaults button.

I'm not sure why it is so cranky with the smaller values.

I noticed exactly the same thing last night. Moreover, changing the number of decimal places in the buyFactor double precision parameter shouldn't affect the load map because everything remains the same size in memory.

So ...
1) Changing the string length in the string parameter affects the problem.
2) Changing the decimal length in the double precision Parameter affects the problem.

So what does this all mean? Do you think it has something to do with the WPF control itself?

A wild guess would be that some math exception occurs, perhaps in the analysis calculations, and then the Analysis Indicator dropdown ends up partially hosed. I mean you can still type to move around in the dropdown, but as you know, you can't select an indicator, and the scroll bar doesn't work.

QUOTE:
A wild guess would be that some math exception occurs, perhaps in the analysis calculations,

But the buyFactor parameter isn't being used in any calculations. The code line that uses it (just above the PlaceTrade line) is commented out. And Analysis Series isn't throwing a math exception, but perhaps that exception is being handled so we don't see it.

Moreover, it also doesn't explain why changing the string length of the description parameter causes the WPF control to fail. Or why some people can't reproduce the problem on their system.

The following is a way to workaround the problem:

Run the backtest
Go to the Backtest Results -> Analysis Series tab
Go to the Analysis Indicator control and RIGHT-CLICK in the control
A popup will be shown. DO NOT pick any selection in the popup. Click away to somewhere else so that the popup disappears.
Now, the Analysis Indicator operates as expected.

I can only speculate that there is something wrong with event handling sequence somewhere in the WL code. The odd thing is that it only happens with certain code and only on some machines.

Another observation is that when the problem does occur other dropdowns on the same tab and other tabs work fine.

QUOTE:
I can only speculate that there is something wrong with event handling sequence somewhere in the WL code. The odd thing is that it only happens with certain code and only on some machines.

What's also weird is that the Parameter class, which affects it, has nothing to do with this WPF control. I'm thinking this is an installer problem with WPF since only certain machines are affected. I'm wondering if the WL installer installs WealthLab.WPF differently on some machines verses others? (But why would it need to do that in the first place?)

I got another clue about the Analysis Indicator bug behavior. Apparently, the autocomplete function for this control fails to bubble up its result to the Analysis Indicator control. It appear the Analysis Indicator just locks up when you Copy-and-Paste a value into it. The autocomplete finds the pasted result, but the Analysis Indicator can't pass that result onto WL proper.

Maybe if you just got rid of the autocomplete function altogether, this Analysis Indicator control would function correctly. I would offer to help debug this WPF control, but my knowledge of WPF is poor. :(