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

**PicNick** · 22.11.2006, 16:00

Noch was: Wir haben ja bei Key-Val gesehen, daß das mit den Strings und Stringlängen so seine Haken hat.
Ich schau mir die Register-DLL in dieser Richtung durch.

Also, wenn da irgendwo Kanten auftauchen, nicht verbeißen, sondern Laut geben

**PicNick** · 22.11.2006, 16:42

mmmhh. Blöde Geschichte.
Also, was besseres fällt mir jetzt auch nicht ein:
Um die zurückgegebenen String Vergleichen zu können oder so:
(Tree_build_node)

Code:

        ppar = RnRegistNextPar(head, 0, ParName)        ' get first param
        While ppar <> 0                                  ' while params 
            StrLen = RnRegistName(ppar, ParName)
            WrkString = ParName.Remove(StrLen, ParName.Length - StrLen)
    ' WrkString passt jetzt wirklich
    ' braucht KEIN "new" vorher

Die DLL-Funktion
StrLen = RnRegistName(ppar, ParName)
Kann man auf alle register-Werte anwenden, also DIR, PAR und VAL
Der Name wird nun 2 x zurückgeschickt, aber was soll's

**marvin42x** · 22.11.2006, 19:28

@NumberFive:
Die Programme kann ich starten. Habe auch das reg ausgeführt aber ohne eine Messagebox zu bekommen. Die Dll Habe ich zusätzlich nach system32 kopiert.
Ich meine das ich das schon früher mal mit reg gemacht hatte.
Das Connectete aber nicht am Server.

Ich habe Dir jetzt ein Susi Sorglos Packet geschnürt in dem ist alles drin was ein Mensch so braucht. Wenn Du dich mal im icq meldest schicke ich dir was frisches. Damit kannst Du dann ein Netzwerk hinstellen und Tests durchführen.
Mich würde interessieren ob die RnRegist.dll auch von vb6 aus angesprochen werden kann.
Für den Amiga muss es ja nicht kompatibel sein.
Aber für unsere älteren Programmierer unter VB6 wäre es doch nicht schlecht.
MrNiemand sitzt in der Beziehung im selben Boot mit Dir oder umgekehrt. Vielleicht könnt ihr eine Allianz bilden.
So eine Art Veteranen Club

Ich bin gerade sehr knapp mit Resourcen. Was sich erst ändert wenn so eine Art Grundversion des RnWizards steht.
Vielleicht zersägst Du aber auch den RnWizard für Deine Zwecke und umgehst alle Probleme?
Wie auch immer es gibt viele Wege.
Melde dich bitte mal.
Und verzeih mir möglicherweise den Veteranen Club.

@PicNick:
Wenn ich fertig bin mit umfummeln auf allgemeinen Wunsch eines einzelnen Herrn.
Werde ich verstehen was Du zuletzt gesagt hast.
Das mit dem Knoblauch und das mit dem nicht verbeißen war ja noch relativ einfach.
Aber danach muss ich mir mein Tauchzeug holen und in Richtung Wunderbaum abtauchen um Erleuchtung zu erlangen.
Das wird nicht an mangelndem Interesse scheitern.
Die Gründe warum das scheitern könnte wären nur das mir die Götter die Erleuchtung verweigern.

Netter Gruß

**PicNick** · 22.11.2006, 19:48

Nun, die Sache mit Strings, die von der DLL zurückgegeben werden sollen:
Wenn du einen Leer-String erzeugst mit
MyString = new string(" ", 64)
und diese Stringadresse an die DLL weitergibts, kann die wunderbar ihr Zeugs drin ablegen. ABER:
Die Länge ist aus Sicht von VB nach wie vor 64, auch wenn eigentlich nur drei belegt wurden.
Daher hauen Vergleiche und andere Manipulationen nicht hin, weil (scheinbar) der String mit Blanks auf 64 Bytes aufgefüllt ist.
daher muß man aus dem einen String einen neuen machen, aber gleich in der richtigen Länge. Das macht man, indem man diese Blanks hinten abzwickt. (remove)
Das Problem hatten wir sofort beim Key-Value, bei den Registry-Sachen ist es nur noch nicht stinkig geworden.

