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

Vier Dinge:

Eins:
Ich habe mal Test weise eine Dll aus dem Internet eingebunden, das ging ohne Aufhebens.
Ich musste noch nicht mal einen Verweis hinzufügen.

Zwei:
Ich weis nicht wo Du den Pfad hinschreibst:
Zitat:
declare Tralala LIB "C:\da\und\dort\rnregist.dll" etc.
Also in dem Projekt existiert das nicht.

Drei:
Irgendwas ist bei Dir anders als bei anderen Menschen.

Vier:
Ich habe das an zwei verschiedenen Rechnern ausprobiert immer mit dem gleichen Ergebnis.
Habe das einem Anderen gegeben der hat das bei sich gemacht , mit dem selben Ergebnis.
Es steht also 3 zu eins für mich.

Netter Gruß

Das ist Form1.vb

Code:

---

Imports System.Runtime.InteropServices

Public Class Form1
    Dim heute As Date
    Dim yy As Int16
    Dim mm As Int16
    Dim dd As Int16
    Dim DllVal As Integer

    Dim Selected As Integer
    Dim NodSel As System.Windows.Forms.TreeNode

    Dim RegTop As Integer
    Dim RegistryName As String


    Declare Function RnRegistInit Lib "rnregist.dll" () As Integer
    Declare Function RnRegistRead Lib "rnregist.dll" (ByVal top As Integer, ByVal filename As String) As Integer
    Declare Function RnRegistFlush Lib "rnregist.dll" (ByVal top As Integer, ByVal filename As String) As Integer

    Declare Function RnRegistNextDir Lib "rnregist.dll" (ByVal Hd As Integer, ByVal pre As Integer, ByVal dir As String) As Integer
    Declare Function RnRegistFindDir Lib "rnregist.dll" (ByVal Hd As Integer, ByVal dir As String) As Integer
    Declare Function RnRegistCifDir Lib "rnregist.dll" (ByVal Hd As Integer, ByVal dir As String) As Integer

    Declare Function RnRegistNextPar Lib "rnregist.dll" (ByVal Hd As Integer, ByVal pre As Integer, ByVal dir As String) As Integer
    Declare Function RnRegistFindPar Lib "rnregist.dll" (ByVal Hd As Integer, ByVal dir As String) As Integer
    Declare Function RnRegistFindParDef Lib "rnregist.dll" (ByVal Hd As Integer, ByVal dir As String) As Integer
    Declare Function RnRegistCifPar Lib "rnregist.dll" (ByVal Hd As Integer, ByVal dir As String) As Integer
    Declare Function RnRegistNextVal Lib "rnregist.dll" (ByVal Hd As Integer, ByVal pre As Integer, ByVal dir As String) As Integer
    Declare Function RnRegistCifParVal Lib "rnregist.dll" (ByVal Hd As Integer, ByVal dir As String, ByVal val As String) As Integer
    Declare Function RnRegistCifParValSet Lib "rnregist.dll" (ByVal Hd As Integer, ByVal dir As String, ByVal val As String) As Integer
    Declare Function RnRegistDrop Lib "rnregist.dll" (ByVal Hd As Integer)
    Declare Function RnRegistName Lib "rnregist.dll" (ByVal Hd As Integer, ByVal name As String) As Integer
    Declare Function RnRegistNameSet Lib "rnregist.dll" (ByVal Hd As Integer, ByVal name As String) As Integer
    Declare Function RnRegistRef Lib "rnregist.dll" (ByVal Hd As Integer) As Integer
    Declare Function RnRegistRefSet Lib "rnregist.dll" (ByVal Hd As Integer, ByVal ref As Integer) As Integer


    Public Sub New()

        InitializeComponent()
        Selected = 0

    End Sub
    Private Sub Tree_build_node(ByVal head As Integer, ByVal TreeHdr As System.Windows.Forms.TreeNode)
        Dim pdir As Integer
        Dim ppar As Integer
        Dim pval As Integer
        Dim DirName As String
        Dim ParName As String
        Dim ValName As String

        Dim NodSub As System.Windows.Forms.TreeNode
        Dim NodVal As System.Windows.Forms.TreeNode

        DirName = New String(" ", 64)
        ParName = New String(" ", 64)
        ValName = New String(" ", 64)

        pdir = RnRegistNextDir(head, 0, DirName)        ' get first param
        While pdir <> 0                                ' while params
            NodSub = New System.Windows.Forms.TreeNode
            NodSub.Text = DirName
            NodSub.Tag = pdir
            TreeHdr.Nodes.Add(NodSub)                    ' create treeview
            Tree_build_node(pdir, NodSub)
            pdir = RnRegistNextDir(head, pdir, DirName)        ' get first param
        End While
        ppar = RnRegistNextPar(head, 0, ParName)        ' get first param
        While ppar <> 0                                  ' while params
            NodSub = New System.Windows.Forms.TreeNode
            NodSub.Text = ParName
            NodSub.Tag = ppar
            TreeHdr.Nodes.Add(NodSub)                    ' create treeview
            pval = RnRegistNextVal(ppar, 0, ValName)        ' get first value
            While pval <> 0
                NodVal = New System.Windows.Forms.TreeNode
                NodVal.Text = ValName
                NodVal.Tag = pval
                NodSub.Nodes.Add(NodVal)                    ' create treeview
                pval = RnRegistNextVal(ppar, pval, ValName)        ' get first value
            End While
            ppar = RnRegistNextPar(head, ppar, ParName) ' next param
        End While

    End Sub

    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        Dim DirName As String
        Dim ValName As String
        Dim phdr As Integer

        Dim NodHdr As System.Windows.Forms.TreeNode

        DirName = New String(" ", 64)
        ValName = New String(" ", 64)

        RegTop = RnRegistInit()
        RegistryName = "t_vis_set.cfg"
        DllVal = RnRegistRead(RegTop, RegistryName)
        phdr = RnRegistNextDir(RegTop, 0, DirName)
        While phdr <> 0
            NodHdr = Me.TreeView1.Nodes.Add(DirName)            'Top Directory
            NodHdr.Tag = phdr                                  ' save position
            Tree_build_node(phdr, NodHdr)
            phdr = RnRegistNextDir(RegTop, phdr, DirName)
        End While
    End Sub
    Private Sub TreeView1_AfterSelect(ByVal sender As System.Object, ByVal e As System.Windows.Forms.TreeViewEventArgs) Handles TreeView1.AfterSelect
        Dim Seltext As String
        Dim slen As Integer
        NodSel = e.Node
        Seltext = New String(" ", 64)
        Selected = e.Node.Tag
        slen = RnRegistName(Selected, Seltext)
        TextBox1.Text = Seltext
    End Sub
    Private Sub TextBox1_TextChanged(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles TextBox1.TextChanged
        Dim slen As Integer
        If Selected <> 0 Then
            slen = RnRegistNameSet(Selected, TextBox1.Text)
            NodSel.Text = TextBox1.Text
        End If
    End Sub
    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim retval As Integer
        ' RegistryName = "something_different_or_the_same.CFG"
        retval = RnRegistFlush(RegTop, RegistryName)
    End Sub
End Class

---

Ja, das Form1 sehe ich ja.
Auch die Deklarationen.
Die sind OK
Ist die alte Schreibweise, aber völlig in Ordnung so.
Ich habe mit einer genau solche Deklaration eine andere Lib mal eingebunden und das ging ohne zucken.
Da legst Du die Lib einfach ins bin Verzeichnis und alles ist fein.
Er weigert sich einen Verweis zu setzen weil er sagt da ist keine. Der tut so als wollte ich eine nicht dll Datei als dll verkaufen.

Ich hatte schon mal mit MrNiemand einen dll-Versuch zwischen VB6 und VB2005 gemacht.
Der lief im ersten Anlauf VB6 dll in vb2005 OK
Vb2005 dll in vb6 Problem.


Es ist ganz gut, dass wir das Problem haben. Denn Du kannst das bei Dir gar nicht nachvollziehen.
Du kannst nur zu Deinem Kollegen gehen und das da mal probieren.

Wer den Fehler als erstes finde hat gewonnen :-)

