Wer kann diesem Zeichen schon widerstehen? Ich nicht

 

Okay, ich habe ein Konzept erstellt und erstelle gerade eine Testversion. Die funktioniert auch schon (unidirektional). Was habe ich vor? Siehe anhängendes Bild.

 

http://img291.imageshack.us/img291/8982/mtec.png

 

Der Name ist da, damit einfach einer vorhanden ist - gibt sicherlich bessere. Aber nun zum Inhalt.

 

MTEC.mq4 ist ein MQL-Sourcecode, welcher eigenständig arbeiten kann, aber auch in eigene EAs eingebunden werden kann. Darin sind DLL-Funktionen als Imports vorhanden. Mit den DLL-Funktionen kann ich mit einem externen Programm Kontakt aufnehmen, z.B. der geplanten GUI. Die Kommunikation erfolgt per TCP/IP, funktioniert somit lokal, aber auch remote z.B. im LAN oder über das Internet! In der GUI kann ich losgelöst vom Terminal Informationen darstellen und Kommandos zurücksenden, die dann in der MTEC.mq4 verarbeitet werden können.

 

Außerdem träume ich davon, dass ich eine Datenbankanbindung (Access reicht ja) habe. Ich möchte nämlich meine Orders mit Eigenschaften versehen, sodass ich bei Absetzen der Order gleich Informationen dranhängen kann. Mit diesen Infos an der Order kann ich im späteren Verlauf Ausstiege verarbeiten. Die Infos blieben dann auch beim Neustart des EAs vorhanden.

 

Ich erstelle gerade erstmal ein "proof of concept", eine Art Machbarkeitsstudie. Wenn die positiv verläuft, werde ich weiterentwickeln. Was geht bisher: Messages vom MT4 an die GUI. Sobald der Rückweg funktioniert, werde ich gerne mal die Version posten. Vorher nicht.

 

Für mich ist die TCP/IP-Verbindung wichtig, da ich beruflich viel unterwegs bin. Zu Hause läuft dann mein Computer mit EA und per Remote-GUI könnte ich meinem EA andere Parameter mitteilen (z.B. geänderte Markteinschätzung...).

 

Bis Ende nächster Woche müsst ihr euch gedulden (falls überhaupt Interesse besteht), vorher komme ich zeitlich nicht dazu.

 

Was könnte die Community leisten?

 

Testen, Ideen, Definition des Kommunikations-Protokolls, Definition der Standard-Funktionen... Wenn das Kommunikationsprotokoll zwischen DLL und GUI offen ist, könnten auch andere Programmierer eigene GUIs schreiben. Was auch immer.

 

Soooo - wie war das mit Thread Hijacking?

 

 

RAiNWORM

Zur Vorbeugung von Urheberrechtsmißbrauch/ Property Right Violation ausgelagert in ein zugriffsbeschränktes Forum (Original)

Aber nun zum Inhalt.

 

Klingt gut. Ein Knackpunkt könnte die schnelle Reaktion des MQL-Codes sein der die DLL einbindet. Der Code unter 'Start' wird ja nur mit jedem Tick ausgeführt, das kann mitunter dauern. Da wäre wahrscheinlich auch die Variante mit Sleep im Init-Teil eine Lösung.

 

Man könnte aber auch innerhalb der DLL diverse Werte schon auf Vorrat speichern so dass externes Programm und MQL Code dann schnellen Zugriff darauf haben.

 

Lutz

Ich erstelle gerade erstmal ein "proof of concept", eine Art Machbarkeitsstudie. Wenn die positiv verläuft, werde ich weiterentwickeln. Was geht bisher: Messages vom MT4 an die GUI. Sobald der Rückweg funktioniert, werde ich gerne mal die Version posten. Vorher nicht.

 

....

 

Was könnte die Community leisten?

 

Testen, Ideen

 

Mir fällt gerade noch ein: ich hatte hier mal einen MQL-Code gepostet der Daten zu einem externen Webserver sendet indem er eine URL aufruft. Auf dem gleichen Weg könnte man auch Anweisungen an den MQL-Code senden indem der Webserver die dann im HTML-Code mitsendet. Anbindung an eine Datenbank ist auf dem Webserver auch kein Problem.

 

Der Webserver muss auch nicht extern stehen, mit XAMPP lässt sich so etwas ohne Probleme ganz schnell auch lokla einrichten.

 

Nur so als Alternative.

 

Lutz

Erstaml: Genial das du das wirklich angehst ;)

 

@TCP/IP: Nochmal *G* Wie genau willst du das realisieren? Die dll als TCP Server und von außen kann sich dann hinverbinden wer will (mit zugriffsbeschränkungen etc.) sprich die GUI is dann recht unabhänigg und kann in beliebiger Sprache ausgefasst sein? Das wär natürlich schön.

 

Da ich beruflich gerade recht viel mit TCP/IP mach ne kurze Idee von mir (muss nicht beachtet werden, nur als Anregung ;):

• DLL spielt den Server (hab ehrlich gesagt mit dlls noch nicht viel gemacht, aber ich glaub/hoff das geht).
  
• Das Protokoll läuft über standardisierte Telegramme, die dll speichert sich ne liste der empfangenen telegramme.
  
• Der EA läuft im Hamsterrad (whileschleife) mit sleep(1) und kann damit im Millisekundenbereich reagieren (da die Order bei MT teils ein paar sekunden braucht bis sie durch ist, sind Millisekunden eh superschnell *G*) aber blockiert trotzdem nix.
  
• Zugriff von EA auf die DLL messages mit einer Funktion, die als Rückgabe zusätzlich sagt ob noch ein Telegram in der Warteschleife steht.
  

 

ich weiß nicht wie man das in DLLs am besten löst (bin im Moment reiner JAva-Programmierer ) aber das TCP-lesen sollte man vermutlich in eigenem Thread oder non-blocking machen, damit man immer den aktuellen Tick etc. durchkriegt.

 

Helfen kann ich dir wenn dann nur beim testen und bei Bedarf eine MTEC.jar bauen (dann wär der Client auch noch Plattformunabhängig *G*), wie gesagt DLLs hab ich mich noch nie so wirklich viel mit beschäftigt.

 

lg

 

Edit: @DB: wieso nicht MySQL? ist per C/C++ ja nicht so das Problem (genaugenommen richtig schön ;)

• DLL spielt den Server (hab ehrlich gesagt mit dlls noch nicht viel gemacht, aber ich glaub/hoff das geht).
  
• Das Protokoll läuft über standardisierte Telegramme, die dll speichert sich ne liste der empfangenen telegramme.
  
• Der EA läuft im Hamsterrad (whileschleife) mit sleep(1) und kann damit im Millisekundenbereich reagieren (da die Order bei MT teils ein paar sekunden braucht bis sie durch ist, sind Millisekunden eh superschnell *G*) aber blockiert trotzdem nix.
  
• Zugriff von EA auf die DLL messages mit einer Funktion, die als Rückgabe zusätzlich sagt ob noch ein Telegram in der Warteschleife steht.
  

 

Genau so läuft der MTEC auch schon (Spionage?? )! Also, die DLL beinhaltet den TCP/IP-Server, welcher von außen verbunden werden kann. Im Non-Blocking-Zustand nimmt er Nachrichten entgegen und speichert diese in einer Liste. Diese Liste kann aus einem EA via DLL Message für Message ausgelesen und verarbeitet werden. Das ist die Receive-Funktion. Wenn nichts in der Warteschleife steht, dann kommt ein Leerstring. Ich kämpfe momentan nur noch mit dem Problem der Stringrückgabe aus der DLL in den EA. Momentan bringe ich damit MT4 regelmäßig zum Absturz, aber das wird noch gelöst.

 

Edit: @DB: wieso nicht MySQL? ist per C/C++ ja nicht so das Problem (genaugenommen richtig schön ;)

Welche Datenbank verwendet wird, ist eigentlich egal. Ich würde gerne Access nehmen, da ab Win2000 automatisch die notwendigen Treiber auf Windowssystemen installiert sind (auch wenn kein Access selbst installiert ist!). Bei MySQL oder SQLServer (oder meiner Lieblingsdatenbank Oracle) müsste wirklich ein komplettes Datenbankmanagementsystem installiert werden. Finde ich etwas übertrieben ;-) OK, es gibt für MySQL auch so eine Art Lokalinstallation, aber selbst die will installiert sein.

 

