Errori, bug, domande - pagina 362

 
Lizar:
La necessità di tale funzionalità aumenterà con l'aumentare del numero di tipi di oggetti. E diventerà necessario quando si creano oggetti in cui non è possibile determinare il numero di punti di ancoraggio dal loro tipo. Per esempio, può essere una polilinea di qualche tipo. Ma per ora non è molto critico, ma può essere eseguito come un desiderio nel servizio Desk.

Per ora, è più realistico (se ce n'è bisogno) creare una funzione di commutazione che dia il numero di punti di ancoraggio per tipo di oggetto.

Basta fare questa tabella (MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types) in switch. Il parametro di ingresso della funzione sarà ObjectGetInteger(chart_id,name,OBJPROP_TYPE).

Non ci sono pericoli nascosti poiché tutti i tipi sono rigidamente legati a punti di ancoraggio. Ma se appaiono gli oggetti con un numero variabile di punti, allora ci sarà un disperato bisogno di una tale funzionalità.

 
Urain:

Ora, il modo più realistico (se ne avete bisogno) è quello di creare una funzione di commutazione che darà il numero di punti di ancoraggio in base al tipo di oggetto.


Ho chiesto una proprietà in ObjectGet molto tempo fa.

mi sembra che questo abbia a che fare con la logica stessa nelle viscere di MT5.

Probabilmente passa solo attraverso tutti i punti e controlla se sono VUOTI. E se un punto ha una cifra normale, costruisce.

Quindi non c'è una relazione diretta tra il tipo di oggetto e il numero di punti di ancoraggio.

Per questo hai notato correttamente che devi fare il cambio da solo.

 
Urain:

Ora, il modo più realistico (se ne avete bisogno) è quello di creare una funzione di commutazione che darà il numero di punti di ancoraggio in base al tipo di oggetto.

Basta fare questa tabella (MQL5 Reference / Standard constants, enumerations and structures / Object constants / Object types) in switch. Il parametro di ingresso della funzione sarà ObjectGetInteger(chart_id,name,OBJPROP_TYPE).

Non ci sono pericoli nascosti poiché tutti i tipi sono rigidamente legati a punti di ancoraggio. Ma se avremo nuovi oggetti con un numero variabile di punti, avremo davvero bisogno di questa funzionalità.

sergeev:

Ho chiesto una proprietà in ObjectGet molto tempo fa.

Se ci saranno oggetti con un numero variabile di punti, allora una tale funzionalità sarà estremamente necessaria.

Probabilmente passa solo attraverso tutti i punti e controlla se sono VUOTI. E se un punto ha una cifra normale, costruisce.

Quindi non c'è una relazione diretta tra il tipo di oggetto e il numero di punti di ancoraggio.

Se c'è un numero variabile di punti, allora ci sarà un estremo bisogno di tale funzionalità.

Sì, come ho scritto sopra, l'ho implementato tramite interruttore. Funziona senza problemi. Ma l'idea va oltre, voglio più comodità e universalità.

A proposito, penso che sarebbe bene permettere agli utenti di creare i propri oggetti. Per esempio, permettere almeno di unire gli oggetti standard in gruppi con un "marchio" comune. In modo che sia possibile riferirsi a un gruppo di oggetti come uno solo. Poi ci sarebbero alcuni oggetti complicati come polilinee, anelli, tori... e così via. E anche gli oggetti di qualche pannello di controllo potrebbero essere uniti. E Ctrl-B non produrrebbe un foglio di oggetti, ma nomi ordinati di gruppi di oggetti, o qualcosa di simile. Inoltre, il problema di ricevere 100000 eventi da oggetti modificati in OnChartEven() handler sarebbe risolto, perché questi 100000 oggetti potrebbero essere uniti in un gruppo e ricevere solo un evento CHARTEVENT_OBJECT_CHANGE. Tutto sommato, sarebbe una bellezza. Naturalmente, è possibile implementare parzialmente tutto questo attraverso le classi, ma non tutto.

 

Lizar:

........ E Ctrl-B darebbe non un foglio di oggetti, ma nomi ordinati di gruppi di oggetti, o qualcosa del genere...........

....... come questi 100000 oggetti potrebbero essere combinati in un gruppo e ricevere un solo evento CHARTEVENT_OBJECT_CHANGE. Tutto sommato, una bellezza.......

Sognate, ma non fatevi illusioni.

:)

 

