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

[marvin42x]

Zitat: Gute Nachricht
1. Ja, Lesen bildet.
2. Gratulation.
Etwas anderes hätte Deinem Seelenfrieden auch nicht gut getan

Status:
Habe jetzt Deinen MARV Cofig -Vorschlag in den neuen TreeViewe von MARV eingelesen.
So wie Du es hingeschrieben hast ist es genau das was ich mir gewünscht hatte. Nicht zu viel und nicht zu wenig.
Das lassen wir jetzt erstmal so.
Bis uns noch mehr einfällt.

Randbemerkung:
Ich glaube, ich hatte es nicht erwähnt. MARV wird selbstverständlich auch Netzt –Remote fähig sein sobald er online ist. Nur der Befehlssatz den er kann wird etwas umfangreicher sein.
Der RN-Server könnte Beispielweise auch den MARV manipulieren.
Da der Server Netzwerkseitig sehr im Bilde ist vermute ich das das noch sinnvoll sein könnte.
Kann sein, dass die gegenseitige Beeinflussbarkeit ab und an noch Thema wird.

Netter Gruß

[PicNick]

Nun, ist die Frage, wer das Sagen hat. Natürlich könnte sich der µC und damit den RN_SERVER ein Profil aussuchen, da er ja weiß, was die µC so an Geräten draufhaben. Wenn die aber nicht spezifisch sind, also einfach ADC u. Servos (z.B. wie bei einem einfachen Fernbedienungs-Betrieb) ist das nicht unbedingt eindeutig.
Umgekehrt könnt' MARV den der ausgewählten Konfiguration entsprechenden Bootloader starten

Also die Frage: Sucht sich der Server seine Clients aus oder der Client seine Server ?

Kommt wahrscheinlch drauf an: Tüftelst du grad am Robby rum, hast du eine gleichbleibene Config am PC und lädst den µC immer wieder nach.
Bastelst du am PC, bleibt der Robby unverändert und du hast start-stop am PC

However, ich glaub', am Wichtigsten ist mal, daß wir am PC ein Setup haben, daß er sich unter einer bestimmten Config merken kann, also Slider links oben, ADC rechts unten und das Radar schön groß in der Mitte.

[marvin42x]

Bootloader:
Das mit dem Bootloader ist ja noch mal eins drauf.
Gefällt mir, der Ausblick auf das was wir könnten.

Das mit den Wichtigkeiten sehe ich auch so.
Ich realisiere deswegen auch als erstes das laden ändern, erstellen und Speicher mit der neuen Config –Dll bei MARV und einem TestClient.

Da ich mich entschlossen habe Das Konzept einer Standard -Klasse für Die Clients (like Mixer) noch konsequenter als schon geschehen durchzusetzen schreib ich wie immer erstmal alles neu.

Es ist ein Kreutz, wenn man besser wird.

Netter Gruß

[PicNick]

..schreib ich wie immer erstmal alles neu..

nur nicht zu hastig ! Alles, was funzt, haut man nicht weg !

Aber es ist richtig, gerade das administrative Zeugs (doppelklick: wenn nicht da, dann starten, wenn minimized, dann ausgraben, wenn eh' am Schirm, dann nach vorn und Fokus drauf, etc.) ist bei allen Komponenten immer wieder das Gleiche, ist angenehm, das nur einmal als "Generic RN-Component" schreiben zu müssen.

Erst wenn das steht, dann mit "inherit" was Spezielles drauf hängen.


EDIT: Das mit dem Bootloader machen wir dann, wenn wir das restliche Projekt mit Flaschenweise Prosecco begossen haben. *ermbarmen*

[marvin42x]

Prosecco ist auch keine schlechte Idee

Ja, Bootloader machen wir wenn wir sturzbetrunken sind

Netter Gruß

[PicNick]

A propos sturzbetrunken:

Solche DLL Functions OHNE return-Value mag der VB irgendwie nicht.

Da müßte man die Deklaration erweitern. Ein "Delete-Config-Entry" Beispiel anbei

Declare Function RnRegistDrop Lib "\indizes_disk\exe\rnregist.dll" (ByVal Hd As Integer) As Integer

        Dim res As Integer
        If Selected <> 0 Then
            res = RnRegistDrop(Selected)
            Selected = 0
            NodSel.Remove()
        End If

Läßt sich vielleicht mal klären, aber sei's d'rum

[marvin42x]

Apropos Apropos:

Danke für das Fixing.
Habe ich gleich als Delete Button eingebaut

Da das auf die Art geht und irgendwie unauffällig aussieht könnte man ja erstmal Gras drüber wachsen lassen. Ich bin da schlicht, wenn er will und kostet nicht viel, soll er haben.
Ich habe an die Deklarationszeile einen Kommentar rangemacht
Wenn ich das richtig sehe war es auch der einzige Fall ohne Rückgabewert.

Bin gerade dabei dem MARV die Remote Befehlsfähigkeit zu implementieren.
Das brauche ich bevor ich die Registry auswerten kann.
Das ist dann Programmintern immer ein und derselbe Aufruf egal von wo der Befehl kommt.
Insgesamt werde ich Deinem Ratschlag folgen und nicht alles neu machen.
Da ich von Anfang an Baugruppen haben wollte besitzt das ja im Prinzip schon die richtige Struktur. Und zukünftig verändert sich das, wie man bei der Befehlsauswertung sehen kann auch schrittweise in die richtige Richtung.

Netter Gruß

[PicNick]

So, es sind schon wieder Berliner Meerschweinchen gefragt.

Anbei ein VB-Project IP_DLL und eine "RnRegist.DLL"

In der Dll sind ein paar IP -Funktionen zusätzlich zu den Config-Sachen

Im VB das gewohnte Spiel mit dem "DLL-Finden".

der Basic hat nur Grundfunktionen drinnen, es fehlt jede Eleganz.

Schau mal, ob du dich auskennst (mit dem Callback-Trara)

Ich werd noch Doku machen.

Laß hören, wenn du Zeit hast

[marvin42x]

Manchmal frage ich mich wann Du das alles machst.

Egal.

Dll Finden:
Selbes Phänomen wie letztes Mal.
Er findet die Lib nicht oder sie gefällt ihm nicht, sagt er, ohne das näher zu erläutern was nun genau meint.
Ich habe alle alten überall rausgelöscht um keine Verwirrung zu bekommen.
Und ihm die neue zu Füßen gelegt.
Wenn ich ihn mit der Nase drauf stoße will er sie nicht.

ich bleib drann

Netter Gruß

[marvin42x]

Programm:

Die Aufrufe decken sich stark mit dem wie ich es verwende.
Was ja durch die Aufgabenstellung auch nahe liegt.
Das bedeutet, dass ich das recht schmerzfrei integrieren kann.

Du bist ja des Visual Basics schon ganz schön mächtig.
Ist wohl doch kein neues Ufer, sondern nur das Alte frisch gestrichen

Da ich mich lange genug mit dem TCP/IP rumgekloppt habe weis ich so eine Lib zu schätzen.
Ich werde dann mal daran gehen und das ausprobieren.

Wiederholung:
Das Verpacken in Musterprojekte ist sehr angenehm und hilfreich.

Netter Gruß