Und ja, richtig: wenn die DLL steht, kann die GUI in jeder belieben Sprache geschrieben sein! Wir müssten uns nur auf ein Protokoll einigen (oder "Telegramme", wie du es nennst).

 

RAiNWORM

Klingt gut. Ein Knackpunkt könnte die schnelle Reaktion des MQL-Codes sein der die DLL einbindet. Der Code unter 'Start' wird ja nur mit jedem Tick ausgeführt, das kann mitunter dauern. Da wäre wahrscheinlich auch die Variante mit Sleep im Init-Teil eine Lösung.

 

Richtig, es wird auf eine While-Schleife (mit Sleep) hinausslaufen.

 

Man könnte aber auch innerhalb der DLL diverse Werte schon auf Vorrat speichern so dass externes Programm und MQL Code dann schnellen Zugriff darauf haben.

 

Also die DLL läuft (was zumindest den TCP-Server) anbelangt in einem eigenen Thread. Jede Nachricht wird entgegengenommen und gespeichert. Der MQL-Code kann dann, wenn er Zeit und Lust hat, die Nachrichtenliste sequentiell abarbeiten. Oder an was für Werte hast du sonst noch gedacht?

 

RAiNWORM

Diese Liste kann aus einem EA via DLL Message für Message ausgelesen und verarbeitet werden. Das ist die Receive-Funktion. Wenn nichts in der Warteschleife steht, dann kommt ein Leerstring.

d.h. du packst die message in einen String? wieso nicht direkt mit CallByReference? Ich würd auf alle Fälle als Rückgabe noch einen Statusflag dazunehmen ob es weitere Nachrichten gibt, damit in dem Fall sofort die nächste vom EA gelesen wird und nicht erst nach der nächsten Sleep-Phase.

 

Ich kämpfe momentan nur noch mit dem Problem der Stringrückgabe aus der DLL in den EA. Momentan bringe ich damit MT4 regelmäßig zum Absturz, aber das wird noch gelöst.

Ja, das Problem hat ich glaub ich auch mal... Das MT-DLL example kennst du sicher schon oder?

 

Und ja, richtig: wenn die DLL steht, kann die GUI in jeder belieben Sprache geschrieben sein! Wir müssten uns nur auf ein Protokoll einigen (oder "Telegramme", wie du es nennst).

Juhu ;) Wie das Protokoll aussieht, darfst du entscheiden, die Frage ist auch was die GUI alles können soll. Geht es um ein reines Tool zum schnellen kaufen/verkaufen, oder soll auch Chart, offene Positionen etc. angezeigt werden?

 

lg

Also die DLL läuft (was zumindest den TCP-Server) anbelangt in einem eigenen Thread. Jede Nachricht wird entgegengenommen und gespeichert. Der MQL-Code kann dann, wenn er Zeit und Lust hat, die Nachrichtenliste sequentiell abarbeiten. Oder an was für Werte hast du sonst noch gedacht?

 

An diverse Zustandsmeldungen und Werte vom MQL-Script. Wenn der die regelmässig der DLL mitteilt und diese dort gespeichert sind kann diese die sofort bei Anfrage an das anfragende Programme (z.B. ein GUI) weitergeben. Das wird schneller sein als wenn in dem Fall erst das MQL-Programm angefragt werden müsste, dort sehe ich einen potentiellen Flaschenhals.

 

Lutz

d.h. du packst die message in einen String? wieso nicht direkt mit CallByReference?

 

Ja, in einen String, der per CallByReference übergeben wird. Ich hatte erst eine Funktion, die prüft, ob Nachrichten in der Warteschleife sind, aber dann hätte man die Lesefunktion auch nochmal aufrufen müssen. Jetzt habe ich alles zusammengepackt: die Receive-Funktion hat Rückgabewerte 0=keine Nachricht, 1=Nachricht vorhanden. Im letztgenannten Fall wurde die Nachricht in den (by ref) übergeben String gestellt.

 

Ich würd auf alle Fälle als Rückgabe noch einen Statusflag dazunehmen ob es weitere Nachrichten gibt, damit in dem Fall sofort die nächste vom EA gelesen wird und nicht erst nach der nächsten Sleep-Phase.

 

