Druckbare Version
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ß
au weia. Naja.Zitat:
..Entwickler der Referenzbausteine..
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.
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ß
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 .Zitat:
..erfreulich unauffällig
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ß
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.
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
*grübelgrübel*
Jetzt kommt ein Querschläger, setz' dich lieber erstmal hin :mrgreen:
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)
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ß
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) :-)
Zitat:
….positiv formuliert, ….paar Sachen umbauen musst.
Ja, das hast Du gut gemacht :-)
Ich hatte schon Helm und Sicherheitsgurte angelegt in der Annahme großer Umbrüche.
Habe alle Hoffnung fahren lassen, und mich dem Schicksal ergeben, mit dem Lied auf den Lippen „Nun fahr denn hin du schöne Welt“
Aber wie ich sehe komme ich noch mal davon.
Das was Du da entwirfst sieht gut aus und ist diskussionslos gekauft.
Die individuelle Kommunikation zwischen PC-Komponenten wäre damit auch in besten Händen.
Das Konzept smarter Clients mit Fernsteuerfähigkeiten in Modularere Bauweise sehe ich da nicht gefährdet.
Die Frage des lokalen Ereignis Manager oder Vereinstifter also das was MARV originär sein sollte müssen wir dann noch betrachten.
Das meint:
Was der Server, der ja naturbedingt sehr gut im Bilde ist lieber mit erledigen sollte.
Ob es sinnvoller ist das der Server die Schäfchen hütet und/oder auch startet und beendet.
Ist klar das ich MARV mag, aber wenn was anderes besser fürs Projekt ist wird das Bessere genommen.
Zehn mal Umschreiben habe ich ja fürs Erste versprochen ;-)
Netter Gruß
Eine Frage steht für mich noch im Raum:
Wieweit tangiert die Sache jetzt die Internetfähigkeit.
Callback und Handles hören sich nicht sehr transportfähig an.
Einmal könnte ich mir ja eine Browserbasierte Sache vorstellen.
Aber zum anderen Die Standard Clients als Verein auf einem Entfernten Rechner hinter einer Firewall.
Die einfach über…. ???????? kommunizieren.
Was mein Ideal wäre.
Oder sehe ich da was falsch?
Netter Gruß
However, konzeptionell soll sich ja eigentlich nichts ändern, ausser, daß aus den zwei Programmen MARV.EXE und RN_SERVER.EXE eines wird.
Denn sonst kommunizieren die sich blöde.
MARV verhält sich wie ein weibliches Wildschwein im Frühjahr: ("S-a-u" hat er zensiert)
Er wirft seine Ferkel hinten raus (SHELL) und wartet, daß die bei den Zitzen (connect Port 42) wieder auftauchen.
(Nicht alles, was hinkt, ist ein Vergleich)
Vielleicht gliedern wir aber die COM Port geschichte dafür aus und machen eine Client-Kategorie "Remote-Adapter" , die dann auch für anderer Remote-Geschichten herhalten kann (HTTP, SOAP, blabla)
Auch das wär dann etwas geradliniger.
Egal, step by step. Ich bau mal wieder an der DLL um und liefere ein Template.
Also, Meerschwein is angesagt.
Da ist ein IP_DLL drinnen, wie gehabt, mit ein paar Kleinigkeiten dazu.
Er kann, je nach Button, Server spielen oder Client, wie vorher.
Pikanterie: er kann auch beides gleichzeitig machen, (natürlich erst define und dann connect, logo)
Darüber hinaus noch naturbelassen, guck einfach mal rein.
Ja, habe schon reingeguckt.
Mein Gehirn hatte aber heute keine rechte Lust.
Darum bin ich mit ihm übereingekommen, dass ich das erst Morgen verstehe.
Weiter haben wir uns geeinigt die Zeit nicht zu vertrödeln, obwohl wir beide sehr müde wahren.
Darum haben wir erstmal was gemacht was relativ einfach ist und Arbeitserleichterung für die Zukunft verspricht.
Ich habe jetzt mal die Ecke an der ich arbeite zusammengestellt.
In den Programmtexten beider Projekte kannst Du sehen wie ich Dein Template einbaue.
Falls es Dir so zusagt würde ich das in diesem Stil fürs erste beibehalten wollen.
Das kann sich ändern wenn wir das möglicherweise in Klassen oder Module packen.
Bis dahin wäre es für mich zum Testen und Verwenden eine enorme Erleichterung.
Also bitte wohlwollend prüfen.
Ich habe die IP_DLL schon so zurechtgemacht das Du sie zum Weiterarbeiten nehmen könntest.
Das ist jetzt eine Option, wenn Du was anderes bereit stellst bau ich das natürlich auch ein.
Netter Gruß
Jetzt noch der Rest.
Alles mit einem mal wollte er nicht.
Netter Gruß
Bin zwar immer noch müde.
Habe aber jetzt mal die Sache ausprobiert.
Das ist ja noch mehr als ich glaubte zu brauchen.
Da bin ich ja hocherfreut über das Spielzeug.
Da muss ich erstmal richtig nachdenken was man damit alles anstellen kann :-)
Hmm…. Denk sinnnier……
Ich werde als nächstes mal sehen, dass ich das irgendwie anwende.
Netter Gruß aus den Research and Destroy Center
Short Doku I:
Beim Portdefinieren zeigt die bei "define" erzeugte "IpDef"-Referenz sozusagen auf das "Mother-Port". Ausser eventuell wieder wegschmeissen ("stop listening") kann man damit eigentlich nicht machen.
Wenn sich nun ein Client an das Port connected, wird "callback" gerufen mit dem Status=2. (Der Client kriegt da grad sein "ok" auf den Connect)
Auch damit kann man in unserem Fall nicht viel machen, da ja noch keine Message empfangen wurde.
Wenn nun der Client die erste Message wegschickt, sollte sie ja zumindest seine PID enthalten, und jetzt sollte (oder kann) der Server erst wirklich aktiv werden.
Aber da ist der Status nichtmehr = 2, sondern wieder normales "ok" (=0)
Rein technisch müßte sich ein Server diese IpRef nicht extra merken, er kriegt ja jedesmal in der Callbackroutine diesen Wert wieder mit.
Er kann auch so darauf normal senden (antworten) oder ggf. "disconnecten"
(Wird fortgesetzt)
Doku II:
Stimmen wir mal die Situation beim Starten der einzelnen Applikationen:
Es gibt eine Startliste mit Prozess/Programm Namen. wobei sie auch mehrfach gestartet werden sollen.
z.B. Eintrag "GUI e.V" Starten = 2 x
Der "SHELL" Befehl gibt ja die PID des erzeugten Prozesses zurück.
d.h. die PID des GUI e.V weiß MARV schon durch das Starten.
Jeder erzeugte GUI e.V Prozess connected sich nun mindestens einmal, möglicherweise aber auch mehrfach an das von MARV definierte Port (42)
Bei Marv taucht nun eine neue IpRef auf, die MARV ja dem richtigen Prozess zuordnen muß
Daher muß in der ersten Message von GUI e.V die PID enthalten sein. Die kann er nun bei den durch "SHELL" erzeugten Einträgen suchen und die IpRef dazu hängen.
Bei jeder weiteren Message des GUI e.V wird MARV nun die IpRef suchen (und finden), d.h. er weiß sofort, von wem die Message kommt.
Dabei sollte eine Struktur entstehen, wie im Bild angedeutet.
Sind wir soweit d'accord ?
Doku:
Ja soweit alles klar.
Ich habe noch nicht so viele mit Zeigern gearbeitet. Aber kein Problem.
Zitat:
und die IpRef dazu hängen…
das wäre jetzt ein Integer die ich im Nachrichtenstring mitschicke?
Allgemeines:
Wir wollten ja auch mal sehen ob davon nicht einige Richtung RN-Server wandert. Weil der ja besser im Bilde ist.
Und MARV eine eher Inhaltliche Rolle übernimmt die mehr mit Projekt spezifischen Fragen zu tun hat als mit Administrativen.
Und was Unterhaltsames zum Wochenende:
Rückblick von mir auf damals schwierige Zeiten:
Frr ms d Pro se krz Vrn ver dm s af d dls kl Mnt d Pgzil vllstg a d Bls sn knt.
Ht sn d Bls z Gl gr gwd
Frühr mstn die Proger ser kurz Varinamn verwndn dam sie auf dn dmls kln Monit die Progzeile vollstg auf dem Bildsch sen knten.
Hte sin die Bildsch zm Glck größer gewrden
Früher mussten die Programmierer sehr kurze Variablennamen verwenden damit sie auf den damals kleinen Monitoren die Programmzeile vollständig auf dem Bildschirm sehen konnten.
Heute sind die Bildschirme zum Glück größer geworden.
80 Zeichen pro Zeile war einmal das Limit.
Hut ab vor den alten Herren.
N G
Ntr Grs
Netter Gruß
Naja, eine Lochkarte hatte eben nur 80 Spalten. Und davon waren ein paar reserviert. Ursprünglich gab's zum programmieren überhaupt keine Monitore, sondern z.B. Lochkartenstanzer IBM 29 *hehe* und Formularpapier mit den Spalten. Kleinere Änderungen und Jobs hat man selber gestanzt, sonst gab man das in die "Datenerfassung", wo ein paar schicke Mädels gesessen sind.
Verknautschte Lochkarten wieder geradebügeln kennt ja heute keiner mehr.
*räusper*
Was das "reinhängen" betrifft, kommt's natürlich drauf an, was MARV eigentlich tun soll und worauf er aufpassen muß.
Wenn er nur ein paar Prozesse starten muß und sich dann einen schönen Tag macht, isses natürlich einfacher.
Wenn er seine Schäfchen hüten muß und schauen, daß sie nicht an den Klee gehen, muß er aber natürlich sozusagen für jeden Prozess ein "dossier" anlegen und die ganzen n:n Zusammenhänge verwalten.
Wie ich weiß, geht das aber mit dem Config-TreeView recht komfortabel.
Also schlaf' dich mal ordentlich aus, du wirkst ja im moment etwas ausgepowert, das kriegen wir schon hin.
(Hab ich das schon gesagt ? Wenn's hint' weh tut, soll man vorn' aufhören)
Ausschlafen:
ja an die Möglichkeit hatte ich auch schon vage gedacht :-)
Vielleicht sollte ich mal guten Rat befolgen.
Also dann bis etwas später
Netter Gruß
Kaum schreibt man was hin, fallen einem auch schon selbst die Gegenargumente ein.
Daß sich ein GUI eV mehrfach connected, ist technisch ja o.k., aber praktisch sinnlos und verwirrend, vor allem bringt's ja nix.
Dennbei einem eventuellen Routing muß ja das Verhältnis CLS/IDENT<>IpRef eindeutig sein.
CLS/Ident andererseits kommen ja aus der Config, also müßte ja da schon drin stehen, daß mehrere Connections gemacht werden sollen.
Also aus administrativer Sicht (starten, config, etc) ist nur eine Connection sinnvoll, welcher connection sollte er denn ein Commando "MAXIMIZE" senden ?
Was anderes ist es, wenn eine Gui eV daherkommt, die NICHT von MARV gestartet wurde. Remote von woanders, z.B.
Das muß akzeptabel sein. Für diese GUI hat MARV dann wahrscheinlich keine Parameter oder Commands auf Lager, aber wenn sich einer mit PID und CLS/IDN korrekt anmeldet, kann er auch mitspielen.
(Muß man aber was machen, damit man PID von fremden rechnern nicht mit den lokalen durcheinanderhaut)
Btw: Ich hab ein bißchen im MARV gestöbert. Für jeden gestarteten Prozeß speicherst du in einem Array die PID.
Als Quickie brauchst du eigentlich nur eine zweite, gleich große Integer-Tabelle, wo du am gleichen Index wie bei den Pids die IpRef reinschreibst.
Mit dem gleichen Suchvorgang kannst du also nach PID oder IpRef suchen, kommst auf den gleichen Tabellen-Index und weißt, was zusammengehört.
So, habe mir nach der Arbeit einen 10 Minuten Schlaf gegönnt, so was soll gesund sein, habe ich gehört.
Aber warum bringen die im Fernsehen schon die 0:00 Uhr Nachrichten?
Na egal, das kläre ich später.
Jetzt erstmal GUI EV’s
Erster Beitrag: Aufgabenverteilung
Also ich beginne jetzt erstmal etwas Philosophisch:
Das RN -Netz ermöglicht das Soziale Zusammenleben von vielen Einzelkomponenten.
Das RN –Netz misch sich nicht in die Gründe ein warum und wie sich Gruppen zusammenschließen.
Dieser Part des RN –Netzes erfordert Stabilität und Leistungsfähigkeit. Und ist vom User nicht zu beeinflussen.
Denkbare Auflistung:--BEGIN--------------------------------------------------------------------
RN- Netz:
Dazu gehört vermutlich Das ganze Level 0 und alles was man wohl unter Serveraufgaben rechnet.
Komponenten dieses Parts sind:
1 Der RN -Server
2 Die RN -Sende und -Empfangsroutinen in den Netzteilnehmern.
3 Die RN- „Befehls-Erkennungs „ Routinen (was dem Befehl zufolge gemacht wird aber nicht mehr)
Der Server hat natürlich, da er sich auf dem Bildschirm tummelt, auch eine soziale Komponente. Er muss also auf Geheiß seine Position und Größe ändern oder auch unsichtbar werden können.
RN –Netz Teilnehmer:
Das sind PC Programme mit spezialisierten Aufgaben.
Komponenten dieses Parts sind:
Trackbar
Levelmeter
Radar
3D Visualisiere
Datenbank
Simulant usw….
RN -GUI –Builder
Das ist ein PC –Programm welches Komponenten startet und ihr Überleben überwacht.
Komponenten dieses Parts sind:
N.N.
Eventuell RN-Server
In Vertretung: MARV
RN –Netz Assistenten
Da geht es um das „Warum und Wie“ RN –Netzfähige Netzkomponenten starten und zusammenarbeiten.
Komponenten dieses Parts sind:
N.N.
In Vertretung: MARV’s
Und andere Userapplicationen
Denkbare Auflistung:--ENDE--------------------------------------------------------------------
Aufgaben des RN –Netzassistenten.
Ich stell mir das mal versuchsweise vor:
Benutzerwünsche entgegenzunehmen
Das Artikulieren der Wünsche zu erleichtern
Dafür sorgen, dass ein vom Benutzer gewünschtes Szenario(EV) erzeugt wird und es betreuen.
Assistenten haben üblicherweise keine großen Kompetenzen in Fachgebieten.
Zentrale Fragen verwaltet der RN-Server
Der hat die Liste der Listen.
Wenn ich mir das so ansehe denke ich mangels besserer Ideen bei mir, wir machen den Builder und den Assistenten erstmal funktionell im MARV weiter und sehen was dabei rauskommt.
Das ist zwar erstmal sehr Programmier -sprach –Spezifisch aber das Logikmodell ist ja nachher universell.
Netter Gruß
Zweiter Beitrag:
Technische Ausführung der Builder und Assistent Funktionalität:
Mich graust schon vor Tabellen und Abfragen und Ref’s
Aber egal.
Das sieht aus als hätten wir so eine Art Level 1 Server zu bauen.
Die Adressierung:
Es erscheit zwingend, dass ein MARV immer nur einen Verein gründet.
3 Vereine dann = 3 MARV’s und daher auch drei Mother PID
Jede von einem RN Netz –Assistenten(in diesen Falle MARV) gestartete PC –Komponente bekommt über die Kommandozeile die Mother PID mit auf den Weg.
MARV bekommt beim Star auch schon die PID von seinem Schützling (Child PID) mit
Jetzt besitzt Ein Vereinsmitglied bereits eine Identität die durch Mother und Child PID definiert ist.
Darüber haben Mother und Child Kenntnis.
Es Connected nie ein EV. Der EV ist im Prinzip nur eine Liste. Zur Zeit geführt von der Mother(MARV)
Es Connecten immer nur Vereinsmitglieder.
Die haben auch nie identische Netnamen da der Netname von MARV erzeugt wird und eine Nummerierung besitzt.
Wenn jetzt Ein Vereinsmitglied beim Server Connected hätte er schon eine Menge an Individualität zu bieten.
Mother PID (Was jetzt die Vereinsidentität repräsentiert da jeder MARV nur einen Verein gründet)
Child PID
Dazu käme noch sein Netname, der ja auch beim Start zugewiesen wird z.B. Trackbar2.
Jetzt bekommt das Child vom Server bei der Anmeldung eine IpRev zugewiesen.
MARV weis davon noch nix???
MARV selber hat sich ja bereits mit seinem Netname als erster beim Server angemeldet und hat seine eigene IpRev zugewiesen bekommen.
Man könnte jetzt Den Netname von MARV so wählen, dass es ein Vereinsname ist.
Jeder MARV meldet sich also mit einem anderen Netnamen an.
Jetzt müsste das Kind erstmal mit Mutti reden können und seine neu erworbene IpRev bekannt geben.
Ab jetzt wäre eine eindeutige Adressierung über IpRev möglich.
Soweit meine unbestätigte Meinung.
Eine andere sehr interessante Sache:
Da Du ja in Deiner IP Wundekiste noch eine Serverfunktionalität versteckt hast schwebt mir die Möglichkeit vor eine Kommunikation außerhalb des RN –Servers zwischen Komponenten zu ermöglichen. Die machen sich einfach einen anderen Port auf und können reden ohne die Anderen zu stören. Wozu auch immer.
Jetzt erstmal genug
Netter Gruß
OT: Dein Lebensrhythmus macht mir Sorgen tzzz, tzzz
Wenns kompliziert wird, hilft Teilen.
Eigentlich gehts um zwei recht unabhängige Dinge:
Die Message-routerei PC<>PC<>µC und hin und her. (RnCom)
Und dann die Konfigurationsgeschichte (MARV, Kinder, eV, etc.etc.) die dafür sorgt, daß Applikationen da sind, wo es was zu routen gibt.
Wir sind ja im Moment tief drinnen im Letzteren und darauf können wir uns ruhig erstmal konzentrieren.
Der Gedanke, die MARV<>Kinder Kommunikation völlig außerhalb der "RnCom"-Geschichte abzuhandeln, hat was, denn das spielt sich praktisch immer point-to-point ab, Sender-Empfänger sind immer eindeutig. Der komplette Adress-header einer Message (und auch das CMD-Byte) kann da geschmissen werden, da steht für diese Verwendung nix interessantes drin.
Teilen ist gut.
Aufgabe und Namen:
Bei meiner letzten Auflistung ist auch der Begriff RN –Netzassistent aufgetaucht.
Der Netzassistent wird ja z.Z. von MARV dargestellt.
Wobei da inzwischen fast mehr Nick als Marv drin ist ;-)
Aber das ist gut so.
Ich denke wir sollten wie beim RN-Server, der ja seinen Job im Namen führt auch „RN-Netzassistenten“ , „Rn-NA“ oder eine ähnliche Bezeichnung einführen. Das hilft um schon von Außen zu sehen das dieses eine erweiternde Funktion des RnCom ist.
Solange mir noch nicht klar war was ich so als Programm verzapfe wollte ich da noch kein RN vorne anstellen. Aber inzwischen kristallisiert sich ja eine gewisse Brauchbarkeit heraus.
Was hältst Du davon wenn wir die „offizielle Version“ des RN-Netzassistenten „Rn-NA“ oder was Ähnliches nennen? Vorschläge gerne gesehen.
Programmier Option:
Ich würde den Code von MARV auch nicht gern als exklusiv Marin42x sehen wollen.
Mir wäre es aus praktischen Erwägungen heraus lieber, wenn der Code ein Vorschlag ist, in dem von beiden Seiten gebaut werden kann, was ja indirekt bereits geschieht.
Es ist eh Open Source.
Ich habe in der neuesten Variante bereits angefangen Versionsdatum und Autor für die Komponenten und später für die Sub’s einzuführen. Damit blieben wir vor Verwirrungen bewahrt.
Das ist ein Vorschlag. Ich bin in Professioneller Programmentwicklung nicht bewandert. Es kann also sein, das man so was ganz anders macht. Auch hier Vorschläge gern gesehen.
Das wir uns auf die EV Geschichte konzentrieren bin ich ganz auf Linie.
Zitat:
MARV<>Kinder Kommunikation völlig außerhalb der "RnCom"
Völlig hab ich nicht gesagt :-)
Der allgemeine Datenverkehr Sensor --> Anzeige bleibt ja unbenommen.
Die Befehlsübermittlung was Position kill und was weis ich angeht würde ich auch lieber im RnCom lassen um zukünftigen Ideen nicht im Weg zu stehen was die Remote Seite angeht.
Da käme ja sonst keiner mehr ran.
Wenn jetzt aber zwei PC-Applikationen unbedingt Mapps austauschen wollen könnten sie das tun ohne die Anderen zu behelligen. Das gleiche würde für Bildbearbeitungen und Erkennungsdatenbanken gelten.
Es würde nicht übers RnCom laufen wäre aber Bestandteil des Generic RN-Client.
Da würde mir erstmal eine rudimentäre Ausprägung für den Tag X reichen.
Irgendwie rede ich in letzter Zeit ein bisschen viel
Netter Gruß
Ps. Jetzt bin ich aber wieder im normalen Nachmittagsprogramm :-)
Jetzt hat mich diese Schweinebacke unter dem A.. ausgeloggt und will, daß ich alles nochmal schreibe *grmpf*schnorch*
Kurzform:
Vorschläge:
RnComManager /RnComWizard /RnComAssistant
(ausses Roboternetz noch ein "Netz" im Namen is zuviel :-)
Eigene Schiene: Is im Grund ja jetzt mal völlig egal, über welches Port "Marv" mit seinen Ablegern quatscht. (Du kannst mit der DLL auch noch x andere Ports definieren) Und wenn dann mal irgendeine Applikationen mit einer anderen auf einem eigenen Kanal tuscheln will, soll's uns im Moment auch wurst sein.
Open-Source-Profi-development: Solange wir das Fundament noch hin und herschieben, kann der Klempner im 1.Stock keine Badewanne aufstellen, da hilft ihm nix.
Schneeball-Phase, halt.
Jetzt setz' ich mal ab, sonst schmeißt er mich wieder
Ich mein das ist ne Sauerei, dass ich jetzt lachen musste.
Wenn einem das ganze Geschriebene flöten geht ärgert man sich schon die Platze.
Ich hab auch gleich wieder aufgehört mit Lachen, ja.
Bei mir ist das ja anders. Da meine Rechtschreibung schlecht ist muss ich das Ganze immer erst in Word verzapfen bevor ich es einstellen kann. Da kann mich nur noch ein PC-Absturz bremsen, wie letztens auch frei nach Murphy passiert ist.
Aber das war’s eigentlich nicht was ich sagen wollte.
Ich wollte mal fragen ob Du es drauf hättest mir zum Spielen eine Sonder Edition des RN-Servers zu bauen die automatisch beim Start auf 127.0.0.1 Port 42 Open macht?
Ich schraube gerade an dem ganzen Getümmel und das würde mir sehr zu Passe kommen.
Das ist aber nicht vorrangig.
Ich Quäle mich sonst auch so weiter durch.
Netter Gruß
Special Edition: sollte kein Problem sein.Zitat:
Zitat von Verstorbener Programmierer
Du kriegst heut eh' noch ein paar Schmankerl vor die Füsse :mrgreen:
Zitat:
Zitat von Rebbe Grün im Telegramm
oh oh,
Bei den Rohrlegern hieß das:
Kinder betet
Vater lötet
Netter Gruß aus dem unterirdischen Schutzraum
So. Ich hab die Doku ein wenig auf den letzten Stand gebracht.
Passende DLL dazu is auch dabei.
(bei den "RnRegist" ist aber noch alles beim Alten)
Neu: Manipulationen mit "Key-Value" unabhängig von RnCom oder sonstwas. (schreiben und lesen)
Also ggf. auch für Commandline bzw. shell-commands
Hab ich noch nicht, aber ich denke, wir werden in den Routinen den Text für "KEY" standardgenmäß links ausrichten, trimmen und uppercase.
"Value" nur ausrichten und trimmen.
Gerade mit ggf. anderen Plattformen ist das einfach sicherer
Bei den "Config" Paramtern und Knoten mach ich es ja auch, das hat sich bewährt.
Da können wir uns ja richtig einig sein.
Manipulation mit Key-Value:
Unabhängigkeit ob Commandline, TCP/IP Message, oder aus der Config Datei,
alles ein Format und eine Routine. Genau.
Formatierung:
Value Case sensitiv lassen ist mir sympathisch. Auch der Rest der Festlegung findet volle Zustimmung.
Eine sehr runde Sache und eine sehr gut lesbare Dokumentation dazu.
.
Verständnissproblem:
Bei einer Sache habe ich noch einen Riss im Hirn.
Wenn ich schreibe FORMPOSX=100,FORMPOSY=200
Ist das Klar.
Das ist bei mir jeweils eine Routine.
Wenn ich eine Routine habe, die zwei Parameter braucht
Ausgedachtes Beispiel:
FORMPOS
Die will x und y übergeben haben.
Wie würde da die Zeile aussehen?
Netter Gruß
Es gibt mehrere Möglichkeiten: Eine davon
Mehrere Values:
FORMPOS=264=128,...
Sowas schreiben:
Sowas LesenCode:RnCsvWrSep(csvref, "FORMPOS")
RnCsvWrVal(csvref, "264")
RnCsvWrVal(csvref, "128")
Da mach ich es aber immer so, daß die Routine ihre Values selber liest oder schreibt, d.h. ich drück' ihn einfach den CSVREF Handle in die HandCode:RnCsvRdSep(csvref, Key)
if Key = "FORMPOS" then
RnCsvRdVal(csvref, X_VAL) ("264")
RnCsvRdVal(csvref, Y_VAL) ("128")
Da kann sich die Routine selber drum kümmern, da sie ja am besten weiss, was sie braucht.Code:RnCsvRdSep(csvref, Key)
if Key = "FORMPOS" then
sub_routine (CsvRef as Integer)
Elseif Key = "SAUBACKE" then
sub2_routine (CsvRef as Integer)
public sub_routine (CsvRef as Integer)
RnCsvRdVal(csvref, X_VAL) ("264")
RnCsvRdVal(csvref, Y_VAL) ("128")
public sub2_routine (CsvRef as Integer)
RnCsvRdVal(csvref, SAU_VAL) ("???")
Da das "RdVal" niemals über das konkrete Element hinauskommt, kann da nix passieren, Also wenn nur ein Value da ist, kann die Sub auch zwanzigmal RdVal sagen, ohne was durcheinander zu bringen.
Andere Variante, auch gern genommen:
In einem solchen String stehen nur Keys und werte für EINE Funktion
Die Funktion als Key ohne value vorne.
"FORMPOS,X=100,Y=20,TOPX=233,TOPY=200"
Dann würde die Hauptroutine nur einen RdKey machen und dann die Funktionen mit dem CsvRef aufrufen, dann soll die selber lesen, was sie braucht.
Dritte Variante, etwas aufwendiger:
Irgendein Value ist selbst ein Key-Value string (Das geht beliebig rekursiv). Das erklär' ich noch, wie das geht
Vielleicht nachgeschossen, falls das nicht gut erklärt wurde:
RnCsvRdKey liest IMMER den NÄCHSTEN KEY, das RnCsvRdVal dazwischen KANN man machen, MUSS aber nicht
z.B. String
"PAR1=ellenlangerschrott,PAR2=wichtig
RnCsvRdKey(ref, KEY) liefert "PAR1"
wenn ich will, kann ich jetzt RnCsvRdVal() machen und krieg "ellenlangerschrott"
So oder so, der nächste
RnCsvRdKey(ref, KEY) liefert "PAR2"
Wie ich das im Moment sehe schließe ich mich deiner Gewohnheit an und drück der Routine den CSVREF Handle in die Hand.
Das bedeutet zwar, dass ich alle Routinen umschreibe aber der Vorteil überwiegt hier.
Ich denke das hast Du gut beschrieben.
Ich werde das mal umsetzen.
Netter Gruß
CSVREF Handle in die Hand drücken:
Bin doch noch etwas unschlüssig geworden.
Da ich die Routinen auch aus der Programmlogik heraus ansprechen will kann es sein, das ich da noch variiere.
Aber Wege hat es ja genug.
Vorschau:
Wenn ich das Key=Value implementiert habe kommt noch ein Net Befehl dazu:
SNAPSHOT
Alle Child -PID in der Liste des Wizards bekommen diesen Befehl und machen einen Snapshot ihrer Parameter.
Länge, Breit, Position, Port, IP, Werterange usw.
Diesen Config Tree senden sie an den Mother –PID (den Wizard)
Der Wizard baut daraus einen Gesamt Tree und speichert den unter einem gewünschten Namen ab.
Das ist dann die Config mit der der Wizard die gespeicherte Session wieder herstellen kann.
Gott steh mir bei.
(PicNick würde da aber auch erstmal reichen)
Netter Gruß
Ps. damit wäre das Thema Config aber auch schon am gewünschten Ende.
(Glaube ich jedenfalls) :-)
Pars ComandLine läuft.
Und wird erkannt und ausgeführt.
Ganz prima.
Was ich noch machen muss damit er das richtige bekommt siehst Du unten:
Aber das weist Du ja.
CsvLen = RnCsvRdKey(CsvRef, Key) ' ergibt “PARAMx”
While CsvLen <> 0
CsvLen = RnCsvRdVal(CsvRef, Val) ' ergibt “Valuex”
'-----------------------------
' auswerten Key=Val
MyKey = Trim(Key) 'Leerzeichen eliminieren
MyVal = Trim(Val) 'Leerzeichen eliminieren
lenk = MyKey.Length 'Länge holen
lenv = MyVal.Length 'Länge holen
MyKey = MyKey.Remove((lenk - 1), 1) 'Bissel Tricky, da muss noch ein verstecktes Zeichen am Ende gekillt werden.
MyVal = MyVal.Remove((lenv - 1), 1) 'Bis ich da drauf gekommen bin......
DoCommand(MyKey, MyVal)
'-----------------------------
CsvLen = RnCsvRdKey(CsvRef, Key) 'Next
End While
Ans Schreiben von Key=Values mach ich mich morgen.
Netter Gruß
Aus den Search and Zerstreu Labs. In good old Berlin
Edit:
Nachtrag:
Die frischeste Version findest Du unter dem Link den ich Dir geschickt habe.
Und sag jetzt nicht Du hast den verbummelt.
Netter Gruß
Tagchen !
Ok, um das trimmen etc. kümmere ich mich, schau nur erstmal, ob du bis dahin irgendwie überlebst.
Pfooaaa ! Der VB ist nix für Rekonvaleszente, Frischoperierte, manisch Depressive und Gemütskranke !
Wenn du sagst Text.Length , gibt er dir die Länge von "new", egal, was da drin steht.
Leider muß man auf jeden Fall folgendes einfügen, damit das ein sauberer String wird:
Ich faß' es nicht.Code:CsvLen = RnCsvRdKey(CsvRef, Key)
While CsvLen <> 0
Key = Key.Remove(CsvLen, Key.Length - CsvLen) NEWNEWNEW
CsvLen = RnCsvRdVal(CsvRef, Val)
Val = Val.Remove(CsvLen, Val.Length - CsvLen) NEWNEWNEW
....
(Geht auch, wenn csvlen = 0, also keine Sorge)
Anbei die DLL mit trimmen und ausrichten, wie besprochen