Errors, bugs, questions - page 2748

[Mihail Matkovskij]

Sergey Dzyublik:

That's a lot of text, haven't read it all.
But if you have something working in debug version and yet not working in release, or vice versa, then check if all variables and fields, especially in class/structure, have been initialized.

Those data that needed to be initialised I have initialised. And if some random data happen to be there, it will cause an error in the program itself (for example, Array out of range or Invalid pointer). At least, it will not affect operation of the debugger. And it helps to find such bugs.

[Sergey Dzyublik]

Mihail Matkovskij:

Maybe you have this defect:

(not fixed by ME5(build 2390)) ** (new) Debuger, StepInto (F11) and installed breakpoints do not work.

[Mihail Matkovskij]

TheXpert:
Maybe your file structure is so complex that the debugger can't associate a breakpoint, then it's the debugger's problem.

I think the file structure of the standard UI elements I use in my project is even more complex than my work. I would have to work very hard to make something like that. But as it is, take it and use it, as they say. If you put everything together, as in my case. Then, indeed, you get something complicated. But for running programmes it's quite normal.

[Roman]

fxsaber:

Initially, this was brought up to.

At a certain stage, not only the relative part of the time taken becomes important, but also the absolute part.

Get used to allocating variables in C for a while, and it's a good habit to do so.

In the first custom function, the input MqlTick structure is passed directly to the MQL function, without any memory allocation.
Such an entry is called bad coding.

bool GetCurrentTick1( MqlTick &Tick )
{
  return(SymbolInfoTick(_Symbol, Tick));
}

In the second example, the CurrentTick variable is created; the memory is allocated for it.
And this entry is considered more correct.
Since the memory is already allocated, the input data are processed faster, without unnecessary costs.

bool GetCurrentTick2( MqlTick &Tick, const bool NewTick = false )
{
  static MqlTick CurrentTick;
  
  if (NewTick)
    SymbolInfoTick(_Symbol, CurrentTick);
  
  Tick = CurrentTick;
  
  return(true);
}

[TheXpert]

Roman:

Get a bit more C, you'll get in the habit of allocating variables.

Follow your own advice and you might get at least the slightest idea of allocation.

[Alexey Navoykov]

Roman:

...

And that record is considered more correct.

Counted by whom? You could at least give us the speed measurements first.

[Sergey Dzyublik]

Alexey Navoykov:

Who's counting? You could at least give me a speed measurement for starters.

Too much attention for a troll.

[Roman]

TheXpert:
If you follow your own advice, you might get at least a glimpse of allocation.

By allocation, I meant memory allocation.
Not in that literal sense as a class.
A user-defined function has its own scope.

[Roman]

Alexey Navoykov:

Who counts? You should at least give some speed measurements to start with.

On the previous page fxsaber gave the measurements.
I explained why it happens this way.
Always allocate memory, statically or dynamically.

[Mihail Matkovskij]

Sergey Dzyublik:

Maybe you are experiencing this defect:

(not fixed by ME5(build 2390)) ** (new) Debugger, StepInto (F11) and installed breakpoints do not work.

It's possible... I tried the int CCheckGroup::itemCheckState(const string item) method I described above. And at first the debugger does go there. But once it exits and that's it, the debugger doesn't see it any more and no breakpoints or "Step with enter" work. Well, we'll have to make do with Print() and Alert() temporarily.