Gute Idee! Ist eingebaut. Rückgabewert 2.

 

Ja, das Problem hat ich glaub ich auch mal... Das MT-DLL example kennst du sicher schon oder?

Das DLL-example habe ich mir nur kurz angeschaut. Die Lösung ist: strings in MQL sind structures. Die ersten 4 Byte enthalten (long int) die Länge des Textes, die nächsten 4 Byte den Zeiger auf das erste Zeichen des Textes. Hinzu kam noch, dass meine Programmierumgebung mit Unicode-Strings arbeitet, sodass ein Zeichen größer als 1 Byte war. Und zu allem Übel muss man Strings, wenn sie by ref übergeben werden sollen, als eindimensionales String-Array übergeben. Wenn ich den erwische der sich das ausgedacht hat!

 

Juhu ;) Wie das Protokoll aussieht, darfst du entscheiden, die Frage ist auch was die GUI alles können soll. Geht es um ein reines Tool zum schnellen kaufen/verkaufen, oder soll auch Chart, offene Positionen etc. angezeigt werden?

Zum Protokoll mache ich mir mal Gedanken und stelle den zur Diskussion...

 

Zum Tool:

Der erste Schritt wird sein: schnelles Kaufen/Verkaufen mit automatischem oder fixen SL/TP (anhand max. risk, CRV, was auch immer).

Der zweite Schritt wird sein: Absenden von "custom commands" an MT4. Das heißt, der Anwender kann selber Kommandos definieren, welche über die GUI abgesetzt und in seinem EA verarbeitet werden können (z.B. Umkonfigurieren von Parametern)

Der dritte Schritt: Erweiterung der GUI um offene Positionen (inkl. Risikobewertung).

Der vierte Schritt: Datenbankanbindung an die DLL, sodass ich zu meinen offenen Orders Informationen zusätzlich speichern kann (ab wann soll trailing stop gezogen werden etc.)

Der fünfte Schritt: .........

 

Das Ding wird glaube ich niemals fertig sein, da die Ideen niemals ausgehen werden.

 

Da ich es gerade geschafft habe, mache ich mal schnell ne Version fertig. Bis gleich

An diverse Zustandsmeldungen und Werte vom MQL-Script. Wenn der die regelmässig der DLL mitteilt und diese dort gespeichert sind kann diese die sofort bei Anfrage an das anfragende Programme (z.B. ein GUI) weitergeben.

Stimmt, finde ich wichtig. Kommt auf meine Liste. Ticks werden sofort gesendet, aber z.B. offene Orders (würden) nur auf Anfrage. Und da ist ein vorgehaltener Datenbestand wirklich schneller.

Hier ist sie, die TEST-Version. Hierbei ging es mir nur darum, ob die Idee überhaupt umsetzbar ist.

 

Wichtige Hinweise:

• aus Mangel an Tickdaten am Wochenende habe ich ein Script geschrieben
  
• nach 60sec beendet sich das Script automatisch
  
• das Script verweist auf die DLL im Pfad C:\Temp, entweder dort ablegen oder im Script anders einstellen
  
• absolut gar keine Fehlerbehandlung --> wenn was knallt, dann richtig (sollte aber nicht vorkommen)
  
• keine Konfigurationsmöglichkeit (IP fix 127.0.0.1, Port 28038)
  
• Kommandos müssen getippt werden
  
• Kommandos haben (bis auf close) keine Auswirkung und werden nur als MessageBox vom MT4 dargestellt
  
• für Endanwender bislang uninteressant ;-)
  

Die EXE kann liegen, wo sie will - aber momentan halt nur auf dem selben Rechner. Bei mir hatte die Windows Firewall gemeckert (weil ein TCP-Server aufgemacht wird), was bestätigt werden sollte.

 

Mich würde in erster Linie überhaupt erstmal interessieren, bei wem es (technisch) läuft und bei wem nicht.

 

Das MQL-Skript befindet sich direkt hier im Anhang. Alle Dateien gibt es >>hier

 

http://img24.imageshack.us/img24/9665/mtecprealpha.png

 

 

RAiNWORM

MTEC_testscript.mq4

Bearbeitet 15. Mai 201016 Jr. von RAiNWORM

Ihr gebt ja schon ordentlich Gas Jungs *bigsmile* Klasse!

 

