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

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

Maxim, in che modo questa soluzione è migliore? Dopotutto, per controllare lo stato di un flag, deve essere controllato periodicamente anche in MQL. Così, si scopre che ovunque si guardi, è necessario monitorare costantemente i cambiamenti dello stato di qualcosa per capire che è il momento di raccogliere i dati. E questo frammento può essere memorizzato nella dll stessa e controllato lì - è quello che faccio io. Nel tuo esempio hai una chiamata implicita alla dll per restituire lo stato della bandiera.

Controllare la bandiera è un'operazione molto veloce. Intendo il più veloce in assoluto :-)

E non ci sono chiamate implicite in questo esempio:

InitDLL riceve int *flags come input, lo memorizza da qualche parte, genera una traccia che conta qualcosa e al termine fa atomic_inc(flags).

Il consulente deve solo controllare flags[0].

 
È per controllare. Questo è il punto chiave. Quello che sto suggerendo è che lo strumento dovrebbe essere notificato quando un "compito" viene completato. Cioè, in modo da non dover spendere risorse costanti per controllare. La notifica è arrivata - hai ricevuto i dati.
 
Maxim Kuznetsov:

controllare la bandiera è un'operazione molto veloce. Cioè, è il più veloce in assoluto :-)

E non ci sono chiamate implicite in questo esempio:

InitDLL riceve int *flags in input, lo memorizza da qualche parte, genera una traccia che conta qualcosa e fa atomic_inc(flags) al completamento.

Il consulente deve solo controllare flags[0].

Ma non si può fare nulla con il solo controllo della bandiera - è necessaria una sincronizzazione inter-thread, barriere, atomica o mutex quale prendere, ovviamente, per non tutte le CPU.


Alexey Barbashin:
Esattamente da controllare. Questo è il punto chiave. E suggerisco di avvisare lo strumento che il "compito" è stato completato. Cioè, non è necessario spendere risorse costanti per controllare. La notifica è arrivata - hai ricevuto i dati.
E come sono implementati tutti quei mutex? Tutto attraverso il controllo e l'impostazione delle bandiere, per quanto ne so. Dovete comunque controllare qualche bandiera da qualche parte nel thread di µl.
 
Maxim Kuznetsov:

controllare la bandiera è un'operazione molto veloce. Cioè, è il più veloce in assoluto :-)

E non ci sono chiamate implicite in questo esempio:

InitDLL riceve int *flags come input, lo memorizza da qualche parte, genera una traccia che conta qualcosa e al termine fa atomic_inc(flags).

L'EA deve solo controllare flags[0].

Max, beh, la situazione con il callback è chiara per ora. Useremo quello che abbiamo e aspetteremo che gli sviluppatori aggiungano la funzione di callback.

Voglio tornare alla questione della GUI. Non importa su cosa sia disegnato. Per esempio io lo faccio in Sharp, voi lo fate in Tcl.

Finché il modulo esiste da solo, non è affatto un problema. Ma mi piacerebbe molto che le forme non volassero da sole, ma che fossero legate alle carte appropriate.

Quando si imposta il genitore del modulo creato, questo viene posizionato sul grafico richiesto. Ma c'è un problema di "fusione" della finestra con il grafico e il grafico disegna solo la forma "incollata".

Suggerisco di provare a risolvere questo problema per ora, poiché è ancora al di fuori del campo d'azione degli sviluppatori di MT.

Hai provato ad allegare la tua GUI ai grafici?

 
pavlick_:

Ma non si può fare solo con il controllo delle bandiere, c'è bisogno di sincronizzazione inter-thread, barriere, atomica o mutex, che non è rilevante per ogni CPU, ovviamente.


E come sono implementati tutti i tipi di mutex? Tutto attraverso il controllo e l'impostazione delle bandiere, per quanto ne so. Dovete comunque controllare qualche bandiera da qualche parte nel thread di µl.

