Errors, bugs, questions - page 2541

New comment
 
Ilyas:
So you didn't get the control back to the terminal, you "hung up" in an "infinite" loop inside the Fn in the DLL.
What kind of normal termination are we talking about!

If you need such behavior, you should run a separate thread with a loop inside Fn in DLL, which should be stopped by a flag, that is set in a separate function FnStop and with DLL_PROCESS_DETACH

The fact that I don't get control back, it's done for example, it's clear that while should be run in a separate thread, so as not to block the mql thread.
But I get the same behavior when I run while in another thread, the problem is in DLL_PROCESS_DETACH, this identifier does not work, for the existing flag Detach.
Yes, we have already written, that we need to create separate exported function and use it to control this flag.
But as shown in this example, flag in DLL_PROCESS_DETACH does not work.
Maybe there is an error in terminal, it is logical that DLL_PROCESS_DETACH should transfer flag to another state.
The while loop gets this state, exits the loop, anything encountered along the way is executed and terminates the Fn() function itself.
Only after that the dll should be unloaded!
But this does not happen, we get some kind of early dll unloading by hidden terminal mechanisms, so we get a crash.

 
TheXpert:

I don't want incompetent people like you, Fedoseyev, etc. to get involved in discussing bugs and constructs.

so that constructions and mechanisms taken in MQL from C++ in their entirety and looking the same as in C++ would work the same as in C++.

it's bullshit and you know it, but you have to throw it in there.

You're the one whining about how annoying it is, about a separate language and a separate thread.

Open a separate thread for yourself and your sympathisers and whine there.

I had a better opinion of you. My mistake. It happens. You're boorish and ... not smart.

 
Roman:

It's made for example, while should be run in a separate thread, so as not to block mql thread.
I get the same behavior when I start while in another thread, the problem is in DLL_PROCESS_DETACH, this identifier doesn't work, for existing flag Detach.
Yes, we have already written, that we need to create separate exported function and use it to control this flag.
But as shown in this example, flag in DLL_PROCESS_DETACH does not work.
Maybe there is an error in terminal, it is logical that DLL_PROCESS_DETACH should transfer flag to another state.
The while loop gets this state, exits the loop, anything encountered along the way is executed and terminates the Fn() function itself.
Only after that the dll should be unloaded!
But this does not happen, we get some kind of early dll unloading by hidden terminal mechanisms, so we get a crash.

Let me guess. If you start a loop in a terminal thread from dll, it hangs, and if you run it in a separate thread, which detach(), then the terminal crashes with an error?
 
Roman:

Not taking control back is just an example, it's clear that while should be run in a separate thread so as not to block the thread

So give us a proper example and leave the attachments alone. manage thread creation/deletion explicitly by yourself.
 

Forum on trading, automated trading systems and trading strategy testing

Bugs, bugs, questions

Sergey Dzyublik, 2019.05.26 15:12

Unfortunately, at the moment function pointer types in MT4/MT5 are very limited and not practical due to some defects:
#(not fixed in MT5(build 2118))"Compilation error when using the same function signature repeatedly within typedef".
#(not fixed in MT5(build2118))"When working with typedef, using a template function with explicit specialization does not generate code for that template function".


In view of the expected implementation of the namespace, please consider implementing support for this behavior in the next C++ as part of the defect fixes:
//#include <iostream>

template<typename T>
class A{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
    T data;
};

template<typename T>
class B{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
};

template<typename T>
void func(T& value){
    ++value;
}


void OnStart(){
//int main(){
    A<int> a;
    B<int> b;
    
    a.f_ptr = func<int>;      // automatic code generation of templates functions
    b.f_ptr = a.f_ptr;        // assignment operation for function pointers with the same function signatures and different function pointer types.
    
    int x = 1;
    b.f_ptr(x);
    printf("%d\r\n", x);                  //2
    printf("%d\r\n", b.f_ptr == a.f_ptr); //1     // equal operation for function pointers with the same function signatures and different function pointer types.
}