Das Registry-Lesen, z.B
ppar = RnRegistNextPar(head, 0, ParName) ' get first param
geht ins Auge, wenn du dann z.b. vergleichst
if ParName = "SEMMELHUND" THEN
gassi_gehen()
Das funzt nicht so nicht
Was du brauchst, ist die tatsächliche Länge der strings und die liefert der DLL-Befehl
StrLen = RnRegistName(ppar, ParName)
DANN geht
passender_string = ParName.remove(StrLen, (64 - Strlen))
und jetzt haut es hin.

(Statt "64" nehmen wir aber den wert von ParName.Length, dann müssen wir nicht aufzupassen, was wir vorher bei "NEW" angegeben haben).

Besser ?

**marvin42x** · 22.11.2006, 20:01

Ah, alle klar.
Muss einem doch gesagt werden.
Nun muss ich den Abend nicht im Ungewissen Dunkel verbringen sonden nur im Dunkeln.

Netter Gruß

**PicNick** · 22.11.2006, 20:19

Na also.
Gleich noch was: Wenn wir das Layer-1 Format auch zwischen Wizard und seinen Kinderchen beibehalten wollen, sollten wir als Target-Zieladresse ein standard Pseudo-Ziel angeben ("Command-Interpreter").
Dann kann es auch in Zukunft keine Probleme geben, was nun zu routen ist und was nicht.

Die PID als Ziel könnten Konflikte kriegen mit unseren anderen IDs. (Servos, adc, etc.)

Die Rückadresse lassen wir einfach mal auf NULL

Dadurch ist ein frühzeitiges Splitten von routbaren Layer-1 Messages und administativem Zeugs möglich, d.h. SERVER und Wizard kommen sich von vornhinein nicht in die Quere.

(Hintergedanke: Mit einem anderem Pseudo-Target könnten wir dann sehr einfach (und modular) so Sachen machen wir zentrales Protokoll/Log oder so.

**marvin42x** · 22.11.2006, 20:32

Hört hört, Hintergedanken.
Klingt irgendwie nicht schlecht. In so einer Richtung habe ich überhaupt noch nicht gedacht.
Fazit:
Es bleibt spannend

Dann lass mal zu gegebener Zeit hören, auch wie der Messages String aussehen könnte.

Netter Gruß

**PicNick** · 23.11.2006, 10:57

So, war etwas mehr vergraben, der Hund, der.

Ich hab der Einfachheit halber das korrigierte Form1.vb als zip eingefügt, das restliche Projekt hast du ja

Nachtschwärmer aus Bridge-Town: bei Cut & Paste immer guckst du, ob die VariablenNamen auch passen. Beim "DoCommand" waren da leichte Differenzen
Beim "invoke" isses so, daß er alles, was in den "invokten" Subs passiert, als Fehler des "invoke" selbst anmault. Geschmissen hat es ihn ganz woanders, Krüppel, das.

**marvin42x** · 23.11.2006, 15:42

Danke fürs Fixing.
Es läuft wunderbar.
Ich kann jetzt an der Stelle erstmal die Klappe zu machen.
Befehlshandling auf den Kommunikationswegen läuft.
Und obwohl ich weis was es kann, freue ich mich trotzdem immer wieder daran wenn es jetzt auf Geheiß pariert und Befehle aus dem Netz befolgt.
Wenigstens einer der sich was sagen lässt.
Ich frage mich ob ich das ganze nicht eigentlich deswegen mache

Jetzt werde ich noch die Formular Objekte soweit es geht vom Kernprogramm abkoppeln.
Und das Setzen von Default Werten Zentralisieren.
Danach sollte Parametrieren über Config dran sein.

Netter Dank aus Bridge -Town