*.exe liegt in

C:\Programme\MBT MetaTrader 4\MTEC_pre_alpha

Broker MB Trading

 

Ergebnis eines ersten Tests

 

 

 

 

#Edit: Pfad hatte ich angepasst

 

#import "C:\Programme\MBT MetaTrader 4\MTEC_pre_alpha\MTEC.dll" //

 

 

OK,

weils Script heisst, sollte es vermutlich auch in Script liegen, gell

 

 

Fehlermeldung taucht dennoch auf.

Schätze es liegt an mir ^^

Das Ding wird glaube ich niemals fertig sein, da die Ideen niemals ausgehen werden.

 

Das Problem kenn ich ;)

Ergebnis eines ersten Tests

 

 

Gleiches Problem bei betätigen des 'connect' Buttons in der exe, hier mit dll unter c:\temp\ wie im Original.

 

Wie erfolgt die Verbindung der Exe zur DLL? IP-Adresse? Local Host?

 

Die DLL muss ja auch gestartet werden, damit der IP-Server läuft. Sehe nach der Messagebox im MT4 auch nicht 'Comment("MTEC running");' im Fenster, vielleicht hilft das weiter.

 

Lutz

OK,

weils Script heisst, sollte es vermutlich auch in Script liegen, gell

 

Fehlermeldung tritt bei mir nur auf wenns ein EA ist. (und da auch nur deswegen weil kein Tick kommt, und damit die start() nie ausgeführt wird)

 

Also als script läufts einwandfrei

 

bzgl location: wenn die dll in experts/libraries liegt muss man keinen absoluten Pfad angeben sondern es reicht:

 

#import "MTEC.dll"

 

@whipsaw: ist bei den scripten dlls erlaubt?

@whipsaw: ist bei den scripten dlls erlaubt?

 

 

Jetzt ja ;.)

 

Für alle die Mit-Testen wollen, hier kurz die ToDo's.

 

 

 

*works*

 

Jetzt ja ;.)

 

 

Für alle die Mit-Testen wollen, hier kurz die ToDo's.

 

Danke, jetzt funktioniert es hier auch. Das Häkchen für die DLL unter Optionen für EAs fehlte.

 

Saubere Arbeit.

 

Lutz

Ich hab's auch mal ausprobiert.

Hab Pfad für DLL angepasst, DLLs erlaubt, Firewall disabled ... und läuft ohne Probleme.

 

Saubre Arbeit

 

absolut gar keine Fehlerbehandlung --> wenn was knallt, dann richtig (sollte aber nicht vorkommen)

 

Den "socket error" bekomm ich, wenn ich nach 60s bei "Script beenden" auf nein drücke. Denke aber, das

ist halt so noch nicht vorgesehen.

Wow, nicht, schlecht, dass ihr auch schon reingeschaut habt! Interesse scheint ja da zu sein.

 

@whipsaw: Danke. Ich hatte vergessen zu erwähnen, dass DLLs erlaubt werden müssen, da bei Scripts beim Start kein Konfigurationsfenster erscheint (bei EAs schon).

 

@mythos: Ich hatte die DLL schon überall liegen, auch unter libraries. Hatte er nie gefunden. Bei meinem Win7 64bit versteckt er Programmdateien überall. So liegen Scripte und EAs unter "VirtualStore". Und bevor ich lange suche, hatte ich einfach den DLL-Pfad fest eingestellt.

 

Wenn eines Tages ein ordentliches Fehlermanagement drin ist, dann erscheinen auch ordentliche Meldungen, wie "DLL nicht gefunden", "DLL-Funktionsaufrufe nicht erlaubt" etc. Wenn die GUI "Connection refused" meldet, dann läuft der TCP-Server (DLL) nicht (mehr). Das Skript endet absichtlich nach 60sec, damit es auf jeden Fall irgendwann einmal endet. Ganz wichtig wird auch die Authentifizierung sein, sonst melden sich Fremde per TCP/IP an und handeln mein Depot leer (oder hoch)

 

Ich hoffe, es ist ersichtlich, welches Potenzial in diesem kleinen Beispiel steckt! Dadurch, dass ich vom MT4 beliebiege Daten an eine GUI und zurück senden kann, stehen sehr sehr viele Möglichkeiten offen. Wer mal in das MQL-Script geschaut hat, sieht, dass ich das Kommando "close" einfach per IF abfrage und entsprechend reagiere. Sehr simpel im Grunde. Ich stelle mir das so vor, dass Standardfunktionen buy,sell,close trade, modify, trailing SL etc. in MQL-Code einprogrammiert werden. Dann kann die GUI sofort als One-Click-Trader eingesetzt werden. Über "custom commands" kann jeder EA-Entwickler eigene Kommandos definieren und selbst darauf reagieren.

 

Ich bin jetzt die Woche über wieder mal beruflich in Deutschland unterwegs. Zum Programmieren werde ich nicht kommen, aber hier im Forum werde ich schon vorbei schauen

 

RAiNWORM

Wow, nicht, schlecht, dass ihr auch schon reingeschaut habt! Interesse scheint ja da zu sein.

 

Nur so viel: Ich hab schon den Auftrag für ein e-Commerce System gegeben ^^

 

Ich bin jetzt die Woche über wieder mal beruflich in Deutschland unterwegs. Zum Programmieren werde ich nicht kommen, aber hier im Forum werde ich schon vorbei schauen

 

Es soll sich keiner unter Druck gesetzt fühlen. Das ist kein Commercial, sondern Just for Fun.

Job und Family gehen vor und tom-next ist in nem Monat auch noch da.

Nur so viel: Ich hab schon den Auftrag für ein e-Commerce System gegeben ^^

Sollen wir nicht lieber P.H. abwerben und wir kassieren nur 10% von dem, was er verlangt? Dürfte reichen

Es soll sich keiner unter Druck gesetzt fühlen. Das ist kein Commercial, sondern Just for Fun.

Job und Family gehen vor ...

Klar, verstanden. Ich wollte nur vorsorgen, nicht dass ich einige durch die Ideen heiß gemacht habe und sie nachher enttäuscht sind. Um meine Partnerin werde ich mich selbstverständlich auch noch kümmern

...und tom-next ist in nem Monat auch noch da.

Too big to fail?

Hi,

 

ich hatte mal eine ähnliche Idee, deswegen melde ich mich kurz. Aber MetaTrader ist für mich relativ schnell gestorben. Ich traue der Plattform nicht und den meisten MT-Brokern auch nicht. Deswegen konzentriere ich mich erst mal auf das manuelle Trading und später dann auf das FIX-Protokoll, da der Aufwand doch irgendwie der selbe ist und ich in meiner gewünschten Umgebung bin.

 

Meine Idee war, ein Server-Programm zu schreiben und eine Client-DLL für MetaTrader. Die Client-DLL soll bei aktivieren eine Verbindung zum Server aufbauen und jeden Tick zum Server senden. Der Server ist dann nur das eigentliche Handelssystem. Dieser wertet die Daten aus und erzeugt Entscheidungen die er dann der Client-DLL mitteilt. Somit kauft oder verkauft dann der MetaTrader.... -der Serverdienst läuft am Besten auf einem separaten Rechner im LAN (falls doch ein Hintertürchen in MetaTrader wäre) und akzeptiert nur die Verbindung deines definierten Clients z. B. über dessen Fingerprint...

 

Viel Erfolg!

 

LG johno

 

PS.: -ja, ich traue MetaTrader nicht^^

Meine Idee war, ein Server-Programm zu schreiben und eine Client-DLL für MetaTrader. Die Client-DLL soll bei aktivieren eine Verbindung zum Server aufbauen und jeden Tick zum Server senden.

Mich würde interessieren, warum die MetaTrader-DLL mit dem Server Kontakt aufnehmen soll. Beim MTEC sieht es genau umgekehrt aus, da davon ausgegangen wird, dass der MetaTrader dauerhaft läuft und damit auf die Verbindung wartet. Wenn bei dir der Server ständig läuft, jedoch ohne Anbindung an MetaTrader, dann kann das Handelssystem auf dem Server mangels Tickdaten und Marktzugang nichts machen.

 

(falls doch ein Hintertürchen in MetaTrader wäre)

PS.: -ja, ich traue MetaTrader nicht^^

