MetaTrader 4 Build 529 beta released with new compiler - page 133

 
What was fixed in 560 does not work in 562. Buttons on top of OBJ_EDIT do not work again.
 
pro_:
What was fixed in 560 does not work in 562. Buttons placed over OBJ_EDIT do not work again.
Please try 563 build.
 
Renat:
Try the 563 build, please.
During optimization or test not in visual mode, if there are Alerts or audible event alerts in code - they all sound and Alerts windows pop up. Maybe it's better to ignore them in the tester, except for visual mode?
 
artmedia70:
During optimization or test not in visual mode, if there are Alerts or audible event alerts in the code - they all sound and Alerts windows pop up. Is it better to ignore them in the tester, except for visual mode?


I insert them in the code and bypass them myself

void CreateOrSetLine(const string NameObj,datetime Time1,double Price1,datetime Time2,double Price2,color cColor)
  {
   if(IsOptimization()==true)
      return;
   if(ObjectFind(NameObj)==-1)
     {
      ObjectCreate(NameObj,OBJ_TREND,0,Time1,Price1,Time2,Price2);
      ObjectSet(NameObj,OBJPROP_RAY,false);
      ObjectSet(NameObj,OBJPROP_BACK,false);
      ObjectSet(NameObj,OBJPROP_COLOR,cColor);
     }
...
... в т ч  алерты
... и прочие сообщения - которые на оптимизации не нужны

и так получаю более быстродействующий код
 
 
YuraZ:

into the code and bypass myself

I understand that. The question is about something else. How much time will it take to process ifs with intensive use of graphics and serious optimization. And you can simply have the tester itself ignore the output of graphics, alerts and sound in a non-visual mode.
 
artmedia70:
Yes, it's clear. The question is different. How much time will it take to process ifs in case of intensive use of graphics and serious optimization. And you can just make the tester ignore the output of graphics, alerts and sound in a non-visual mode.

I partly agree, but if there is no code in the tester, you can handle it with one conditional transition and the problem is not so big

In any case it will save processing speed

it's just that in your proposal the tester will crawl through the code anyway and bypass only the output of graphics and sound, and in my variant the output is immediate

of the code block that is not needed during testing, and I, as the author, know better what can be skipped and what not

and this approach is considerably faster.

it is not a fact that the tester will handle the whole block of code faster than if you go straight to the place where the author knows exactly that further code is not necessary for optimization

 
Renat:
Try 563 build please.

Yes, thank you, it was fixed promptly. But unfortunately there is a new incomprehensible behaviour of OBJ_EDIT. I will try to explain.
I have two OBJ_EDIT , one on top of the other. Since the drawing order has not been fixed yet, we have to play with names of objects. Well, we have got used to it.
The lower one is called "1_abc" and the upper one "abc". At initial drawing all is correct. At program redrawing (for example change of sizes) upper, "abc", disappears (goes "under" lower). And if you click on the place where it was his field is highlighted, although he himself is not visible. Tried to give other names to change the drawing order, still the same behaviour... appeared in the last 563rd build, it was fine before that.
 

The 563 build does not work:

ObjectSetString(chartid,NAME,OBJPROP_TOOLTIP,tooltip);

The same code works fine in 5.

 
pro_:

There are two OBJ_EDITs , one on top of the other. Since the rendering order has not been fixed yet, we have to play with the object names.


How is it not fixed? Now the objects are drawn in strictly chronological order and not in alphabetical order. Didn't it get into the build?

Please give me an example of your code to illustrate the problem

 
Wahoo:

The 563 build does not work:

The same code works fine in build 5.


Yeah, it's working.

check on pure graphics, maybe it's because of a template bug

Reason: