Das mit der config File war urspünglich nicht so bös' gemeint. Ich hab halt der Einfachheit halber für den RN-SERVER das verwendet, was ich sozusagen in der Lade hatte (Ich brauch' sonst immer Plattform-neutrale Sachen). Der Witz daran ist der, das sie nach dem Laden real im Speicher als hierarchischer Tree zur Verfügung steht, man muß nicht immer jeden Sch... in irgendein feld schreiben, um es sich zu merken, und den ganzen Tree zu lesen oder auf File zu flushen, geht auch elektrisch. Arbeitet sehr ähnlich der Registry in Windows
Dann ist eben der Gedanke der zentralen Config aufgetaucht, und da kann so ein Tree schon hilfreich sein, wenn man ihn mit der gleichen Struktur aufbaut wie eben die ganze Applikation.
Ich werd' die Doku + Demo zum Download herrichten.
Das ist eine DLL, die direkt von allen DLL-Fähigen Programmen verwendet werden kann. Die Funktionen im Wesentlichen
Create (empty) Tree
Drop Tree
Build (file-name-string) Einlesen ganzer Tree
Flush (file-name-string) Rewrite ganze Tree
Create/Delete/Find Directory "Knoten"
Create/Delete/Find Parameter "Key"
Create/Delete/Find Value "Value"
Primär ist alles auf string-basis, weil das überall geht.
Ich möcht noch die IP-Geschichte verpacken, das haben wir ja schon abgedeutet. Von den Funktionen her eigentlich wie die normale Socket-Geschichte, nur das Message-Zerlegen und Aufbauen ist integriert.
Eventuell auch die Layer0-ComPort Sache, die könnten ja vielleicht auch endere brauchen.
Und diverses Bit und Byte-gefummel, das immer wieder nervt.
Die meisten Sachen gibt's ja schon, es geht nur darum, wie man das vernünftig mit einer DLL exportieren kann.
Ja, der neue will kein "RN" mehr (is aber noch in Arbeit, mit der "fast-connect" Geschichte)
Doku hab' ich begonnen :
https://www.roboternetz.de/wissen/in...C_PC-Programme
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Gerade Marvins Marvellous MARV getestet.
Überleg' grad, ob EINE zentrale ini/cfg überaupt zweckmäßig ist
Also:
MARV weiss, was wie oft zu starten ist + einige setup parameter
Aber die einzelnen Komponenten könnten durchaus auch ein Eigenleben führen.
*murmel, grübel*
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Sorry, bin auch schon wider runter vom Baum. War ein harter Tag.
Und Du weist, ich habe es schon viermal neu geschrieben und ich schreibe es wenn es sein muss auch zehn mal neu.
Das mit der einheitlichen Cofig-Geschichte und dem Tree ist Genial.
Das ist viel besser als das was ich habe.
Das eignet sich fast als Geburtstagsgeschenk
Das Du unter Anderem bei der Bit und Byte-Fummelei noch hilfst entspannt mich ungemein.
Es ist ein ziemlicher Graus, wenn man sich das alles zusammensuchen muss.
Ich mach jetzt erstmal mit meinem Zeug so weiter und werde nach und nach mit den Sachen mitziehen.
Was schön ist, dass ich einige Probleme die noch ausstehen erstmal parken kann und da nicht so viel Zeit verwenden muss.
Bin schon wieder ganz oben auf
Freu mich.
Netter Gruß
Ps. Sehe gerade es ist angekommen.
Fein
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
Bei der Ini –Sache bin ich ganz offen, der beste Vorschlag gewinnt
Netter Gruß
Erläuterung des bisherigen Konzepts:
Jede Einzelkomponente trägt sich höchstpersönlich in das Config File mit einer eigenen Rubik ein, wenn man sie positioniert und eingestellt hat und den save Config Button drückt.
Jede Komponente hat seinen eigenen Save Button.
Die Komponente könnte auch als Einzelkämpfer auftreten.
Dann ist halt das Ini File kleiner.
In Arbeit ist zurzeit der Wechsel zwischen verschiedenen Konfigurationen.
Sprich Config Files dadurch entstehen dann unterschiedliche EV.’s.
Die Info welches Config nun das angesagte ist soll als Pfadangabe über ein Start-Argument in der Komandozeile an die startenden Einzelkomponenten mitgegeben werden. Dort wird ja bereits eine laufende Nummer mitgegeben die zum Bestandteil des Namens wird, also der ID „Trackbar 1“ z.B.
Weiter ist angedacht dort auch IP und Port und eventuell Komponentennamen zu übergeben.
Das managt MARV.
MARV weis ja was es tut,(hoffentlich) .
Weiter Merkt sich MARV die TaskID und kann beim drücken vom Aus Button alle gestarteten Tasks anhand der TaskID wieder abräumen.
Später sicher auch in einer Auswahl gezielt einzelne.
Jetzt der Schwenk zur Kür:
Geplant ist eine Remote -Funktion der Komponenten wenn sie erstmal online sind.
Das geschieht über IP Messages mit Befehlen. Damit kann man sie im laufenden Betrieb verschieben, vergrößern, verkleinern, Wertebereiche umstellen. Na das Ding wird damit lebhaft wie ein Floh, wenn man will.
Das kann man natürlich auch benutzen um die Komponenten erst nach dem Start anzuordnen. Oder umzuordnen falls sich Gegebenheiten verändern.
Auch kann man darüber die Komponente beenden.
Puhh….
Erstmal genug.
Man kann sehen, dass das RN-Com eine weit offene Architektur hat. Da bleibt kein Auge trocken und keine Seele ungetröstet.
Netter Gruß
So jetzt noch der Rest:
Es ist dem geneigten Leser natürlich schon klar, dass mit der TCP Remote –Funktion auch ein Roboter seine eigene GUI starten und konfigurieren kann. Der Befehlsumfang und die Parameter sind ja nicht sehr aufwendig.
Wenn ein RN-Server und ein MARV online sind, ist fast nicht unmöglich.
Netter Gruß
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
Apropos Typisches Userverhalten:
Ich hätte da einen Wunsch:
Wenn ich mich jetzt mal auf mein Konzept beziehe.
Würde es reinpassen wenn der Server die TCP -Befehle:
Form.Hide
Form.Show
Form.Minimize
Form Resize
Können würde.
Aus dieser Anforderung raus stellt sich dann die Frage eines einheitlichen TCP-Befehlssatzes oder Formates.
Da diese Befehle ja für alle Komponenten funktionieren sollen.
Mein Vorschlag:
Es wäre lieb, wenn Du die Definition dafür vorschlägst und wir die dann festlegen.
Die Notwendigkeit, dass der Server oben genannte Befehle kann ist nicht eilig.
Er dient jetzt erstmal nur als Vehikel um dieses Feature fertig zu definieren.
Außerdem weis ich noch nicht ob Du damit in der Form einverstanden wärst.
Netter Gruß
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
Weiter geht’s
Ich mach heute den Alleinunterhalter
Jetzt eine Übersicht über TCP –Standardbefehle:
Das schwebt mir so vor:
Form.Hide
Form.Show
Form.Minimize
Form Resize
FormPosX
FormPosY
FormSizeX
FormSizeY
Close(Programmende)
CurrentConfig
Save Config
Load Config
Set Value, (welcher Wert), (Wert)
StartAction (irgend eine Aktion)
Na und was noch so kommt…….
Netter Gruß
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
OT (Now to something completely different)
Da is eine Zip, wo ich so eine Art digitalmixer mit einer ähnlichen Aufgabenstellung wie MARV gemacht habe (is schon älter)
unzip
wenn's auf der disk c:\ ist:
Start MX0.EXE
FILE->OPEN-> "saurier.mix"
DRV -> (right-mouse for config)
TRANSPORT-> Start / STOP / ZERO
bißchen rumdrücken, doppelclicken und right mouse Menues
Wenn's Spaß macht.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Na, du hast ja auch ein umfangreiches Programm, wo sicher noch ein paar Zugaben kommen..den Alleinunterhalter ..
Ich hab' schon mal den Helm aufgesetzt und bin in den Schützengraben gekrochen. Da wird js scharf geschossen.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Berechtigungen
Zitieren
Lesezeichen