Abbastanza vero. Ma che avvenga a livello molto basso, di applicazione, come, per esempio, funziona con OnChartEvent. Cioè, ora lo programmiamo esplicitamente (controlli), ma tutto potrebbe essere trasferito a livello di applicazione, come ha detto Renat (ha suggerito alcune varianti).

 
Maxim Kuznetsov:

Sono giù :-) donare - puoi mandarlo a MS

066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb

se c'è qualcos'altro, potrei essere in grado di trovarlo.

Grazie, passato, ho una sterlina!

 
Alexey Volchanskiy:

Grazie, passato, ho una sterlina!

così è più redditizio di scalper! disposto a dare al dettaglio per un centesimo, li dai all'ingrosso per 1$/ten. il profitto è limitato solo dalla velocità di trasferimento :-) quanti kilobyte al secondo
 
Maxim Kuznetsov:
così è più redditizio di scalper! pronto a venderli al dettaglio per un centesimo, li vendi alla rinfusa per 1$/decine. l'unico limite è la velocità di trasmissione :-) alcuni kilobyte di GUIDs al secondo

Allettante come l'inferno. È così che conquisteremo il mercato delle GUID usate! E diventare un monopolio, creare una frenesia artificiale come con il bitcoin e diventare ricchi!

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

Max, beh, la situazione con il callback è chiara per ora. Useremo quello che abbiamo e aspetteremo che gli sviluppatori aggiungano la capacità di callback.

Voglio tornare alla questione della GUI. Non importa su cosa sia disegnato. Per esempio io lo faccio in Sharp, voi lo fate in Tcl.

Finché il modulo esiste da solo, non è affatto un problema. Mami piacerebbemolto che leforme non volassero da sole, ma che fossero legate alle carte appropriate.

Quando si imposta il genitore del modulo creato, questo viene inserito nel grafico richiesto. Ma c'è un problema di "fusione" della finestra con il grafico e il grafico disegna solo la forma "incollata".

Suggerisco di provare a risolvere questo problema per ora, poiché è ancora al di fuori del campo d'azione degli sviluppatori di MT.

Hai provato ad allegare la tua GUI ai grafici?

Non ho alcun bisogno di incatenare i moduli ai grafici.

Ci sono grafici operativi che sono direttamente collegati al grafico (tutti i tipi di linee, didascalie, iscrizioni, ecc.), questo è naturalmente fatto da strumenti di MT.

Ma ci sono GUI di gestione - impostazioni, rapporti, statistiche. Sono abbastanza grandi ed è un crimine contro l'utente metterli dentro un grafico :-)

Basta posizionare il modulo sopra il grafico. Sarà necessario rimuovere il modulo dal gestore delle finestre e tenere traccia dei cambiamenti nella geometria del grafico e del focus.
Un tale "tramonto a mano" :-) Almeno non entrerete nelle viscere di MetaTrader e non imporrete nuovi brividi e ganci alle sue finestre - cioè vi comporterete decentemente

Qualsiasi GUI chiamata dalla DLL ha la caratteristica più sgradevole - gli Expert Advisors/indicatori che la chiamano si riavviano periodicamente a causa del minimo starnuto. Il che porta alla riapertura dei moduli e a cascate di linguaggio scurrile...
Forse i "servizi" (o come si chiamano) annunciati da tempo saranno privi di questo inconveniente.

L'aggiornamento/ sul posizionamento di un modulo - metti RectLabel sul grafico e nel grafico-eventi per tracciare il cambiamento dei codini. Quando cambia - metti la sua forma rigorosamente in cima :-) Avete bisogno di un po' di tamburello quando cambiate scheda, minimizzate la finestra, per nascondere il vostro modulo in tempo
 
Alexey Volchanskiy:

Non hai spiegato proprio niente. Come fate a portare i dati da MT* al pannello sharpe?

Ho fatto il feedback tramite Memory Mapping con sondaggi a tempo. Il pannello trasmetteva solo diverse impostazioni e risultati di calcolo lenti

Ho un TC esterno, non ho bisogno di un feedback GUI al terminale.
1...6789101112131415
Nuovo commento