Eigenes Chartprogramm mit Visual C schreiben

Schau mal unter tradeproject.de
Da kann man die Strategien in VB programmieren und es hat schon Charting & Routing. Wäre das nicht was ?
... geht ein wenig über "Fingerübung" hinaus ;-)

@ Tobiasl [#2]
Danke, aber ich will keine Soft, mit der ich Strategien programmieren kann. Davon hab ich schon 5.
Ich möchte eine eigene Soft entwickeln, aber die Chartingroutinen nicht neu erfinden, sondern eine Funktionsbibliothek einbinden, um Charts zu erzeugen.

Gruß

@ gautama2 [#3]
"eine Funktionsbibliothek einbinden, um Charts zu erzeugen."

zedgraph?
http://zedgraph.org/wiki/index.php?title=Main_Page
http://zedgraph.sourceforge.net/samples.html

@ gautama2 [#1]

hier gibts eine Library mit Indikatoren
http://www.ta-lib.org

@ AAA [#4]

cool. Das scheint das Passende zu sein.
Vielen Dank erst mal an alle.

Gruß

Aus der Hochenergiephysik gibt's auch einiges, was frei verfügbar ist. Sieht zwar oft nicht ganz so "sexy" aus, wie modernere Pakete, die für's Web gemacht sind. Ist aber dafür getestet wie kaum eine andere Software, wird teilweise seit Jahrzehnten weiterentwickelt, ist performant, skaliert nach oben bzgl Datenmengen, Speicher, Laufzeiten, usw.

http://cernlib.web.cern.ch/cernlib/

Ich selbst schreibe Java und benutze intensiv http://java.freehep.org/ und JAIDA. Aber es gibt sicher auch C#-Adapter oder C#-Implementierungen der AIDA-Interfaces.

Fragen willkommen.

Gruß,
Asamat

gautama, wie weit bist' gekommen?

Herr Ebert, die Programmiersprache heißt C# @[#1]

http://de.wikipedia.org/wiki/C-Sharp

@ AAA [#8]

stecke noch in der Grundlagenforschung, sprich Werkzeugsuche :)

Momentan bin ich gar nicht zuhause, sondern im Hessischen und kümmere mich um den Ausbau von 2 neuen Dachwohnungen. Daher neben Traden und Weihnachtsvorbereitungen kaum Zeit. Wenn das inkl. Vermietung im Februar vorbei ist, muss ich erst mal Urlaub nachholen und so kann das noch ein wenig dauern. Mal sehen ob ich in der Zwischenzeit ein wenig basteln kann und erste Schritte zustande bringe.

C# deshalb, weil ich es damit geschafft habe, eine Anwendung mit Anbindung an IB zu bauen und mit ein paar Knöpfen Orders zu versenden. In C++ blieb mir das versagt, obwohl es auch damit gehen müsste.
Jetzt will ich ein bisschen Charting dazu machen und in das Ganze dann noch eine Handelssystematik pflanzen und traden lassen. Ob das sinnvoll ist weiß ich nicht, eiegtnlich hab ich ja Programme dafür.
Jedenfalls gebe ich meinem inneren Drang dazu nach und meist war das dann, wenn auch Jahre später, für irgendwas gut.

@gautama2,

bevor Du das Rad neu erfindest, schau Dir mal das an:
http://www.rmchart.com/

Eine m.E. sehr hochwertige kostenlose Grafik-Bibliothek. Ich selbst habe sie zwar nicht benutzt, weil meine bescheidenen Anforderungen mit den Bordmitteln meiner Entwicklungsumgebung machbar waren ( http://www.powerbasic.com ).

Aber für Chart-Freaks m.E. einen Blick wert...

ciao,
zentrader

@ zentrader [#10]

Danke. Sieht gut aus, vor allem Freeware. Rad neu erfinden ist nicht meine Absicht. Also eine Funktionsbibliothek ist genau mein Begehr :)

P.S. Ist aber wohl nicht für C#?
for ASP, BCX, PowerBASIC, VBNET_ACTIVEX, VBNET_DLL, VB6_ACTIVEX and VB6_DLL.

@ gautama2 [#9]
"C# deshalb, weil ich es damit geschafft habe, eine Anwendung mit Anbindung an IB zu bauen und mit ein paar Knöpfen Orders zu versenden. In C++ blieb mir das versagt, obwohl es auch damit gehen müsste."

:-)))
Mir blieb leider auch in C# einiges versagt ("Ereignisbehandlungsmethoden u. Eventhandler", so schimpft sich das doch?), da bin ich nicht richtig durchgestiegen! Und in Java ging gar nichts! :-( So bin ich bei VB.NET gelandet u. kann damit Quotes empfangen und Orders senden, aber auf absoluten "Dummie Niveau". Ab und an bastel ich da was u. in meinem "Hinterkopf" entwickelt sich langsam so eine Idee heran, ein persönliches einfaches Ordertool, wohl ähnlich wie bei dir. Aber ich hab zedgraph zB. nicht mit IAB Quotes in C# zum Laufen gebracht! ;) Und in VB.net hab ich ncoh nichts versucht mit Charts.

In diesem Sinne wäre es interssant, wenn du hier deine Codestückchen in C# zu IAB posten würdest, dann entwickelt sich vielleicht ein Austausch mit mehreren Teilnehmern. Ganz locker...

@ zentrader [#10]
PowerBASIC, da kann man dann seine VB.NEt Geschichten portieren, wenn es schneller laufen soll!? ;))

@ AAA [#12]

Ja, wenn ich wieder ein Stück weiter bin poste ich hier.
Mein Einstieg in das Thema waren die Videos vom Daniel Gollner.
Das hab ich sklavisch nachgemacht und es ging problemlos.
Danach dann stückweise für mich selbst angepasst.

http://www.enterlong.com/videos.html

die beiden letzten unten. Am Anfang recht langatmig, aber wenn man das übersteht, dann geht's. Man kann auch mindestens die erste Hälfte des ersten Videos überspringen, wenn man gleich zum Programmiertechnischen will.

Dummie Niveau ist auch meine Ebene, von daher können meine Posts vielleicht recht lustig werden. Mein Sohn lernt in seinem "Informatik Reinschmecksemester" in Garching gerade Java. Vielleicht hab ich da bald Unterstützung.

@gautama2,

die Funktionsbibliothek von RMChart liegt auch als Windows Standard DLL vor. Diese kannst Du natürlich in C# einbinden!

Die von Dir genannte Aufzählung bezieht sich nur auf den Source Code Designer...

@AAA,

also der von C#.NET oder von VB.NET erzeugte "managed" Code sollte sich in der Laufzeit-Performance eigentlich nicht unterscheiden.

PowerBasic ist eine komplette Entwicklungsumgebung, die Standard Windows Exe oder DLLs erstellt, d.h. diese benötigen keine zusätzliche Runtime (wie z.B. VB6, Java oder .NET).

In der Vergangenheit hat man PB oft dafür eingesetzt Performance-Bottlenecks in "alten" VB6-Programmen zu beheben. Natürlich geht dies prinzipiell auch bei VB.NET, in dem man da Code auslagert und eine PB-DLL aufruft. Denke aber nicht, dass dies unbedingt Sinn macht, da ja .NET eine gigantische Funktions- und Klassenbibliothek mitliefert, die eigentlich schnellen Code zulassen sollte...

PowerBasic hat für nicht C/C++-Experten m.E. folgende Vorteile:

1. die Programme sind klein und benötigen keine Runtime
2. die Programme sind schnell (vergleichbar Programmen, die mit C oder C++ erstellt wurden)
3. der Programm-Code ist Basic und somit m.E. leichter wartbar/lesbar (insb. wenn die Programme etwas komplexer werden) als C/C++-Code

ciao,
zentrader

...und nicht zu vergessen, da dieses Forum ja auch die dt. "Heimat" von Metastock ist:

PowerBasic gehört zu den Sprachen, die explizit vom Metastock Developer Kit unterstützt werden u.a. bzgl. der Erstellung von Metastock Plugins, also der Erweiterung der Metastock Grundfunktionalität.

ciao,
zentrader

@ gautama2 [#1]

Um das Rad nicht neu zu erfinden, kannst du auch mal hier schauen:

http://www.modulusfe.com/

Ist eine sehr gute Bibiothek, wo du alles inklusive hast.

Hat das jemand mal asuprobiert?
TWSLink
TWSLink is an universal DLL/COM based Interface to TWS.
It can be used with various Programming Languages like C++, C#, VB.NET, etc.; Script Languages like Perl or Python, etc. and many Applications like Trade Station, AmiBroker, eSignal EFS, Excel, etc.

TWSLink implements most of the InteractiveBrokers API features, fast, reliable and efficient, liberates you from Programming Details, thus makes your Coding Work easier and Code more transparent.
http://www.trade-commander.org/produkte.htm

@ AAA [#17]

die von TradeCommander in Berlin sprechen sogar deutsch... also notfalls einfach dort fragen...

IAB-TWS/API Componenten gibt es doch viele. Wer es "einfach" will, nimmt das Zeug mit COM oder ActiveX. Auf Dauer (versions)sicherer ist sowas als direkte Kommunikation auf Socketebene per TCP/IP. Ein gutes Beispiel für C++/Pascal wäre hier die Komponente von "http://WWW.HHSSOFTWARE.COM".

Bei Chartkomponenten ist es ähnlich. Entweder man nimmt etwas fertiges (egal ob Freeware oder gekauft) und passt seine eigene Datenlogik an die Übergabeschnittstelle des "Charts" an, oder man arbeitet intern mit schnellen optimierten Datenformaten, was dann aber bei jeder Darstellung eigenen Aufwand oder Konvertierung bedeutet.

Manchmal macht es auch Sinn, das Rad neu zu erfinden, einfach weil man dann weiß was wo wie passiert. Dann geht zwar nicht "alles", aber das was geht hat man "selbst" 100% unter Kontrolle.

Ich sehe wenig Sinn, zig Standardbibliotheken und Komponenten so zu sammen zu setzen, das etwas universelles und allgemein benutzerfreundliches wie TradeSignal/TradeStation/MetaStock herauskommen wird. Wer danach sucht nimmt entweder gleich so ein Programm oder schreibt ein "PlugIN", was die Sandardfunktionen um das worum es geht ergänzt.

Wer wie @gautama2 "nur" ein bisschen Visualisierung für ein kleines eigenes Tradingtoll braucht, sollte evantuell das nehmen was in der jeweiligen IDE schon drin ist. Also bei Visual C++/C# eventuell TEECHART(/Pro).
Ist wie auch in den "Borland-Varianten" nicht das schnellste & effektivste, aber reicht bei rein "ergebnisorientierter" Programmierung aus meiner Erfahrung in 75% aller Fälle aus.

Fragen was einfacher / besser lesbar ist (@zentrader [#14]) kann man auch zunächst verdrängen. Im Prinzip geht heute in jeder Sprache fast alles.
Ob Geschwindigkeit und Versions-/Installationsvoraussetzungen wie bei Java/NET eine Rolle spielen, oder ob man einfach nur eine "Abneigung" gegen "Runtime-Umgebungen" hat, ist anfangs ohne Bedeutung.

Wenn man kein Problem damit hat, einzusehen, das es letztendlich meist am persönlichen "Nichtwissen" scheitert (@AAA [#12]), freut man sich auch an Ergebnissen welche selbst erreichbar sind. Ob hier der VB.NET Code gut oder schlecht ist, bzw. warum das in C#/C++ nicht wollte sind doch Detailfragen.

Wer erstmal eine eigene Lösung hat, und feststellt das es "nur" an Optimierung/Speed fehlt, der findet dann auch einfacher jemanden, der nur noch etwas bestehendes "umschreibt".

!Besser eine brauchbare Gesamtfunktion, als viele optimale Einzelteile, die aber real (noch) nichts verwertbares machen...

@ TimeTrade [#18]
"Wer wie @gautama2 "nur" ein bisschen Visualisierung für ein kleines eigenes Tradingtoll braucht,..."

Halt mal!: gautama2 [#1] "Ziel ist langfristig eine kleine Autotrading Applikation für IB unter Windoof mit ein bisschen Charting und Signaldarstellung."

Ein bißchen Autotrading soll also auch dabei sein! ;)

Die TIABSocket component von Ross Hemingway hatte ich sogar vor Jahren schon mal gekauft, nur hat der Ansporn für Programmiern u. Delphi damals dann doch nicht lange gehalten,...

"IAB-TWS/API Componenten gibt es doch viele."
Ja, aber dann doch nicht so viele, die man gerne benutzt und vor allem sind die gar nicht so leicht im Netz zu finden, dann sieht das oft so "hobbymäßig" aus deren Websitegestaltung, als nicht Programmierprofi muß man dann erst mal schauen...

Was gibt es denn für C# / VB.NET?

Und was ist mit solchen Dingern wie "OpenQuant" und "activequant"

OpenQuant
"Video 4 - This video demonstrates how to develop a simple strategy code that monitors and prints out trade and bar data from Interactive Brokers in real time."
Sieht aus wie in "Visual C# 2005" gautama, warum benutzt du nicht openquant? ;)
http://www.smartquant.com/openquant/video/video4/video4.html

@ AAA [#19]

Eventuell hatte ich mich missverständlich ausgedrückt, deshalb "mein" Vorschlag zur Entwicklung einer solchen Applikation unter folgenden Voraussetzungen:

- man "will" ein eigenes Programm, nimmt also etwas Mehraufwand gegen PlugIN's / Modulen für fertige Programme in kauf (und vernachlässigt erstmal Varianten wie Openquant)
- man hat schon ein Stück Software, was sich mit IB verbindet, und nimmt die Sprache einfach als weitere Basis für den Rest, ohne "Wertung" was jetzt besser oder sonst noch "möglich" wäre
- man will etwas sehen, hat aber keine Lust jedes Pixel einzeln selbst zu malen
- man plant als "Ziel" auchmal ein paar eigene Regeln fest zu programmieren, um diese dann wenn's klappt auch automatisch zu handeln
- man "kennt" ein paar Info über z.B. Herr Gollner, soll heissen man hat zumindest eine glaubwürdige Referenz von einem der sowas "geschafft" hat im Hinterkopf...

Wenn dem so ist, dann empfehle ich einfach ein paar grundsätzliche Überlegungen vorab:

- bei so einem Projekt wird dreht sich letztendlich alles um die Art&Weise wie die Daten intern "gehalten" und "verarbeitet" werden
- eingangsseitig bei Programmstart muss alles wieder in den Speicher
- eingangsseitig bei Bedarf oder Live kommt was von z.B. IAB-TWS dazu
- in der Verarbeitung muss man was prüfen
- in der Verarbeitung muss man was berechnen
- in der Verarbeitung eventuell was ergebnisabhängig auslösen
- ausgangsseitig sollte man was speichern
- ausgangsseitig will man was sehen
- ausgangsseitig will man was übergeben/auslösen
- wer keine eigene "Erfahrung" in Datenmodelierung und Datenhaltung hat, nimmt sich das von einer "Schlüsselkomponente" geforderte Übergabeformat (=> Hier wäre das z.B. die eingesetzte Chartkomponente!)
- ein zunächst wirres "Funktionskonzept" lässt sich später bei Bedarf noch schrittweise optimieren, wenn die Datenbasis stimmt und bleiben kann
- ein "unglückliches" Datenkonzept ist später kaum noch ohne großen Basisaufwand zu änderen... (selbst beste Klassenstrukturen sind dann so ab der 3. Kapselung und Umwandlung nicht mehr gut nutzbar)

Wer anfängt was zu entwickeln, braucht "Erfolgserlebnisse". Es bringt als nix, vorab wie eigentlich üblich ein theoretisches Gesamtkonzept entwerfen zu wollen.
Da fehlt meist nicht nur die Motivation, da fehlt anfangs auch die Erfahrung. Ist ja nicht schlimm, ich behaupte im professionellen Bereich wird auch heute bei Einzelprojekten noch ca. 50% sofort live auf Lösung und nicht als vorab "durchgeplantes" Projekt programmiert;)

=> Also ganz einfach mal anfangen. Zunächst nicht zu viele externe Sachen miteinander kombinieren, oder genau hier den meisten Hirnschmalz bei der Datenübergabe investieren. Optimale Lösungen sind selten universell, also lieber erstmal einfach und funktional mit möglichst viel Standardkomponenten der eigenen IDE.

@ AAA:

Was gibt es denn für C# / VB.NET.

IAB bietet seit API9.40/9.41 nun selbst eine sehr gute schnelle asyncrone Schnittstelle. Das aktuelle NET.Sample ist nur noch "NET" bedingt etwas langsamer als der pure SocketClient. Ich würde unter oben genannten Voraussetzungen also die aktuelle IAB Lösung vorschlagen. Ansonsten gibt es 1:1 Portierungen des C++ Socketclients auf C#.

@ TimeTrade [#20]

ich hab die IB API in das C# eingebunden.
Mein Ziel ist ein Autotrading Geschichte, wo ich auch einen kleinen Chart mit den Signalen und den verwendeten Indis zeigen möchte. Mehr solls nicht sein.

Es reichen auch die backfill Daten von IB. Es muss keine große Datenbank gemanaged werden.

Deine oben genannten Voraussetzungen treffen zu. Mir ist auch erst mal eine kleine Lösung mit Erfolg wichtiger. Ich spiele erst mal mit den Möglichkeiten und dann seh ich mal was ich aus meinen Fähigkeiten machen kann und will.

Viele Grüße

Wer erst mal nur ein bißchen experimentieren und den Programmieraufwand gering halten will, wird es sicher nicht gerne hören, aber:

Meines Erachtens sollte das Tradingmodul von allem anderen (z. B. Chartmodul) getrennt werden. Wenn man nämlich beide Komponenten im selben Programm verbaut, kann es passieren, daß das Chartmodul mal hängen bleibt (muß gar kein eigener Programmierfehler sein), und dann wird evtl. auch das Trading blockiert.

Sicherer wäre die Realisierung zweier eigenständiger Programme. Das Trading-Programm schickt dann lediglich ein paar Signaldaten raus und kümmert sich gar nicht weiter drum, ob und wie das Chart-Programm damit umgeht. Die Datenübergabe könnte ganz simpel dadurch erfolgen, daß eine kurze Textdatei in ein bestimmtes Verzeichnis geschrieben wird.

@ Livetour [#22]

mein Laienverstand sagt mir, dass ich so wenig wie möglich verschiedene Progrämmchen haben sollte, die auch noch mit einer recht lahmen Schnittstelle wie Textdateien kommunizieren. Derartige Lösungen gibt es ja zuhauf und das will ich nicht. Muss ja auch nicht mein eigener Programmierfehler sein, dass die Textdatei nicht geschrieben wird. Muss also kein Vorteil sein, im Gegenteil. Je mehr verschiedene Programme beteiligt sind, desto schlechter find ich.
Aber gut, ich bin Laie. Trotzdem hätt ich gern ein einziges Programm, dass aus den Daten ein Signal und einen Chart erzeugt. Außerdem verstehe ich nciht, weshalb das Signalprogramm Signale ans Chartprogramm schicken soll. Die Signale gehen an die TWS, der Chart soll nur für den Nutzer eine Zusatzinfo geben, damit er nachvollziehen kann, mit welchen Werten für Indis etc. das Programm operiert.
Im Grunde ist das Ganze ja eine Blackbox und muss gar nichts tun, außer Signale abzusondern. Der Chart ist nur sowas wie der Ladebalken, der dem Nutzer die Zeit vertreibt und ihm die Idee gibt, dass gerade etwas passiert :)

@ gautama2 [#23]

Je mehr verschiedene Programme beteiligt sind, desto schlechter find ich.

Ja und nein. Da hier eine sehr wichtige Applikation (Orderabwicklung) neben einer unwichtigen (Charting) läuft, darf die wichtige nicht durch die unwichtige gestört werden. Das kann man zwar auch in einem einzigen Programm sicherstellen, zieht dort aber einen viel größeren Programmieraufwand nach sich und erhöht die Komplexität, auch wenn der User das von außen vielleicht nicht sieht.

Einfacher als in ein eigenständiges Programm gekapselt läßt sich der stabile Betrieb der TradingApp hingegen kaum realisieren. Auch wenn das Schreiben einer Textdatei o. ä. nicht klappen sollte, kann das Tradingprogramm trotzdem die Kontrolle behalten und im übrigen funktionstüchtig weiterarbeiten. Mein Fokus liegt hier also auf einem stabilen Betrieb.

Auch die (niedrige) Geschwindigkeit der Textschnittstelle wird kaum eine zusätzliche Sekunde Verzögerung verursachen. Wenn der Chart tatsächlich nur als besserer Ladebalken dienen soll, dürfte das nicht ins Gewicht fallen. Es muß aber auch nicht über eine primitive Textdatei gehen, sondern das war bloß ein Vorschlag, um den Programmieraufwand so gering wie möglich zu halten.

Außerdem verstehe ich nciht, weshalb das Signalprogramm Signale ans Chartprogramm schicken soll.

"Signale" meine ich im Sinne von Events (Triggern), um dem Chartprogramm zu sagen, daß es jetzt was neues anzeigen soll.

@ Livetour [#24]

aha. Okay. Jetzt versteh ich etwas besser.
Na gut, ich denke ich probier mal beide Versionen mit der Zeit und sehe dann, welche besser geht. Jedenfalls hast Du recht, dass Stabilität die höchste Prio hat.

@ TimeTrade [#20]
Danke für den Beitrag.

@ Livetour [#22]
"Meines Erachtens sollte das Tradingmodul von allem anderen (z. B. Chartmodul) getrennt werden. Wenn man nämlich beide Komponenten im selben Programm verbaut, kann es passieren, daß das Chartmodul mal hängen bleibt (muß gar kein eigener Programmierfehler sein), und dann wird evtl. auch das Trading blockiert."

Die gleiche Frage habe ich eigentlich hier # 3 http://www.terminmarktwelt.de/cgi-bin/nforum.pl?ST=20911&CP=0&F=47
angesprochen wenn du ein spezielles "ausschließlich Tradingmodul" kommerziell/OpenSource für IAB kennst, kannst du gerne in diesem Thread einen Hinweis geben, der kann noch ein paar Beiträge gebrauchen. ;)

Ansonsten zum testen u. experimentieren kann man Charting u. Tradingmodul ja zuerst in ein Programm stecken u. dann später zwei draus machen, oder spricht da etwas dagegen?

@ Livetour [#24]

..."Da hier eine sehr wichtige Applikation (Orderabwicklung) neben einer unwichtigen (Charting) läuft"...

- zwischen Orderabwicklung (TWS/API-"Kontrolle") und Charting(Visualisierung) fehlt noch was: die Signalerzeugung !
- wer Signale mit Indikatoren erzeugt, braucht meist "Schnittpunkte" oder andere grafische "Bereichsprüfungen"
- es macht wenig Sinn, im Ordermodul eine getrennte Logig zur Signalberechnung zu haben, wenn diese im Chartmodul als "Abfallprodukt" schon drin ist...
- es macht Orderentscheidungen eventuell visuell inkonsistent, wenn Visualisierung und Orderberechnung nicht vom gleichen Code ist...
- ich würde also alles in "ein" Programm packen und lieber zukünftig dann in Richtung sauberer Modularisierung "optimieren" (letzendlich bis zu austauschbaren nachladbaren Modulen:)

Nach meiner Erfahrung ist die SAUBERE Datenübergabe zw. mehreren Programmen nicht nur anfangs immer ein Problem, welches man sich nicht unnötig aufhalsen sollte. Schon innerhalb eines Programmes ist es eine der wichtigsten "Hauptaufgaben" Daten vernünftig zwischen den Modulen auszutauschen.

Mehrere Programme mit echter Interprozesskommunikation projektiere ich nur, wenn es sich um skalierbare/verteilte Lösungen handeln soll, also die einzelnen Programme auch in Kombination notfalls auf unterschiedlichen Rechnern laufen müssen. Auf Einzelrechnern mache ich lieber "AllInOne" mit mehreren Modulen/Threads.

@ gautama2 [#25]
Programmiere erstmal die Funktion, dann teste die Stabilität. Aufteilung/Modularisierung/... das ergibt sich von selbst und mit zunehmender Erfahrung kannst du dann auch schon vorab sinnvoll entscheiden wie du ein Problem angehst/aufteils.

@ TimeTrade [#27]

Man muß halt entscheiden, wo für einen die Prioritäten liegen:

- Du möchtest Redundanz vermeiden, ich dagegen bin der Meinung, daß Redundanz in Ausnahmesituationen durchaus das geringere Übel ist.

- Du siehst das Problem einer evtl. grafischen Inkonsistenz, für mich dagegen wäre das nur zweitrangig, solange die Signalerzeugung und Orderabwicklung weiterhin fehlerfrei funktionieren.

- Du nimmst lieber den Aufwand einer sauberen Modularisierung in Kauf, ich dagegen sehe einen Nicht-Profi mit dieser Aufgabe überfordert.

- Du hälst die Kommunikation zwischen Threads/Modulen in einem einzelnen Programm für einfacher realisierbar als über zwei Standalone-Programme, meine praktische Erfahrung hingegen spricht entschieden für das Gegenteil (in dieser speziellen Anwendung).

Es gibt hier wahrscheinlich trotzdem kein abgrenzbares Richtig oder Falsch. Für jemanden, der erst mal schnell Ergebnisse sehen möchte, um herauszufinden, wie weit er überhaupt kommt, für den ist es wahrscheinlich auch kein Beinbruch, wenn er anschließend das halbe Projekt nochmal neu schreiben muß, um es vom "quick & dirty"-Status in ein stabiles Konzept zu überführen, egal ob nun multitaskingfähig innerhalb eines einzigen Programms oder aufgeteilt auf zwei.

Chartmodul mit GDI+

Wie sieht es damit aus? Für einfache Realtimecharts müßte das doch reichen?

GDI+ in VB.NET Tutorial for Beginners

http://www.vbdotnetheaven.com/UploadFile/mahesh/GdiPlusBiggeners04272005015358AM/GdiPlusBiggeners.aspx

GDI+ Tutorial for Beginners C#

http://www.c-sharpcorner.com/UploadFile/mahesh/gdi_plus12092005070041AM/gdi_plus.aspx

Gibt es ein simples Tutorial direkt für einen Chart? Bei dem ich zB. "einfach nur" meine Variable "anstöpseln" muß und mit einem Timer werden dann die Werte als einfacher LinienChart geschrieben? Ja, und die Daten, wo werden die hingeschrieben? Z.B. einfach in ein Textfile?

@ AAA [#29]

Zusammen mit deinen Links der Erläuterungen zu den puren Zeichenfunktionen kannst du mit folgendem Link das machen was dir noch gefehlt hat:

- Laden der Daten
- Zeichen aller Elemente deines Datenarrays

http://www.csharphelp.com/archives/archive254.html
http://www.csharphelp.com/archives/files/archive254/BarChart.zip

Ein einfacheres und kürzeres "komplettes" Chartprogramm lässt sich kaum schreiben. Der Quelltext ist durch seine Kürze komplett zu überblicken und sollte eigentlich gut zu verstehen sein.

"Bunt" machen, skalieren, sonstwas berechnen und einfügen ... kann man alles machen, man muss ich nur entscheiden ob man die Weg "zu Fuss", also alles selbst zeichnen weiter machen will.

Mit einer Chartkomponente geht sicher das "malen" und skalieren noch einfacher, und als Übung zum Verständnis kann man die paar Zeilen aus diesem Quelltext ja mal gegen den Aufruf einer beliebigen Chartkomponente ersetzen.