Ich bleib drann

Netter Gruß

Edit:
Sag mal, kann es sein das die System Uhr vom Forum falsch geht?

Zitat:

---

..einen Verweis zu setzen ..

---

Den braucht er nicht wirklich. Ist bestenfalls hübsch, wenn verwendete dll's im Projekt sind (und man install-sets kreieren will)

Ist ein ganz anderer Kaffee, wenn man mit VBxx eine DLL erzeugt, da geht zwar mehr, aber auch viel spezialisierter. da mag zwische VB6 /VB2005 DLL schon ein Unterschied sein.

Vergiß die DLL im Projekt, das geht ihn eine Sch... an , schau nur, daß der Pfad stimmt.

Schlimmstenfalls kopier die DLL dorthin, wo die anderen sind, also WINDOW\SYSTEM32 oder so.

Wenn Problem, dann eines mit den Pfaden (environment)
Wenn er eine exe oder dll sucht, geht er erst lokal, und dann über
PATH= ............................

(oder man gibt den kompletten Pfad im "declare" an)

Das ist ja lächerlich

System einrichten ... viel Glück

virtuelle Kanne Kaffee reinstell ;-)

Zitat:

---

..virtuelle Kanne Kaffee ..

---

Cyber-coffeine nutz da nix.
Irgendeine Idee ? Ich hab das probiert auf W2k prof. mit der kompletten VB2005 Suite, auf XP sp2 mit VB2005 express und kann den Fehler nicht nachvollziehen.

