Errors, bugs, questions - page 2573
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Probably here in the footnote
Oh, yes, then you don't have to worry about disk overloading.
What surprises me is using global variables of terminal (if that's what they're about) for saving big data sets.
It's a creepy crutch, isn't it?
Okay, the variables themselves, but there are their string names, which must also be stored and still do every time a string search for access to this variable, not to mention the only type double, which can be stored. Sure, you can use union, but using it is not free.
It is much more correct to implement saving independently through resources of any data array with auto-save to disk or when deinit event occurs
Variables themselves are fine, but there are string names, which must also be stored and still do every time a string search to access this variable, not to mention the only type double, which can be stored. It is clear that we can use union, but its use is not free, either.
I had an idea and desire to use global variables, but I decided to save them to disk in the old way, especially now I started to write code properly - data are stored in structures, and you can dump structures to disk in one click - FileWriteStruct().
so, the global variables "must be used exactly the other way round" - data should be stored in the global variable name. and the checksum in double with Base64 - everything is ready in CryptEncode(), and ideally it should be Base85 ( Ascii85 ) or seen somewhere source code on the githab Base128
and if i'm not mistaken, the global variable name in the terminal is 256 characters? the efficiency of Base64 is slightly over 60% ( size), other coding methods have higher efficiency - you can store 160-180 bytes in one global variable
Although you will have to determine the data using the prefix, but in general, it will work - all the more so because global variables are rarely used - all names are essentially free
I had an idea and a desire to use global variables, but I decided to save them to disk in the old way, especially now I have started to write codes as correctly as possible - I store data in structures, and I can dump structures to disk in one click - FileWriteStruct().
so, the global variables "must be used exactly the other way round" - data should be stored in the global variable name. and the checksum in double with Base64 - everything is ready in CryptEncode(), and ideally it should be Base85 ( Ascii85 ) or seen somewhere source code on the githab Base128
and if i'm not mistaken, the global variable name in the terminal is 256 characters? the efficiency of Base64 is slightly over 60% ( size), other coding methods have higher efficiency - so you can store 160-180 bytes in one global variable
Although you will have to determine the data using the prefix, but in general it will all work - the more so that global variables are rarely used - all names are essentially free
The class is laid out, including examples. Developers will introduce new functionality that allows already without writing wrappers around resources to transfer data.
Global variables are used for flags. It is also convenient to always see their values - F3.
The class is laid out, including examples. Developers will introduce new functionality that allows already without writing wrappers around resources to transfer data.
Global variables are used for flags. It is also convenient to always see their values - F3.
I found that in my visual testing mode SymbolInfoTick() returns one value but the Close[0] timeseries has a different value.
Is it my mistake ? Am I doing something wrong ?
It seems like it should be the same values:
Usually the difference is 1-2 points, but on sharp movements it can be more.
Is it only me ?
For now I've taken time series as "more correct". If it turns out that SymbolInfoTick() gives a different value than Close[0], then I assume that the correct value is Close[0] and I leave a spread as it was returned by SymbolInfoTick().
But, it is interesting to understand, which price is correct, what price is "looked" by DC - SymbolInfoTick() or Close[0].
What is the build number?
Build 2155 should be fixed by now - this bug was fixed last week
What's the build number?
Build 2155 should be fixed by now - they fixed that bug last week
Yeah. And I have 2085.
Understood, updating.
P.S. Yes, the values are the same now.What is the build number?
Build 2155 should be fixed by now - this bug was fixed last week
Do you know anything about it?
You haven't given any details to reproduce
You have not given any details to reproduce