Errors, bugs, questions - page 148

[Prival]

EQU:

And again - the code... code... Code is good... but it's also - tactics, cycles... ;)

Doesn't the chart get a message about creating a new bar? I don't believe it...)))

Is it a problem to make an event out of it? Is it a predefined variable at least?

In general, it is easier to process events than to fill a mountain of code. And besides - with errors (ERROR-FREE PROGRAMS DO NOT EVER!!! )))))

I absolutely agree with you that the new bar is an event and it can (and should) be programmed. There's a branch at https://www.mql5.com/ru/forum/1031 read it at your leisure, but I've been struggling for years...

Z.I. I think after reading this you'll see that the new bar may NEVER appear... a hole...

[Валерий]

EQU:

Again, code... code... Code is good... but so are tactics, loops... ;)

Doesn't the chart get a message about creating a new bar? I don't believe it...)))

Is it a problem to make an event out of it? And a predefined variable at least?

In general, it is easier to process events than to fill a mountain of code. And besides - with errors (ERROR-FREE PROGRAMS DO NOT EVER!!! )))))

Generally, how do you see it? 20 timeframes x number of symbols in the 'Market Watch' and the event OnNewBar is generated for each of them? And you have to process each one, to determine which symbol and timeframe it refers to? Now you have the choice: to write your own function NewBar and in it to define what you want to receive new bars: all periods for a symbol, all symbols for the current period or some special case. This results in a specific and uncomplicated function. This is better than the universal OnNewBar function with many checks.

[Konstantin Chernov]

When testing, an error is generated

CTrade::PositionClose::OrderCheck: Invalid stop(s) request
In my Expert Advisor, there are the following lines

description of variables (in the procedure)

CTrade m_trade;

..................

close position

m_trade.PositionClose(_Symbol, eSlippage);

why does it show error? CTrade::PositionClose::OrderCheck: Invalid stop(s) request

wrong SL and/or TP
TRADE_RETCODE_INVALID_STOPS

What do stops have to do with position closing? Or am I missing something?

[[Deleted]]

Prival:

I absolutely agree with you that a new bar is an event and it can (and should) be programmed. There's a threadat https://www.mql5.com/ru/forum/1031 that you can read at your leisure, but I've been fighting for years...

Z.U. I think after reading this it will be clear to you that the new bar may NEVER appear... a hole...

I took the risk of looking at the link... I guess it's really worth a read... at your leisure... ;)

That's the reason for wanting such an event... No bar, no event.

[[Deleted]]

Valmars:
Actually, how do you imagine it ? 20 timeframes x number of symbols in 'Market Watch' and for each one the OnNewBar event is generated? And you have to process each one, to determine which symbol and timeframe it refers to? Now you have the choice: to write your own function NewBar and in it to define what you want to receive new bars: all periods for a symbol, all symbols for the current period or some special case. This makes a simple function. It is better than the universal OnNewBar function with many checks.

20 timeframes... it's not the limit for a ulong parameter... filling a whole variable once in a minute is right, not hard...

Why, OnTick looks at "x number of characters in the 'Market Watch' and generates an event for each..." ?????

And the bit check is, believe me, a pretty fast thing...

And even with an event

- no one's going to make me process it - no need...

- And even if you have an event, nothing prevents you from adding or substituting "write your own NewBar function and define if you want to get new bars" - if necessary...

[Vladimir Kustikov]

Interesting:

Even now it's easy to do, if you know how to do it. The developers promised to rewrite OnTrade() and add the necessary parameters there.

No one prevents such situations from being handled locally, in OnTick() or OnTime() - at the trade operation place; or in OnTrade(), if you need to catch user actions or trade operations not controlled directly by code.

Lightness is a relative concept and for one it is measured in grams, for another in tons. In my Expert Advisor I had to do it HOWEVER (if my code can be called that), because there are no PROSTO variants in my language now, while they could very well exist, imho. And I wasn't particularly happy about the code becoming a hundred lines longer and making it seem more complicated.

Here is the problem in general:

A tick comes, the indicator shows the need to close, I close

When the next tick comes, the indicator shows that it has to close, and I don't know what to do - the position is already positioned and it is impossible to find out what is happening at the moment, of course, but I don't know.

I don't understand why this complexity is still present here? I do not understand why we have to write a ton of code in the onTrade() event to understand what has happened?

