Visual studio sulla piattaforma MT4. - pagina 4

 

Potete vedere come saranno le informazioni tecniche e le istruzioni per creare la GUI del motore grafico seguendo questo link:

https://www.youtube.com/watch?v=ciVqJwgIIyg&feature=youtu.be#t=66.940294

 
Реter Konow:

Per quanto ne so, attualmente non c'è modo di trasferire un'interfaccia creata in MS Visual Studio a un grafico della piattaforma MT.

Perché lo pensa? Beh, c'è, e ce ne sono diversi. Anche se non è chiaro perché esse, le interfacce, dovrebbero essere trasferite alle trame, se è così, probabilmente non esistono. Ma è abbastanza realistico farli sopra MT
 
Реter Konow:

...

Questo significa che l'utente sarà completamente isolato dal codice e dal compilatore in tutte le questioni relative alla creazione dell'interfaccia grafica del suo programma, e avrà a che fare solo con gli strumenti di controllo visivo offerti dallo studio. Il design dell'interfaccia utilizzerà la tecnologia "drag and drop" e le varie finestre di opzioni, attraverso le quali è possibile definire le proprietà dei modelli di finestre e controlli già pronti.

...

... Questo motore ...per fondersi con l'applicazione dello sviluppatore ed eseguire tutto il lavoro grafico.

Ma come si integrerebbe con l'app dello sviluppatore, se non tramite codice? Supponiamo che un programma debba produrre una tabella simile a Market Watch. Poi dovremmo inviargli l'istruzione che "EURUSD" deve essere visualizzato nella cella "A1", il prezzo "1.238273" deve essere visualizzato in A2, ecc. Tuttavia, un insieme di strumenti sarà diverso da terminale a terminale e staticamente i campi e i nomi delle tabelle non possono essere riempiti.

Microsoft Visual Studio è tutto chiaro - è un comodo add-on per il puroAmbiente software creazione di applicazioni. Cioè, Visual Studio non è proprio un ambiente di sviluppo visivo, e nel caso del vostro programma, non è chiaro come funzionerà.

 
Vasiliy Sokolov:

Ma come si integrerà con l'applicazione dello sviluppatore se non attraverso il codice? Supponiamo che il programma debba produrre una tabella simile a Market Watch. Poi dovrebbe ricevere l'istruzione che "EURUSD" deve essere messo nella cella "A1", il prezzo "1,238273" in A2, ecc. Tuttavia, un insieme di strumenti sarà diverso da terminale a terminale e staticamente i campi e i nomi delle tabelle non possono essere riempiti.

In Microsoft Visual Studio è chiaro: è un comodo add-on per il puroambiente software creare applicazioni. Cioè, Visual Studio non è proprio un ambiente di sviluppo visivo, e nel caso del tuo programma non è chiaro come funzionerebbe.

Al momento, una soluzione per combinare il motore grafico e la funzionalità dell'applicazione utente è in sviluppo.

Posso solo presentarvi il concetto generale.

Quando si scrive la propria applicazione, lo sviluppatore dovrà salvare i valori delle variabili restituite dalle sue funzioni personalizzate (per esempio, il valore del prezzo corrente Bid su "EURUSD") non all'interno della sua applicazione ma all'esterno.

Questo significa che invece dei propri nomi di variabili, dovranno scrivere l'indice di una cella di un array di memoria condivisa (situata al di fuori del loro programma) e memorizzare lì il valore restituito dalla funzione.

Questo array globale lo chiamo "kernel di parametri". Poi, l'utente assegnerà l'indirizzo di questa cella al controllo nello studio. A sua volta, il motore grafico fa un ciclo periodico attraverso gli oggetti e guarda gli indirizzi dei parametri legati ad essi nel kernel dei parametri. Se un valore a quell'indirizzo è stato cambiato da una funzione utente, il motore lo aggiornerà nella finestra. O viceversa - se il valore è stato cambiato da un controllo, la funzione utente accetterà la sua elaborazione.

In sostanza, questa soluzione è una simbiosi di due programmi che comunicano su una memoria condivisa, chiamata "kernel di parametri". Entrambi i programmi, il motore GUI e il programma utente, saranno collocati su grafici diversi all'interno del terminale.

