Druckbare Version
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ß
na, na. Dafür bin ich in VB ein Blinder :oops:Zitat:
..unauffällig entsorgen..
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