I am for simplicity, and when it is not there, it makes me sad

[Дмитрий]

Vladix:

Lightness is a relative concept, and for one it is measured in grams, for another in tons. I had to do it in EA (if my code can be called as such), because there are no PROSTO variants in the language now, while they could very well exist, imho. And I wasn't particularly happy about the code becoming a hundred lines longer and making it seem more complicated.

Here is the problem in general:

A tick comes, the indicator shows the need to close, I close

When the next tick comes, the indicator shows that it should close, and I don't know what to do - the position is already hanging, and of course I can find out what's happening at the moment, but I don't know.

I don't understand why this complexity is still present here? I don't understand why in the onTrade() event we are suggested to write a ton of code to understand what has happened?

I am for simplicity, and when it is not there, it makes me sad

I did so, the code is less than a hundred lines ... :) The solution is reliable and immediately for multicurrency

//+----------------------------------------------------------------------------+
// Функция контроля открытия ордера на текущем баре               MQL5         |
//-----------------------------------------------------------------------------+
bool ЕстьОрдернаТекущемБаре(ENUM_ORDER_TYPE тип)
  {
   ulong тикет;
   HistorySelect(SeriesInfoInteger(СИМВОЛ,Period(),SERIES_LASTBAR_DATE),TimeCurrent());
   for(int i=0;i<HistoryDealsTotal();i=i+1)
     {
      тикет=HistoryDealGetTicket(i);
      if(HistoryDealGetString(тикет,DEAL_SYMBOL)!=СИМВОЛ || HistoryDealGetInteger(тикет,DEAL_ENTRY)==DEAL_ENTRY_STATE)// || HistoryDealGetInteger(тикет,DEAL_MAGIC)!=MAGIC
         continue;
      if(HistoryDealGetInteger(тикет,DEAL_TYPE)==тип || HistoryDealGetInteger(тикет,DEAL_TYPE)==DEAL_ENTRY_INOUT)
         return(true);
     }
   return(false);
  }

You can specify any desired period instead of the one at which the EA is hovering. I.e. orders will be placed no more than once per period

And after any trade request, we should make a delay that prohibits the trade request within 30 sec (for example). Otherwise, the order may not appear in the history on the next tick.

[[Deleted]]

Valmars:
In general, how do you imagine it ? In general, the idea is to have 20 timeframes x the number of symbols in the 'Market Watch' and for each of them the OnNewBar event is generated? And you have to process each symbol and timeframe to determine which one it refers to? Now you have the choice: to write your own function NewBar and in it to define what you want to receive new bars: all periods for a symbol, all symbols for the current period or some special case. This results in a specific and uncomplicated function. It is better than a universal OnNewBar function with a lot of checks.

In terms of a standard solution, it should look something like this

1. The event should be bound to the open chart, its period and symbol. The event must occur when a new bar appears (holes are ignored).

Events must be handled in a separate terminal thread (or threads).

PS

So on. Of course, this is a rough approximation without taking into account many specifics...

[[Deleted]]

Vladix:

Actually the problem itself is this:

a tick comes in, the indicator shows it needs to close, I do the closing

When the next tick comes, the indicator shows that it must close, and I don't know what to do - the position is already hanging and one can know what is happening at the moment, of course, but in the middle of nowhere.

I do not understand why this complexity is still present here? I do not understand why in the onTrade() event we are suggested to write a ton of code to understand what has happened?

I'm for simplicity, and when you don't have it, it becomes sad

Perhaps, the developers will add parameters to OnTrade(), at least they were thinking about it. As far as I know there were even some statements about it.

[Vladimir Kustikov]

Dmitriy2:

Made it this way, less code than a hundred lines... :) solution is reliable and immediately for multicurrency

Instead of the period on which the EA is dormant, we can specify any desired one. This means that orders will be placed no more than once per a period.

And after any trade request, we should make a delay that prohibits the trade request within 30 sec (for example). Otherwise, the order may not appear in the history on the next tick.

Put a delay - yes, I accept, how many lines of code will it take? And if we're talking about multi-currency, it's necessary to account for the delay on each one, isn't it?

I wrote the code that solves this. Only I don't like it, just as, sorry, I don't like yours. And it's not about bias, the point is that there are no other options, simple and elegant.