L'unico problema è la creazione della memoria condivisa. Cercando di risolverlo con MQL, non voglio ricorrere a una DLL, ma se non c'è via d'uscita, si può creare una memoria condivisa lì. L'ho già fatto.

 
Реter Konow:

L'unico problema è creare la memoria condivisa. Cercando di risolverlo con MQL, non voglio ricorrere a una DLL, ma se non c'è via d'uscita, è possibile creare memoria condivisa lì. Ho già fatto questo.

Una volta che si ricorre a una DLL, non rimane nulla del vostro concetto. Proprio niente - Pschick. Con una DLL, e anche senza una DLL, il vostro problema può essere risolto senza sviluppare nulla. E questo è il concetto di base della programmazione moderna - non sviluppate nulla da soli, se è già stato creato.
 
Yuriy Asaulenko:
Perché lo pensa? C'è, e anche qualcuno. Ma non è chiaro perché esse, le interfacce, dovrebbero essere trasferite nei grafici - se è così, probabilmente non esistono. Ma è abbastanza realistico sovrapporli a MT.
Per favore, sii più specifico.
 
Yuriy Asaulenko:
Una volta che si ricorre alla DLL, non rimane nulla del vostro concetto. Proprio niente - Pschich. Con una DLL, e anche senza una DLL, il vostro problema può essere risolto senza sviluppare nulla.
Per favore, spiegate la vostra opinione.
 
Реter Konow:
Sii specifico per favore.

Su cosa essere specifici? Creare finestre in VS sopra MT? Questo è un uccellino - in cima a tutte le finestre.

Scambio di dati con VS? 4 modi almeno.

 
Реter Konow:
Per favore, spiegate la vostra opinione.
Vedi il post precedente, o sii più specifico, per favore. Finestre di qualsiasi tipo, senza alcuno sforzo.
 
Реter Konow:

L'unico problema è creare la memoria condivisa. Cercando di risolverlo con MQL, non voglio ricorrere a una DLL, ma se non c'è via d'uscita, è possibile creare memoria condivisa lì. L'ho già fatto.

Naturalmente si può organizzare la comunicazione via DLL, ma nessuno ne avrà bisogno, perché il mercato vieta qualsiasi DLL. L'unico modo per organizzare lo scambio globale di dati tra i due programmi, in termini di MQL standard - è lo scambio attraverso variabili globali. A proposito, ecco una libreria molto bella per lo scambio di dati tramite variabili globali:https://www.mql5.com/ru/code/12786.

In generale, non è molto chiaro per chi state creando il vostro studio. Se per gli sviluppatori la vostra soluzione non ha API. Nessuno vuole trascinare un'applicazione separata, con la quale il programma scambierà dati, specialmente per i programmi inseriti nel Market.

Anche la soluzione con licenza utente, imho, è un'opzione molto infelice. Ecco un programmatore ha sviluppato un programma basato sul vostro studio, pagato per il primo mese di lavoro, e poi nel secondo mese, il suo programma non funzionerà, perché il nucleo grafico del vostro studio ha richiesto un'altra tassa. Sciocchezze. Nessuno sviluppatore baserebbe il suo progetto su un pacchetto che chiede costantemente tasse aggiuntive. Ma anche se immaginiamo che la licenza sarà acquistata come una somma forfettaria, e lo studio stesso sarà una parte dell'applicazione, allora di nuovo non è chiaro come funzionerà nel mercato (programma con licenza con un'altra licenza al suo interno).

Ancora, rispondi alla domanda principale: per quale pubblico di riferimento è stato creato il tuo progetto? Perché l'utente medio avrebbe bisogno del vostro studio? Vuole creare Microsoft Word in MetaTrader 5? Certo, è forte, ma PERCHE'? La gente paga per soluzioni pronte. Per programmi e algoritmi che fanno un lavoro specifico. Non hanno bisogno di creare moduli. Hanno bisogno di programmi. E i programmatori che scrivono questi programmi non possono usare il vostro studio, perché il lavoro è organizzato in modo molto strano.

Comprendete che in questo momento l'enfasi deve essere posta sul mercato. Se volete creare un progetto d'infrastruttura, dovete prima di tutto rispondere alla domanda: "Perché i programmatori, che fanno affari nel mercato, o che lavorano in Freelance, inizieranno a usare il mio studio. Che cosa darà loro?".