MT5 (build 2118), How much longer can we wait for bug fixes intypedef functionality?
Some nonsense - a step to the left of a primitive example on usingtypedef and that's it -a bunch of bugs blocking further development.

 
Vladimir Simakov:
Let me guess. If you run a loop from dll in a terminal thread, it hangs, but if you run it in a separate thread to which you detach(), the terminal crashes with an error?

Not exactly.
Launching a loop works fine.
The problem is when you forcibly stop the program and pass a flag to the loop to exit the loop and terminate a running function.
But the terminal doesn't allow to exit the loop and terminate the running function correctly, because early dll unloading is already triggered. We get a hangup.
The dll is unloaded before the flag state is passed and Fn function doesn't terminate, early unloading breaks everything.

I did it in terminal thread for example, to avoid writing all code, because in blocking mode the problem is better seen.
I have created a separate function for the loop flag and the running loop is running in another thread, but the same behavior.
And when I try to switch the flag to another state from non-locked mql code, through a function to exit the loop,
the terminal doesn't wait for the running loop to finish, and doesn't let the Fn function finish where the loop is running.
Terminal immediately performs an early dll unloading without waiting for Fn function to complete. This is the problem.

TheXpert:
so give a proper example right away. and leave the attachi detachi alone. control the creation/deletion of threads explicitly yourself.

You can see the problem better in locked mode. It doesn't really matter what changes the state of the flag. With an entry point or a separate function.
The entry point is better for locked mode, since control is not passed back and the flag change function cannot be called. This is why atachi detechi is used as an example.
Atachi detachable left alone, made a separate function as you advised, no luck, on a working project in non-blocking mode, the same behaviour.
The dll is unloaded early, the running function with the while loop does not have time to complete and hangs.

 
Roman:

The dll is unloaded early, a running function with a while loop has no time to terminate and a hangup occurs.

there can be no hang-up in a normal implementation

 

Has anyone encountered the following problem with custom symbols? The CustomRatesUpdate function receives normal quotes, but in fact the chart and data window contains something strange (in this case the close and low values are 100 times less than passed):

Also, in parallel, single ticks are emulated with CustomTicksAdd with the same values of close price as in the log (immediately before CustomRatesUpdate), i.e. it's not clear where the reduced values in quotes come from.

UPD:

I've got "reverse" situation on USDCAD - quotes increase 10 times after writing. This is the log I'm getting:

2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]  [high]   [low] [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32987 1.32987 1.32980 1.32987           457       48             0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) Retry: 1 0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]   [high]   [low]  [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32980 13.29730 1.32980 13.29730           457       52             0

The first ArrayPrint is what was written in CustomRatesUpdate, and the second ArrayPrint is what was read using CopyRates from the last most recent bar immediately after writing. First, the difference is the last digit in open, but more importantly, high and close are increased by a factor of 10.

 
Stanislav Korotky:

Has anyone encountered the following problem with custom symbols? The CustomRatesUpdate function receives normal quotes, but in fact the chart and data window contains something strange (in this case the close and low values are 100 times less than passed):

Also, single ticks are emulated in parallel using CustomTicksAdd with the same values of close price that are in the log (immediately before CustomRatesUpdate), i.e. it is not clear where the reduced values in quotations come from.

Yes, I've encountered it, but my null was not clear. You've got 100 times the number of spikes.
I did an extra zero check, it didn't help, it was working all wrong, then it was drawing such spikes.
Mostly this behaviour was observed the first time I started the program, and the first time it created history files with a non-existent date.
Cleaned folder ticks, corrected code, in order to find where the bug, bored, postponed for now, but also have to return to this problem ((
Check also the folder custom history, there may be files with a date that does not exist )))
In general, the bug lives there specific.

Please duplicate the problem in this thread
I think Slava is in charge of custom characters there.
To remind of the problem.
 

Has this error been mentioned before? Can't find it. Bottom line: when loading optimisation results from cache file, forward results are displayed incorrectly. The parameter values have the wrong digits.

You go to the optimization tab. Select the Expert Advisor. Select one of the former optimizations. Backtests are loaded normally. Forwards give this:



MT5, latest build. x64.

1...253425352536253725382539254025412542254325442545254625472548...3189
New comment
Reason: