Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

[marvin42x]

Marshalled Code, insecure Code:

Das Handgeklöppelte schlanke Kleine passt nicht mehr in unser heutiges Konzept. Ohne Seiten -Airbag ist ja eine Fortbewegung auch nicht mehr denkbar.
Wenn Du dann mit 2 Jahre alten Anachronismen auftauchst musst Du Dich nicht wundern wenn die neue Welt nur rumnörgelt

Netter Gruß

[PicNick]

..Entwickler der Referenzbausteine..

au weia. Naja.
Klingt alles irgendwie nach Arbeit.

Btw: das Konzept beim dot-net VB ist ein ganz grausliches, mit dem jedes neue Megahertz der CPU und jedes Byte der Memory sofort abgefackelt wird.


EDIT Seiten-Airbag vs. handgeklöppelt: Ich werd' hoffentlich heut erfahren, ob mein Firmenrechner im A.. ist oder ob das "VisualStudio Professional" einfach Sch... ist. Es produziert laufend Blue-Screens. Da mein W2k auch schon eine alte Sau ist, wollen wir heute XP Prof. installieren. Mal sehen.

[marvin42x]

Referenzbaustein:
Nein, so war das nicht gemeint.
Ich schicke Dir mal ein Muster.
Es geht nur um die Gestaltung.
Wenn wir die richtig wählen kannst Du Dir sogar einiges an Arbeit sparen.
Es geht nur um so Sachen wie:
Keinen Programmcode in Button Event Subs
Benutzen des Region Features.
Das Hauptfenster heißt Form1.
Nur ein paar Konventionen .
Die aber aus Sicht der Juniorenklassen den Unterschied machen.
Du wirst das an dem Beispiel sehen. Sobald ich Zeit habe mach ich es gleich fertig.

Neuinstallation:
Da kommst Du ja in den Genuss der neuesten Technologie

Vb2005:
Bei mir läuft das erfreulich unauffällig auf mehreren Rechnern.

Netter Gruß

[PicNick]

..erfreulich unauffällig

Ja, mit dem Express-Zeugs hab ich auch keine Probleme. Aber in der Fa. hab' ich ihenen eingeredet, wir brauchen das komplette Visual Studio Super-Douper-Professionell mit Wasserspülung und Bauchtanzen, und das macht einen Blue-Screen nach dem anderen .

[marvin42x]

Vb2005 Prof.:

Jetzt wo Du es sagst fällt mir ein.
Ich hatte mir mal vor geraumer Zeit die Vollversion geliehen um zu sehen wo die unterschiede sind.
Dabei benahm sie sich auch zickiger als die Express.
Ich hatte das nicht weiter beachtet da ich damit sowieso nichts machen wollte.
Und weis der Geier, hätte ja auch an meinem System liegen können.

Ich hatte übrigens damals den Eindruck, dass einem bei der Express Version fürs erste nichts fehlt.

Das sind natürlich keine Angaben von Stiftung Warentest sonder ganz subjektive Einzelerlebnisse.

Netter Gruß

[PicNick]

Hi,
na direkt fehlen nur Feinheiten und verschiedenes Drumherum. Das bißchen, was ich da auf der Prof.Version mache, kann ich 1:1 daheim mit dem Expreß verwenden. Also für uns macht es wohl nix.
Debuggen ist z.B. viel mächtiger und auch im Release-Bereich tut sich mehr. Aber da bin ich auch kein Guru.
Egal, was wir da tun, muß sowieso auf der Express Version lauffähig sein, sonst sterben wir einsam mit dem Zeugs.

[marvin42x]

Das Programmieren schreitet voran.

Ich will mal einen Vorschlag zur Kommunikation machen um das Thema anzuleiern.

Beispiel:
MARV startet einfach so. oder mit Parametern in der Befehlszeile
Nach/Bei dem Start guckt er in seine Konfigdatei.
Dort findet er wie er heißt und was er als nächstes tun soll.
Das wäre beispielsweise:
3 Trackbars starten.
Der Aufruf den er tätigt sieht etwa so aus:
OneTrackbar.exe MOTHERPID=2345,NETNAME=TRACKBAR,ID=1,DESTCLASS=53, DESTCLASSEID=1,PORT=42,IP=127.0.0.1; HOWSTART=AUTO
OneTrackbar.exe MOTHERPID=2345,NETNAME=TRACKBAR,ID=2,DESTCLASS=53, DESTCLASSEID=2,PORT=42,IP=127.0.0.1; HOWSTART=AUTO
Noch mal……

Der Trackbar der nun startet. Hat ja order automatisch zu Verbinden.
Und connectet auf IP 127.0.0.1 Port 42 , Anmeldename Trackbar1 PID 3456 mit dem Server.
Das erste was er tut ist ein IAM absetzen:
IAM=MOTHERPID=2345,MYPID=3456
Damit hat MARV die Rückmeldung das sein Kind online und am Leben ist und welche PID er jetzt hat.
Über Die PID kann er jetzt gezielt adressieren z.B Positionieren oder beenden. Auch kann er jetzt die Klassenzuordnungen neu setzen.

Erstmal Pause und warten auf Reflections.
Das ist ja noch nicht wasserdicht.

NETTER=GRUSS

[PicNick]

*grübelgrübel*
Jetzt kommt ein Querschläger, setz' dich lieber erstmal hin
Die Rollen und Aufgaben von MARV <> Rn_server sind mir etwas verschwommen.
Ich denk', das ist wie beim Highlander: Es kann nur einen geben.

Wär's nicht gescheiter und in der Anwendung/Betrieb einfacher, wir würden RN_Server und Marv zusammenführen ?

Alleine schon, nurmehr einen TREE /Config zu haben, scheint mir was wert. In solchen Redundanzen steckt nämlich oft einiger Kummer drin.

Schockiert ? (kalte Umschläge mit Essig können helfen)

[marvin42x]

Nein, überhaupt nicht.
ist ja nicht so dass ich mich um Schwierigkeiten reiße.
Wenn der MARV als Ideenträger das Konzept weitergebracht hat kann er seine Schuldigkeit getan haben.
Nett von Dir das Du bisschen auf meine Gesundheit achtest
Ich hatte extra den Server etwas außen vorgelassen um Dir nicht noch mehr aufzuhalsen.
Also, Du siehst, allerbeste Teambedingungen.

Das mit dem Tohuwabohu hatte mir auch schon Kopfzerbrechen bereitet.
Das zieht ziemlich viel Verwaltungsaufwand nach sich.

Mach mal Vorschläge wie Du die Lösung siehst.
Damit wir da was festlegen und ich meine Aktivitäten darauf ausrichten kann.

Netter Gruß

[PicNick]

Bei der jetzigen Trennung MARV (Supervisor) und Server (zentraler IP-Knoten) wird die Kommunikationen immer knackiger und umständlich.

Was ich mir vorstell' bzw. überlege ist eigentlich einfach: Die paar Aufrufe, die man als IP Server extra braucht, drücke ich der DLL in die Hand, die Funktionen selbst sind ja eh drin. Und das Verhalten bezüglich Messages lesen (callback) ist identisch. Müßte nichtmal eine eigene Callback-routine sein, es ist in beiden Fällen ja das Gleiche zu tun.
Extra ist nur die Verwaltung mehrere IP-Handles, bei Broadcast etc.

Wir werden noch sehen, was alles diese DLL sozusagen im Hintergund abnudeln kann und wo du Hand anlegen müßtest.

Im Prinzip sagst du statt "connect" nur "define" (IPadr, Port) und in der Callback routine, die aber sonst genauso aussieht, gibt es den Event "New", d.h. ein neues IP-Handle taucht auf. Das mußt du dem mit "shell" gestartetem Prozeß umhängen. d.g. du mußt ihn anhand der PID finden (die er ja zu Beginn mitschickt)
Das hättest du im jetzigen Konzept aber auch müssen.
Und wenn du einem bestimmten Fuzzy was senden willst, mußt du das passene IP-Handle verwenden, statt des einen, zentralen, den du jetzt im Moment hast

allein schon der Vorteil: Wenn einer der GUI e.V. verstirbt, weißt du es aus erster Hand.

Klingt nach etwas Arbeit, ist aber einfach mehr straight-ahead und strukturell viel klarer.

War das positiv formuliert ? (dafür, das du wieder ein paar Sachen umbauen mußt)