Getting Strategy Tester (and terminal) frozen with WindowHandle() function - page 2

 
WHRoeder:
I use this in the tester at full speed, never have had a problem. Note the IsStopped and ref https://www.mql5.com/en/forum/126618

Thank you for the info, but not same context at all.

Yours refers to generating Offline Chart from one EA (https://forum.mql4.com/32837).
Mine is to generate Offline Chart from one Indicator, and as such, IsStopped(), IsTesting(), IsVisual() cannot be used. Those calls do not address an indicator.

Moreover I'm not interrested in full speed but merelly tick pace ranging from 20 to 30. I'm not convinced your code, still using WindowHandle(), won't freeze in visual mode at those speeds which are quite different than full 32 speed.

Other hint ?

 
RaptorUK:
:-) looks like I might be able to get rid of my M7 chart and looping script . . .

With the Strategy Tester you can even generate one Offline Chart with one Indicator launched over the Visual Chart of one Dummy EA.

Do your homework first. ;-)

 
berix:
Mine is to generate Offline Chart from one Indicator

Indicators can not sleep or delay. This may include writing files and sending post messages. All offline generators I've seen have been EAs, never an indicator.

 
WHRoeder:

All offline generators I've seen have been EAs, never an indicator.

Indicators can not sleep or delay.

There are offline generators of all flavors : EA, scripts, indicators ... They all work, including writing files and sending post messages.

Indicators can delay with a for loop.

 

By the way, what about this bug ?

How can we report it ?

Rosh ? https://www.mql5.com/en/users/rosh

 
berix:

By the way, what about this bug ?

How can we report it ?

Rosh ? https://www.mql5.com/en/users/rosh

You can report bugs via the mql5 forum from your profile.
 
RaptorUK:
You can report bugs via the mql5 forum from your profile.

Only dedicated to MT5. Have sent message to Rosh.
 
berix:

Only dedicated to MT5.
Don't let that stop you . . .
 
Let's get back to topic. I can reproduce the described bug but...

Most people posting in this forum about so called bugs related to WindowHandle() - I don't address berix here - don't understand how a Windows application internally works. If the terminal freezes because we call WindowHandle() from a stopping indicator (by manually switching timeframes) or expert (by manually pushing the Stop button) this simply is expected behaviour. It doesn't matter if our code currently is in start() or deinit() or wherever. All that matters is the "stopping" status triggered somewhere in the UI thread (all the visible buttons are processed there).

Now the UI thread waits for the Tester thread (our code) to stop and return (we told 'em so) and it won't process it's message queue anymore before that happens. If our code now sends a message into that same queue (WindowHandle() does exactly that but we can reproduce this with any code sending messages to the main terminal window) we end up in a classic deadlock situation. We cannot expect different behaviour.

Learning about SendMessage() and PostMessage() helps. What they do, when to use them and when not. This is how Windows message processing works. We must not produce deadlock situations between concurrent threads or they will block each other.

It might help to visualize how threads are organized in the different Tester modes:
IsVisualMode()=true:
        Indicator::init()   current thread=3864, UI thread=3864
        Expert::init()      current thread=118,  UI thread=3864
        Expert::start()     current thread=118,  UI thread=3864
        Indicator::start()  current thread=118,  UI thread=3864  ->  after Expert::start() in time
        Expert::deinit()    current thread=118,  UI thread=3864
        Indicator::deinit() current thread=3864, UI thread=3864

IsVisualMode()=false:
        Indicator::init()   current thread=3864, UI thread=3864
        Expert::init()      current thread=119,  UI thread=3864
        Expert::start()     current thread=119,  UI thread=3864
        Expert::deinit()    current thread=119,  UI thread=3864
        Indicator::deinit() current thread=3864, UI thread=3864

As we see indicators are always initialized in the main UI thread, later they are executed in the Tester's thread. With VisuaMode=Off they still get initialized but never executed.

IsStopped() is your friend.

 
berix:

By the way, what about this bug ?

How can we report it ?

Rosh ? https://www.mql5.com/en/users/rosh


I don't think that this case may be a reason to request for service desk. It is not bug and is not direct purpose of Strategy Tester.
Reason: