Creazione di una GUI per MQL in modalità grafica. - pagina 9

 
Алексей Барбашин:

Ora puoi solo affilarlo ))

Non è la mia opzione. ))
 
Alexey Volchanskiy:

Ancora solo emozioni.

Alexey, cosa vuoi? Sei un po' confuso dopo gli eventi felici :-)

Nessuna emozione - il vostro amore per .net è un prodotto della gestione e dell'emozione. Bisogna pesare i pro e i contro prima di prendere una tecnologia e correre come i lemming.
c .netprogetto richiede 2 gusci per lo sviluppo (MT e VS). Un netleneck C++ può essere creato senza lasciare l'ambiente comune.
Debuggare .net dll in esecuzione da MT5, con una protezione crescente dal debugging e dal tracing, può essere facile, ma personalmente non ne ho bisogno.

Sovrapposizioni su chiamate DLL, ci sono anche loro. E nel modello di runtime quando MT è solo in polling, sono molto sensibili. Se eseguiamo il calcolo dell'ipercubo nella DLL, non lo noteremo.
Ma se state costantemente sondando il modulo, se il dannato utente ha premuto OK, allora uh-oh. E nei tuoi bagarini preferiti :-)

 
Alexey Volchanskiy:

Ancora nient'altro che emozioni.

L'ignoranza dà fiducia. Ma la conoscenza moltiplica il dolore.

Si obietterà quando:
- una macchina virtuale aliena ed enorme entra nel tuo processo
- dirotta i tuoi estratti e pensa di essere il maestro
- mangia un sacco di memoria e pensa di essere il padrone
- gestire un mucchio di fili che hanno una vita propria.
- il raccoglitore di rifiuti cresce al massimo e limita il tuo processo.
- tutte le chiamate attraverso il wrapper

Per il bene della gui, è decisamente eccessivo.
 
Maxim Kuznetsov:

Alexei, cosa vuoi? Sei un po' confuso dopo gli eventi gioiosi :-)

Nessuna emozione - il vostro amore per .net è un prodotto della gestione e dell'emozione. Bisogna pesare i pro e i contro prima di prendere una tecnologia e si corre come lemming.
Un progetto .net richiede 2 shell per lo sviluppo (MT e VS). C++ netleneck può essere sviluppato senza lasciare l'ambiente comune.
Debuggare .net dll, lanciato da MT5, con una protezione crescente dal debugging e dal tracing, può essere facile, ma personalmente non ne ho bisogno.

Sovrapposizioni su chiamate DLL, ci sono anche loro. E nel modello runtime quando MT fa esclusivamente i sondaggi, sono molto sensibili. Se eseguiamo il calcolo dell'ipercubo nella DLL, non lo noteremo.
Ma se state costantemente sondando il modulo, se il dannato utente ha premuto OK, allora uh-oh. E nei vostri bagarini preferiti :-)

Maxim, quando si tratta di feedback, non fa differenza se si usa net o C++. Per esempio, avete implementato una GUI in Tcl. Dopo tutto, avete anche un problema di feedback. Non dipende dall'ambiente di sviluppo. Se provate a ospitare la GUI su un grafico, lo stesso problema si presenterà con il rendering. Non è che ci sia proprio una discussione sulle prestazioni nel thread. È una questione di gusti, fondamentalmente.

 
Renat Fatkhullin:
L'ignoranza dà fiducia. Ma la conoscenza moltiplica il dolore.

Ti dispiacerebbe quando:
- una macchina virtuale aliena ed enorme entra nel tuo processo
- dirotta i tuoi estratti e pensa di essere il maestro
- consuma un sacco di memoria e pensa di essere il padrone
- gestire un mucchio di fili che hanno una vita propria.
- il raccoglitore di rifiuti cresce al massimo e limita il tuo processo.
- tutte le chiamate attraverso il wrapper

Per il bene di una gui, è decisamente eccessivo.

Renat, visto che sei "entrato" nell'argomento, puoi dirmi come implementare il feedback tra applicazioni di terze parti, non importa in quale ambiente scritto, anche con C++, con MT.

 
Алексей Барбашин:

Renat, visto che ti sei "addentrato" nell'argomento, potresti dirmi come implementare il feedback tra un'applicazione di terzi, non importa in quale ambiente sia scritta, anche se è C++, con MT.

Non è vero. Anche all'interno di MT, tutto è solo tramite eventi MQ predefiniti.
Quindi, che differenza fa? Non è così.
 
Yuriy Asaulenko:
Non c'è modo. Anche all'interno di MT, tutto è solo predefinito. Eventi MQ.
Quindi che differenza fa? Non è così.

Beh, in MT è più facile, attraverso gli eventi. Se si verifica un evento, eseguiamo il comando, se non c'è un evento, ci riposiamo. E usare il timer per far sobbalzare un'applicazione esterna, non importa su cosa sia scritta, non è molto conveniente. Inoltre, a differenza della rete, MT non ha fili. Il timer e gli eventi avvengono tutti in un unico thread, il che impone le restrizioni corrispondenti. Se fosse possibile chiamare lo stesso OnChartEvent dall'esterno, molte questioni potrebbero essere risolte. Fondamentalmente non capisco perché c'è un divieto di chiamare questo metodo. Dopo tutto, MT intercetta gli eventi dell'ambiente: movimento del mouse, clic della tastiera o del mouse... Quindi in questo senso gli eventi interagiscono con il windup, quindi non è chiaro perché un evento utente non possa essere indirizzato anche lì. Sarebbe un mago universale.

 
Polling unidirezionale da µl, pip, file o richieste web.

Non possiamo usare le chiamate dirette al contrario. Anche se possiamo aggiungere un metodo come OnExternal con parametri, ma dobbiamo pensare al canale di trasferimento.

Può essere:
- un callbucket con parametri, registrato nella dll
- mutex chiamato come trigger
- messaggio di finestra per PostMessage

 
Алексей Барбашин:

Beh, in MT è più facile, attraverso gli eventi. Se arriva un evento, eseguiamo il comando, se non c'è un evento, ci riposiamo. Ma non è molto conveniente tirare a tempo un'applicazione esterna, non importa su cosa sia scritta. Inoltre, a differenza della rete, MT non ha fili. Sia il timer che gli eventi avvengono tutti in un thread, il che impone delle restrizioni corrispondenti.

Bene, il mio punto è che le applicazioni esterne hanno la stessa funzionalità, non diversa dai programmi MT, per quanto riguarda gli eventi MT.
 
Perché vi siete fermati a Dotnet per goo?

Forme semplici possono essere fatte facilmente in C++ e in altri linguaggi. E non ci saranno problemi di interfacciamento e perdita di risorse.

E in MQL5 è assolutamente facile fare interfacce in una lingua nativa.