An UllrichC:
Danke für den Kaffee :-) kann sein das wir den brauchen.

Ich fasse mal den momentanen Stand der Ermittlungen zusammen.

Die Dll geht bei PicNick tadellos.
Schlussfolgerung:
Die Dll lässt sich aus VB2005 benutzen.

Die DLL geht bei Marvin42x auf drei Rechnern nicht.

Schlussfolgerung:
Die Systeme kann man als das zu erwartende Umfeld ansehen.

Aufgabe:
Funktionsfähigkeit im zu erwartenden Umfeld herstellen.

Fehlersuche:

Marvin42x hat probeweise eine zufällige Dll aus dem Internet runtergeladen bei der die Einbindung in vb2005 beschrieben war und mit einer entsprechenden Deklaration eingebunden und angesprochen.
Das ganze ohne jegliche Pfadangabe. Die Dll muss nur entweder in bin oder bin\debug oder bin\release liegen.
Wie PicNick schon sagte ohne Verweis hinzuzufügen.
Dieser Vorgang lief problemlos ab.

Auch eine Kernel32.dll Einbindung läuft bei Marvin42x ohne Probleme.

Marvin42x hat die RnRegist.dll in alle nur denkbaren Verzeichnisse kopiert.
Einschließlich system32 und system

Der Befehl: regsvr32 c:\Windows\system32\RnRegist.dll
und regsvr32 RnRegist.dll
Schlagen fehl mit der Fehlermeldung:
LoadLibrary(„RnRegist.dll“) fehlgeschlagen – Das angegebene Modul wurde nicht gefunden.

Dieser Befehl regsvr32 war einmal nötig um eine VB6 Dll anzusprechen. Darum dieser Versuch.
Vorsichtige Schlussfolgerung:
Alle Fehlermeldungen laufen darauf hinauslaufen, dass er die Dll nicht findet obwohl man ihn in jeder erdenklichen Art mit der Nase drauf stößt.
Und der regsvr32 Befehl sagt er findet die nicht, er sagt ja nicht wie schon vorgekommen, er kann sie nicht registrieren weil sie nicht richtig ist. In dem Fall hat er sie offensichtlich gesehen und überprüft.
Schlussfolgerung?

So erstmal Strich, geht später weiter

