how to unload the dll - page 7
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
AlexEro,
I'm back from holiday, I see you've got the bastards all over you. Let's kill them together. )))))
HIdeYourRichess,
The problem with loading loading dlls after deleting indicator indeed exists, but it's not because of errors in the dll code itself, it's because the developers limited the use of external libraries by so called "reasonable limits".
What these limits are - the fuck knows, they did not bother to explain in detail. However, as long as the library fits within these limits, uploads and downloads are fine.
But as soon as a disturbed programmer starts excessively zealously manipulating memory or stealing processor time from the terminal for his calculations or touches the sacred (oh dear) - terminal.exe message queue, the evil methaquot will take its revenge.
Dll not being unloaded is nothing new. I've encountered such things that make my hair curl. For example, some indicators (which didn't contain DLL calls, mind you) started climbing into each other's address space. And even after a call of a simple function from DLL (even not doing anything at all - I tried it specifically!) the terminal suddenly skipped(!) MQL program lines. The for(i=limit;i>=0;i--) timeseries loop after its completion would exit into the area of negative indexes (which was inevitably confirmed by alerts)!!! What amazed most of all was that terminal.exe, having acknowledged all the comicality of the situation after a certain number of milliseconds and immediately shit itself, immediately stopped clattering and returned i back to its original value of 0. Like nothing had happened.
Let's discuss what the regsvr utility does after we have fixed the errors with handling the code of Ex4 programs.
Once again - I don't have a problem with dll anywhere. If you have problems, it's your programming issues, neither MS nor MT is likely to be to blame. And the fact that you need to use "old" VC - it should be clear anyway.
Funny man.
Everything is solved by testing.
.
So take the dll, pull it out of the EA - if it can be removed
with MT running, that's it, you're a hero, congratulations!
And if it fails, why are you writing this here? For whom?
So that customers see what kind of treatment they will receive when working with your products?
Or so everyone knows exactly who not to ask for advice?
.
Now I'm thinking, what kind of answer would the people who asked the question want?
most likely this: Create an exe, load a dll with dynamic linking into it
via GetProcAddress() and pull the calls.
If when the Exe is running it doesn't remove the Dll after unloading, you have a problem.
This is called getting a real objective result instead of making up
some "errors" of "your programming".
And to this obtained result you can come up with a theory :-)...
.
Theories, I repent, have all been made up here.
But that's because you're too lazy to lift the % to reply properly.
.
And VBAG... well... Bravo!
A sensible description of the problem, a specific case, everything became sharply clear.
Although for you, if you're working with an application server, the dll replacement won't be so relevant soon :-).
.
Frankly speaking - for debugging it's better to have *static* data in a file.
Have an EA dump the data into a file for you.
For the last 7 years I've been reading and writing multi-megabyte files in one line - everything is very fast.
And for a tab-separated file you can convert this big string to a matrix in one go and without substr()'s
(in tenths of a second), because splitting into strings and then into columns is somehow too
too slow (it was a few seconds). So that if something crashes, the problem can be *guaranteed*
reproduce, rather than depending on random number generators.
.
And with this approach (!) testing would be simplified. Because it's not a Dll.
Because the run button in ONE CLICK will compile, slink, run, and the exe itself will take the necessary data.
.
P.S.: just the problems with "programming" can be solved...
I agree with the previous comrades that my DLL should be used in MT4 with care and limitation. This means the above mentioned, as well as the fact that you should develop your DLL gradually, and no exotics. Your DLL is a temporary guest in someone else's house of semi-interpreter in MQL4.
2 alsu: I'm sick, I just have nothing to do, I can't conduct an intelligent project in bed, but a conversation with nerds didn't require much mental effort, so I scribbled it down. I'm waiting when their conscience will wake up, but it's not visible yet, only demagogy and verbiage ....
The problem with DLL unloading after removal of indicator really exists, but it is connected not with presence or absence of errors in DLL code itself, but with the fact that developers limited using of external libraries by so called "reasonable limits".
What these limits are - the fuck knows, they do not bother to explain in detail. Nevertheless, as long as the library fits within these limits, uploads and downloads go fine.
But as soon as a disturbed programmer starts excessively zealously manipulating memory or stealing processor time from the terminal for his calculations or touches the sacred (oh dear) - terminal.exe message queue, the evil methaquot will take its revenge.
Dll not being unloaded is nothing new. I've encountered such things that make my hair curl. For example, some indicators (which didn't contain DLL calls, mind you) started climbing into each other's address space. And even after a call of a simple function from a DLL (even not doing anything at all - I tried it specifically!) the terminal suddenly skipped(!) MQL program lines. The for(i=limit;i>=0;i--) timeseries loop after its completion would exit into the area of negative indexes (which was inevitably confirmed by alerts)!!! What amazed most of all was that terminal.exe, having acknowledged all the comicality of the situation after a certain number of milliseconds and immediately shit itself, immediately stopped clattering and returned i back to its original value of 0. Like nothing had happened.
Let's discuss what regsvr utility does after we fix errors of eX4 code processing.
As they say, you can break your dick if you're stupid. In other words, if you can't write normal workable programs in MQL - it's your problem, not MQL, that's all. You can write a buggy dll in C, but it's not cancelling the fact that C is a great language. And here too, a bad dancer, i.e. you, gets in the way of bolls. I understand your desire to blame MT or MS for your mistakes. If it doesn't go away with age, nothing will help you.
Here, as they say, you can foolishly break your dick. In other words, if you can't write decent workable programs in MQL - it's your problem, not MQL, that's all. You can write a buggy dll in C, but it's not cancelling the fact that C is a great language. And here too, a bad dancer, i.e. you, gets in the way of bolls. I understand your desire to blame MT or MS for your mistakes. If it doesn't go away with age - then nothing will help you anymore.
Judging by your avatar, at your age there is nothing to break and nothing to interfere with.
Have you seen my dlls? Why on earth would you call them bad words? I have never written glitches - I don't have time for it. The glitch in this case was written with meta-quotes (I'm not making claims to MS, by the way). If you never put anything more complex than 2 +2 in a dll, it does not mean that others do not. 2 +2 will not glitch.
Funny man.
Everything is solved by testing.
I've tested it - it works fine for me.
So take the dll, pull it out of the EA - if it can be removed
with MT running, that's it, you're a hero, congratulations!
And if it fails, why are you writing this here? For whom?
So the customers can see how they will be treated while working with your products?
Or so everyone knows exactly who they shouldn't go to for advice?
What do you mean "can be removed"? My dlls in the EA are behaving decently. I must be doing something completely wrong.
>> that's your problem, not MQL.
If the interpreter isn't glitchy, it won't skip commands in the code, even if you shit your pants here!
What do you mean "can be removed"? My dlls in the EA are behaving decently. I must be doing something completely wrong.
What I mean is that you have to specify a specific dll in the EA.
Then you have to run the Expert Advisor and do not exit the Metatrader.
Next, the most important usecase is to pretend that we are replacing the dll for a new one.
If it fails when the metatrader is running (and I check by deleting the file)-then
then the system thinks the dll is in use--
voila. Your Expert Advisor is now complete and the dll has not been removed.
Now you have to restart the whole application to replace the Dll.
I'm sick.
H1N1;)
>> they said they got the prefix.
Judging by your avatar, at your age there is nothing to break and nothing to interfere with.
Have you seen my dlls? Why on earth would you call them bad words? I have never written glitches - I don't have time for it. The glitch in this case was written with meta-quotes (I'm not making claims to MS, by the way). If you never put anything more complex than 2 +2 in a dll, it does not mean that others do not. 2 +2 will not glitch.
Oooooh, muyuye has stooped to trying to make fun of the avatar. The next step is trying to make fun of the nickname.
What were you talking about in your previous speech? What horrors did you tell an astonished audience about? Looking at it, I am genuinely perplexed. You would have to work very hard to get that. Hence the bad words about your dlls. But if these horrors you've described don't concern dlls, why are you telling about them?
By the way, what does 2+2 mean? Is that a measure of difficulty? Try implementing something like 2+2 on your own like in Excel and you'll be surprised how hard it is.