Sto scrivendo un indicatore per visualizzare le candele di diversi strumenti contemporaneamente. Dopo averlo avviato e prima che appaiano le nuove barre, tutto viene visualizzato correttamente:

Ma dopo l'apparizione di nuovi bar c'è un cambiamento:

E ChartRedraw non aiuta. Anche se, se premo il tasto giusto-refresh, tutto è a posto. Puoi dirmi come evitare lo spostamento?

Обработчик события "новый бар"
Обработчик события "новый бар"
  • 2010.10.04
  • Konstantin Gruzdev
  • www.mql5.com
Язык программирования MQL5 позволяет решать задачи на совершенно новом уровне. Даже те задачи, которые уже вроде имеют решения, благодаря объектно-ориентированному программированию могут подняться на качественно новый уровень. В данной статье специально взят простой пример проверки появления нового бара на графике, который был преобразован в достаточно мощный и универсальный инструмент. Какой? Читайте в статье.
File:
 

È doppio price; normalizzato automaticamente in MqlTradeRequest? (che è improbabile) e se no, perché non c'è ancora normalizzazione nella libreria standard? (Ho sollevato questa questione 9 mesi fa).

Sono uscito dalla situazione semplicemente facendo delle modifiche nella libreria standard, ma sapete che non è il caso (viene abbattuta quando si aggiorna).

bool CTrade::PositionOpen(const string symbol,ENUM_ORDER_TYPE order_type,double volume,
                          double price,double sl,double tp,const string comment)
{
...
m_request.price       =price; // ??????????
...
}

Se mi sbaglio, allora indicare in che cosa?

Документация по MQL5: Стандартная библиотека
Документация по MQL5: Стандартная библиотека
  • www.mql5.com
Стандартная библиотека - Документация по MQL5
 

Non facciamo la normalizzazione automaticamente, poiché non ci è permesso cambiare il prezzo del commerciante per non essere accusati di arbitrarietà.

Devi normalizzare tu stesso il prezzo se stai usando il prezzo calcolato. Quando un ordine viene piazzato con prezzi netti Bid/Ask invariati, la normalizzazione non è necessaria.

 
Renat:

Non facciamo la normalizzazione automaticamente, poiché non ci è permesso cambiare il prezzo del commerciante per non essere accusati di arbitrarietà.

Devi normalizzare tu stesso il prezzo se stai usando il prezzo calcolato. Quando un ordine viene piazzato con prezzi netti Bid/Ask invariati, la normalizzazione non è necessaria.

Grazie, ho trovato quello che volevo. Ho dovuto normalizzare anche bid/ask in 4.
 
Urain:
Grazie, ho trovato quello che volevo. Anche il bid/ask doveva essere normalizzato in 4.

In realtà, in MT4 non è necessario normalizzare Bid e Ask. Sono sempre normalizzati per default.

Se avete un esempio a portata di mano, mostratemelo per favore.

 
Renat:

In realtà, in MT4 non è necessario normalizzare Bid e Ask. Sono sempre normalizzati per default.

Se avete un esempio a portata di mano, per favore mostratemelo.

Non ho un esempio a portata di mano, è stato molto tempo fa (forse le build attuali vanno bene), una volta c'erano problemi tali che ottenevo requotes in MT4 anche richiedendo Bid e Ask, dopo la normalizzazione tutto è andato meglio, quindi c'era una regola per normalizzare qualsiasi richiesta. E si sa, l'abitudine è una seconda natura.