Netter Gruß

So, weiter geht’s:

Der erstrangige Schluss aus der Situation kann sein:
Schlüssel Annahmen:
Bei PicNick arbeitet die Datei
Bei Marvin42x arbeitet die Datei nicht
Beide Systeme sind ausreichend identisch.
Marvin42x arbeite mit einer Kopie, nicht mit dem Original.
Es fand ein Kopiervorgang, Ferndatentransfer, Kopiervorgang der Datei statt.

Schlussfolge:
Die Datei entspricht nicht dem Original.

Meinung:
Die Pfadangabe in der Deklaration mit c:\……. Kann nicht der Weg sein.

Marvin42x wird aber auch das noch prüfen.

Zwischenstopp

Netter Gruß

Nachsatz:

Wenn jemand was Bestimmtes sucht und das bestimmte ist nicht da obwohl was Ähnliches mit selben Namen da ist, sagt er auch: „ich kann das nicht finden“.
Und dann kann man sich auf den Kopf stellen ihm zu sagen wo das Ähnliche liegt, obwohl es doch den gleichen Namen hat.

Netter Gruß

Ich hab sicherheitshalber die DLL nochmal erstellt. Bin nicht sicher, ob eine verwendete lib nicht im debug mode erstellt wurde, d.h. da braucht er ein paar DLL-Varianten, die ich zwar überall habe, weil ich ja VC++ installiert habe, aber bei euch ist das möglicherweise nicht der Fall.
wenn's wahr ist, hieße das, das er zwar rnregist.dll findet (so blöd kann er ja nicht sein) daß er aber dann nicht weiterkommt, aber nicht weiß, wie ihm geschieht.

Versuchs bitte mal

geht

Netter Gruß

Zitat:

---

..geht ..

---

*unausprechliches*

Da lassen wir uns doch nicht unterkriegen gell? :-)


Edit: MrNiemand hat da im Hintergrund ein bisschen mit geschoben und den richtigen Verdacht gesät:

Thanks :-)

*stinkesauer*indenA..beiss*

Es ist immer solcher Schwachsinn, an dem man Nächte verpulvert.

Ja, ich bin auch drauf reingefallen. Ich habe geglaubt ein schwieriges Problem zu haben.
Es ist halt genau beim ersten mal passiert.
Nimms leicht, klar, bisschen schade um die Zeit aber das Thema Lib Einbinden ist nun ausführlich in diesem Thread nachzulesen :-) :-)


Netter Gruß

So, jetzt zurück zum Mainstream:

Das sieht absolut klasse aus auch die Handlin Routinen sind sehr kompakt.
Ist schon gekauft.
Das ist lieb das Du das in einer Demo in vb2005 rüberschiebst.
Ich schwinge zwar große Wörter aber wenn es um die Praxis geht bin ich für jede Hilfe dankbar.
Ich werde mir jetzt mal angucken wie ich das integriere. Ich werde dabei auch noch einige Umstrukturierungen vornehmen damit die Komponenten am Ende einen einheitlichen Befehlssatz besitzen der auf möglichst allen Wegen ansprechbar ist.
Ich meine:
Config. File
TCP –Befehl
Komandozeilenargument.

Da ist natürlich Essig mit einer Demo nächste Woche :-)

Netter Gruß

Auch das Config File sieht gut aus.
Eine sehr komfortable Sache.
Und wenn ich das richtig sehe steht es zur Laufzeit im Speicher und wird nur bei Anforderung in die Datei geschrieben.
Wie Du schon angekündigt hast.
Werde mich aber erst morgen weiter damit auseinander setzen können. Die liebe Zeit.

Bis dahin

Netter Gruß

Ich werd versuchen, morgen etwas doku zu Config zu liefern.
Hätte mir gedacht, daß man z.B.

Code:

---

[MARV] Server = "127.0.0.1"; port = 42 ; rootdir = "c:\RN\"; exedir = "C:\exedir\"
 [.SCREEN] posx = nnn; posy=nnn; DISPLAY = MINIMIZE
 [.PROTFILE]  file = "protokoll.txt" ; OPEN = AUTO
 [.STARTUP]
  [..FIRST]    shell = "dideldum.exe" ;  param = "param1", "param2", "param3" ;Start = AUTO ; ID = nnn
  [..SECOND]    shell = "tralala.exe" ;  param = "param1" ; Start = MANU; ID = nnn

---

Ich hab' die Erfahrung gemacht, am leichtesten geht es, wenn die Baumstruktur die gleiche ist wie die Applikations-Struktur.

Einer Meinung mit Dir.
Gleiche Strukturen wo immer man kann.
Ich werde auch noch mal die Programm Struktur der Komponenten dahin gehend ändern das jeder der möglichen Befehle eine eigene Routine bekommt.
Damit ist ein gleichmäßig leichter und übersichtlicher Aufruf über alle Wege gewährleistet.
Das wird dann nach und nach immer Bausteinhafter.
Alle Komponenten werden dann einen weitgehend identischen Aufbau haben.
Wenn man eine Komponente verstanden hat, hat man alle verstanden.
Like a Mixer ;-)

Da ich gerade bei einheitlich bin.
Ja Du hattest Recht als Du weiter vorne vermutet hast, dass wird sicher noch nicht alles sein.

Mein Vorschlag wäre:
Einheitliches Look and Feeling.
Auf der einen Seite soll es möglich sein das jeder macht was er will.
Aber wir sollten mindestens ein Standard Design entwickeln bei dem die Bedienung immer denselben Gepflogenheiten entspricht.
Wenn man eine Komponente verstanden hat, hat man alle verstanden.
Das meine ich sicher nicht als Reglementierungsversuch.
Mir liegt vielmehr am Herzen das ein Benutzer in kürzester Zeit mit seinem System klarkommt. Und es mögen lernt.
Einen ersten Vorversuch zum Überlegen habe ich beim OneTrackbar gemacht.
Aber da gibt es sicher noch bessere Lösungen. Ich denke wir sollten aber schon paralell darüber nachdenken.

Jetzt schließe ich aber erstmal sonst kündigst Du mir noch die Freundschaft :-)

Netter Gruß von der Nachtschicht

Morjen !
DLL Was ich noch rauskriegen muß:

dzt. gebe ich Object-Referenzen (Adressen) als INTEGER her, bzw übernehme sie so. Im Prinzip reicht das auch. Ist aber unbefriedigend. Eigentlich sollten das Objects sein

Für diverse Sachen brauche ich so eine Art Callback-Methode, d.h. ich muß aus der DLL Methoden im VB aufrufen, ev. aus einem anderen Thread. Ich werde da etwas experimentieren müssen. Ideen ?

Morgen.
Du hörst Dich an wie jemand der gerade an einer asynchronen TCP/IP Client Funktionalität mit Eventhandling schraubt. Oder einem gemeinsamen Configpool im Speicher.

Das ist dann schon die Kür.
Wird für mich schwer sein da konstruktive Wörter zu finden.
Der Thread wird aber zahlreich mitgelesen vielleicht gibt es ja da Erfahrungen.

Netter Gruß

Auf jeden Fall mal ein wenig Doku zu der DLL

Zitat:
„Ein wenig Doku“…..

Was für ein Ding.
Da muss ich mich aber erstmal hinsetzen.
Das ist mehr als ich jetzt erwartet habe.
In Hinsicht auf die Config Möglichkeiten und in Hinblick auf die Demo.
Ich werde meine Sachen dann mal unauffällig entsorgen.

Ein schönes Teil

Netter Gruß

Zitat:

---

..unauffällig entsorgen..

---

na, na. Dafür bin ich in VB ein Blinder :oops:

Das mit dem Entsorgen geht schon in Ordnung.

Was mit dem Config Modul raus springt ist ja das Idealbild von dem was mir vorschwebt.
ich bin vieleicht etwas Unwissend, aber nicht blöd :-)