Achso, du vermutest, dass der MetaTrader dich ausspioniert oder unerwünschten Personen Zugriff auf deinen Rechner gibt? Oder glaubst du, dass der MetaTrader dein dort in MQL programmiertes Handelssystem an den Broker versendet? Wäre in der Tat sicherlich eine lukrative Geschäftsidee ^^

 

Viel Erfolg!

Danke!

...und tom-next ist in nem Monat auch noch da.

Too big to fail?

 

Sorry für OT, aber:

Muhahahahhahahaaaaaaaaa der ist ja mindestens genauso gut wenn man den Hintergrund kennt wie

"Warum liegt hier eigentlich Stroh" und "das ist Darude mit Sandstorm".

Mich würde interessieren, warum die MetaTrader-DLL mit dem Server Kontakt aufnehmen soll. Beim MTEC sieht es genau umgekehrt aus, da davon ausgegangen wird, dass der MetaTrader dauerhaft läuft und damit auf die Verbindung wartet. Wenn bei dir der Server ständig läuft, jedoch ohne Anbindung an MetaTrader, dann kann das Handelssystem auf dem Server mangels Tickdaten und Marktzugang nichts machen.

Richtig, meine Ansicht war, eine Software zu schreiben, die verschiedene Handelssysteme ausführt und managt.

Angenommen, ich hätte bei zwei verschiedenen Brokern ein Live-Konto und lasse bei beiden mein System handeln. Zusätzlich hätte ich noch (zum Vergleich) zwei Demo-Konten bei denen auch das System handelt, dann hätte ich vier separate Instanzen meines Systems. Warum sollte ich bei jeder Meta-Trader-Instanz einen Serverdienst starten? Lieber doch ein zentrales System, bei dem sich jeder MetaTrader anmeldet und auf seine Befehle wartet die er dann ausführt. Aber du hast schon recht, im Prinzip ist es egal, wer Server und Client macht. -nur eine Frage des Designs. Anmerkung: ich arbeite eigentlich nur noch mit virtuellen Maschinen -deswegen wohl auch so mein Gedankengang (mit den verschiedenen Rechnern und LAN etc).

Achso, du vermutest, dass der MetaTrader dich ausspioniert oder unerwünschten Personen Zugriff auf deinen Rechner gibt? Oder glaubst du, dass der MetaTrader dein dort in MQL programmiertes Handelssystem an den Broker versendet? Wäre in der Tat sicherlich eine lukrative Geschäftsidee ^^

Angenommen, ich hätte meinen Tradingstil gefunden und handle diesen (durch ein System) auf Dauer profitabel. Ich würde das System wirklich nicht mit dem MetaTrader ausführen wollen. Siehst ja, wie die Systeme vermarktet werden... Ich hätte keine Lust, dass der Broker die Logik meines Systems einsehen könnte und mich eventuell dann gezielt abstoßt... -selber dann aber Kohle macht oder das System unter anderen Namen teuer verkauft usw.) Ich traue machen leider wirklich alles zu...

 

Ich persönlich bin davon überzeugt, dass es gute Systeme gibt, die aber nicht verkauft werden. Und andersherum: Warum sollte jemand ein wirklich gutes System verkaufen? MT ist für mich eine reine Marketingmaschine. Leider kann ich hierzu nicht mehr sagen, jedenfalls habe ich kein Vertrauen in diese Plattform. Ob es wirklich so krass ist (wie teils von mir vermutet), weiß ich wirklich nicht...

Ich überlegte mir dieses Prinzip um dem Broker es nicht zu ermöglichen mein System einzusehen, -trotz einer von ihm kontrollierten Verbindung mit entsprechenden Rechten und File-Handels.

 

Danke!

Ich erwähnte das nur, weil dein Projekt ziemlich ähnlich ist. Vielleicht wäre das auch was für dich gewesen. Du entwickelst nun eine DLL für MetaTrader und ein eigenständiges Programm dazu. Wie ich es vor hatte... Wie du was genau machst liegt natürlich bei dir. -Und wirklich, ich bin einfach nicht mehr interessiert. Heißt jetzt nicht, dass ich es inzwischen schlecht -oder MT grundsätzlich negativ finde. Jedoch sehe ich für mich bei MT keine ernsthafte Zukunft. Der Post war wirklich nur für dich als eventuelle Anregung.

 

LG johno