come creare oggetti in modo dinamico? (Alcune cose OOP) - pagina 5
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
2. Framework from scratch.
Similar here. When I started to go a bit deeper into the standard libraries I found many things, which I did not like. Not only the bad performance of those, but also lack of flexibility and also because of an incomplete architecture. I am missing for example a global CMouse class/object as well as a class between CWnd and CObject, because CWnd objects are childs of the chart as well as lines are, and there is no connection to such and no final implementation of any such objects at all like I described it above. And, there is no master object, which holds all such chart objects which makes it possible to show/hide all of them with one command, destroy them, whatever. CCanvas, same thing, a nice class but where is the implementation with CWnd which allows me to create interactive objects based on bitmaps that inherit from CWnd? And so on.
Qual è il ruolo di un CMouse globale? Serve all'utente finale solo come classe autonoma, per avere un facile accesso alla gestione del mouse? Come si relaziona con il framework?
Per quanto riguarda la classe tra CWnd e CObject, non seguo la tua spiegazione sul perché li hai trovati necessari. Gli oggetti CWnd sono figli del grafico, così come le linee - non capisco il problema in questo, e perché non c'è connessione?
Dici anche che non c'è alcuna implementazione finale di tali oggetti come hai descritto sopra? (dove hai descritto?)
L'opportunità di un oggetto mouse globale è, almeno nella mia GUI, di salvare tutte le informazioni sul mouse (posizione, posizione di pressione, prezzo della posizione ecc. Inoltre l'oggetto mouse contiene informazioni sull'uso esclusivo del mouse, per esempio quando si trascina. Questo fa risparmiare molto tempo alla CPU mentre qualcosa viene trascinato o sta per essere cliccato ecc.
Ultimo ma non meno importante: Niente della libreria standard funziona in strategy tester quando viene usato negli EA perché non ci sono eventi del mouse. E se volete implementare il supporto al mouse in strategy tester, sarete grati anche per una tale classe per il mouse, perché la classe non si preoccupa da dove provengono le informazioni sui movimenti del mouse, ma gli oggetti che hanno bisogno delle informazioni sanno ancora dove devono cercare.
---
Non è solo la classe tra CWnd e CObject che mi manca, in realtà è più l'oggetto/contenitore master mancante che contiene oggetti basati sui pixel e oggetti basati sul tempo/prezzo. Come hai detto anche tu, sono tutti oggetti del grafico, quindi il master logico dovrebbe essere un oggetto che rappresenta il grafico e che contiene tutti gli oggetti. E per realizzare ciò, ci deve essere una classe tra CWnd e CObject.
Lo sfondo di questa idea non è solo la logica, è anche una questione di prestazioni. Nel mio caso, quando il grafico cambia in qualche modo, l'oggetto master lo rileva, mette in loop tutti gli oggetti contenuti che possono essere contenitori di linee, contenitori di CWnd così come ogni singolo oggetto di uno di questi tipi, e "informa" ogni oggetto che vuole essere informato da questo. Questo significa solo che c'è un unico ciclo esattamente in un punto del codice, e a causa dell'uso con contenitori e sottocontenitori, questo è estremamente efficiente.
Uso anche questo master per congelare tutti gli oggetti in una volta e per prevenire qualsiasi aggiornamento fisico con una sola linea di codice. La differenza di prestazioni è drastica. Esempio: Quando creo tutti gli oggetti visivi di cui ho bisogno per il mio EA, e in alcuni casi questi sono più di 1000, congelo questo oggetto master in anticipo, creo gli altri oggetti e lo "scongelo" dopo, il che si traduce in un aggiornamento fisico del grafico. Senza congelamento, questo processo può richiedere un intero minuto. Con il congelamento, è meno di 2 secondi.
Prima di iniziare a creare la GUI da solo, ho provato davvero con le libs standard. In seguito, ho cercato di mantenere almeno alcune parti. Ma il problema era che era semplicemente impossibile realizzare ciò che avevo in mente a causa di un'implementazione incompleta e un'architettura che è un po' ... LetsMakeSomethingThatWorksSomehowForWeDontKnow. La performance visiva è raggiunta con una chiara gerarchia, ma le librerie standard sono in qualche modo anarchiche.
Comunque, non sono la prima persona che ha riconosciuto questo. E come Alain ha già menzionato, non sono sicuro che questo aiuti davvero, perché è troppo teorico. Posso solo parlare della mia esperienza con tutta questa roba che non è solo basata su MQL, ma la mia opinione è comunque solo la mia opinione e naturalmente non è legge.
Ma per il secondo tipo, il modo di pensare e le considerazioni discusse qui sono molto preziose e anche molto pratiche. Naturalmente un articolo sarebbe meglio, ma comunque.
Non credo che la gente costruirà quadri dopo aver letto solo questo thread, ma ha ancora buoni pezzi di informazioni e intuizioni, che sembra che mancano anche per le persone che hanno già costruito quadri MQL pubblici.
Quindi, per il mouse e il tester se ho capito bene si usa il ::OnTester() per chiamare il mouse invece di un input utente, se ti seguo.
Grazie ancora, Doerk.
L'opportunità di un oggetto mouse globale è, almeno nella mia GUI, di salvare tutte le informazioni sul mouse (posizione, posizione di pressione, prezzo della posizione ecc. Inoltre l'oggetto mouse contiene informazioni sull'uso esclusivo del mouse, per esempio quando si trascina. Questo fa risparmiare molto tempo alla CPU mentre qualcosa viene trascinato o sta per essere cliccato ecc.
Ultimo ma non meno importante: Niente della libreria standard funziona in strategy tester quando viene usato negli EA perché non ci sono eventi del mouse. E se volete implementare il supporto al mouse in strategy tester, sarete grati anche per una classe mouse, perché la classe non si preoccupa di dove provengono le informazioni sui movimenti del mouse, ma gli oggetti che hanno bisogno di queste informazioni sanno comunque dove devono cercare.
O mi manca qualcosa?
L'oggetto mouse non guarda se è sopra un oggetto o se è attualmente in uso da un oggetto, questo viene fatto dagli oggetti stessi. Ma l'oggetto mouse è il "luogo" centrale dove tali informazioni possono essere memorizzate.
Le classi di controllo standard funzionano così, che ad ogni movimento del mouse tutti gli oggetti sono messi in loop per capire se questo movimento ha qualcosa a che fare con loro, questo richiede molto tempo di CPU che può essere visto facilmente quando si avvia il task manager e basta muovere il mouse quando un EA o un indicatore è caricato e un oggetto CDialog è parte dell'EA o dell'indicatore. Più complessa è la finestra di dialogo, maggiore è l'utilizzo della CPU.
Nella mia GUI, con l'esistenza di un oggetto mouse globale, questo viene fatto diversamente. Puoi avere 10000 oggetti e l'utilizzo della CPU non cresce affatto quando il mouse viene spostato. È fatto in questo modo, che solo appena il pulsante del mouse scende su un oggetto specifico, questo specifico oggetto informa l'oggetto mouse che ha il focus, e appena il mouse si muove dopo questo evento di button-down, nessun altro oggetto ha bisogno di occuparsene, e ogni ulteriore movimento del mouse / ogni ulteriore evento di mouse-move è indirizzato direttamente all'oggetto che ha il focus - che è sempre esclusivo - usando il suo puntatore.
E per la circostanza che tutti gli oggetti grafici, non importa se questi sono basati su tempo/prezzo (linee di tendenza ecc.) o su coordinate pixel (pannelli ecc.) hanno una classe base comune, tutti questi oggetti possono usare un insieme comune di funzioni sovraccaricate per gestire questo. Questo è anche il motivo per cui ho detto che manca una classe tra CWnd e CObject, perché questa classe di base tra è la stessa classe di base che è usata anche dagli oggetti basati su tempo/prezzo e solo questo rende possibile comunicare efficacemente e gestire efficacemente tali eventi.
Sì.
Tuttavia ho la possibilità di catturare qualsiasi movimento se cliccato o meno, e anche con migliori prestazioni della CPU e senza usare i nomi degli oggetti, ma non era questa la domanda qui.