Netter Gruß

However, Haupsach', es hilft.

Status Callback: Is das Problem aufgetaucht, das VB offenbar irgendeine Calling-Convention verwendet, die ich mir suchen muß *grmpf*
Wirkt sich so aus: Ich kann zwar Callbacken, aber beim Return scheppert es dann. Soweit isses gekommen, daß ich den VB mit dem Disassembler debugge *auweia*
Schlimmstenfalls machen wir als interimslösung irgendeine andere Schweinerei *grunz*

Stichwort Callback, schepper:

Wenn es scheppert hat man oft daneben gegriffen.
Mir fällt da spontan das Wort Singleton ein. Ich habe das verwendet um meine Fenster -Instanz eindeutig zu machen.
Maybe das Du das in Deiner Übergabe auch machen musst.

Falls ich arg daneben liege sehe mir das nach. Ich bin mit Dlls in der Hinsicht noch nicht bewandert.

Netter Gruß

@PicNick

Ich weiß leider nicht genau wo dein problem ist mit den CallBack von VB aus aber ich kann dir folgendes auf meiner Erfahrung mit VB6 sagen.

VB ist nicht Thread Sicher !
ComObjekt als Callback's Funktionieren sehr Gut.
Was möchtest du genau machen ?

Ich habe für Comobjekte die in anderen Sprachen verwendet werden und geThreaded sind folgen Lösung gefunden. Ich erzeuge ein unsichtbarer nachrichten fenster wenn die instance des Comobjets erzeugt wird. wenn ich jetzt aus dem Thread ein Event feuern will mache ich das über das fenster und schon tut's.

@all

Irgend wie habe ich zur Zeit massive Schwierigkeit das Protokoll zu verstehen. geht das nur mir so ? Es tut zwar weh das zu geben zumüssen
aber irgendwie Fehlt mir die zusammen fassung.

Gruß

@PicNick:
Ich habe Dir mal ein TCP/IP -Beispiel in VB2005 mit Dll gemailt wie ich es anfangs verwendet habe.
Ich hatte dann im Zuge der Entwicklung die Dll aufgelöst und der Übersichtlichkeit halber als Klassen in mein Projekt aufgenommen.
Inzwischen ist es nun aber wieder konzeptgerechter wenn das eine DLL wird.
Vielleicht ist da irgendwas was Dir weiterhilft.

@NumberFive:
Mach Dir wegen des Protokolls keine Sorgen.
Wenn wir hier aus dem Gröbsten raus sind werden wir das noch mal Ansprechen.
Ich habe in der Richtung auch noch nichts am laufen.
Das wird aber im Zuge der Entwicklung rasch zum Thema werden.

Edit:
mit vb meinst Du jetzt vermutlich VB6?
VB2005 ist was sehr anderes und eben Threadsicher. darum lässt es auch nicht so ohne weiteres mit sich reden.

Edit2:
im Umgang 2005 zu Vb6 wird sehr oft mit Wrappern gearbeitet um das Problem zu lösen. Ich habe aber damit noch nicht gearbeitet deswegen kann ich das hier nur als Stichwort beitragen.

Netter Gruß

Gute Nachricht:
Weil ich mich von solchen Silizium-Batzen grundsätzlich nicht piesacken lasse, haben wir das Callback-Problem jetzt schon halbwegs im Griff. (Lesen hilft, is nur ein Tip)
Also haben wir ja was zu tun. Wie schon Marvin42 sagte, wir müssen kurz einmal die PC-GUI-Fronten begradigen, dann sind wir wieder bei unseren Rn-Standards u. Protokollen

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ß

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 :mrgreen:

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.

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ß

Zitat:

---

..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*

Prosecco ist auch keine schlechte Idee :-)

Ja, Bootloader machen wir wenn wir sturzbetrunken sind

Netter Gruß :mrgreen:

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

Code:

---

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

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ß

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.:oops:

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

Ich werd noch Doku machen.

Laß hören, wenn du Zeit hast

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ß

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ß