Re: dhRichClient3-Toolset

Tech-Archive recommends: Speed Up your PC by fixing your registry

Hallo Olaf,

Schmidt schrieb:

Hier nochmal das modFactory.bas inkl. des BugFix für
das von Ulrich angemahnte Fehlverhalten.


Hat nun einen neuen Bug. Wenn der Fehlerhandler anspringt, wird das Working Dir nicht mehr zurückgesetzt.

Funktioniert mit DLLs in AppPath und auch irgendwo
auf der Platte mit angepaßten ToolSetPath$
Danke für's gegenchecken - damit dürfte meine eher
"noch einsteigerfreundlich" gehaltene Variante erstmal
rund sein - Ulrichs Variation zu dem Thema sollte dann
noch flexibler nutzbar sein (sowie ohne ChDir-Trick) und
dürfte dann für die "Pro's" noch so ein wenig mehr abdecken.


Neue Version ist hier:

<http://www.prosource.de/Temp/Test_dhRichClient3_V1.1.zip>

An Ulrich - bevor ich mit zusätzlichen "neuen Demos"
weitermache, wäre gut, wenn wir uns zuvor auf eine
einheitliche Schnittstelle (also das, was das Factory-
Modul nach aussen hin anbietet) einigen könnten,
damit später Dein Modul einfach so ein- bzw. umgehangen
werden kann anstelle von meiner "Einfach-Variante".


Mein Modul unterscheidet sich ja nicht nur durch die Vorgehensweise bei der Instantiierung. Also selbst bei der gleichen Schnittstelle sind die Ergebnisse unterschiedlich (zB kein Fallback, immer regfree wenn kompilierte Ausführung, Public Vars für den Zugriff auf die Objekte, geht schneller als über Properties, aber man kann natürlich die Vars auch willkürlich oder versehentlich überschreiben).

Außerdem war das Modul eigentlich nicht für die Öffentlichkeit bestimmt. Ich habe mir das geschrieben, um es bei meinen Anwendungen einzusetzen, und einen Link zum ersten Entwurf deswegen gepostet, damit andere auf "Fehlersuche" gehen können :-)

Ok, mein Vorschlag wäre, nachdem der Weg zur aktuellen Version ja oben steht:

möge jeder, den es interessiert, sich das Dingens holen und verwenden wie er es mag. Ich habe auch nichts dagegen, wenn Du es verwendest (zB Naming anpassen und in die Demos mit aufnehmen als Alternative).

Nur so am Rande erwähnt: ich werde das Gefühl nicht los, daß in Deiner Direct.COM noch der eine oder andere Hund begraben liegt. Aber um das einigermassen hieb- und stichfest zu untermauern, müßte ich die Sourcen kennen. Sonst wird das Detektivarbeit und aufwendig.

Punkte, die mich stutzig gemacht haben:

- bei meinem ersten Versuch hat GETINSTANCE ohne Fehlermeldung (via LastDll-Error) reagiert, obwohl das Laden der dhRichCLient3.dll fehlgeschlagen ist. Das müßte doch in GETINSTANCE bemerkt worden sein und sollte dann auch nach draußen kommuniziert werden. Evtl. wäre ja auch ein weiterer ByRef Methodenparameter für die Rückmeldung möglich. Oder eine weitere Methode/Function in DirectCOM.dll, benamst zB. LastError oä.

Dann wundert es mich, warum einerseits eine Instantiierung einer Klasse aus dhRichClient funktioniert, wenn dRC registriert ist und die dll nicht im Applikationspfad sondern sonstwo liegt. Der Programmlader muß ja trotzdem wissen wo er die per LoadTimeLinking angeforderte SQLite dll herbekommt.

Offensichtlich ist dem dabei wurscht das das Working Dir der Applikation woanders hinzeigt. Er nimmt wahrscheinlich einfach den üblichen Suchpfad: soll dRC laden, weiß den Pfad dorthin aus der Registry, findet Bezug auf SQLite dll in der dRC dll, und beginnt das Abklappern mit dem Verzeichnis, in dem die dRC dll liegt.

Das funktioniert auch wenn DelayLoad stattfindet. Ich jedenfalls hatte bisher noch nie Schwierigkeiten, einen registrierten COM-Server zu laden, der seinerseits wieder per Declare eine Standard-Dll einbindet. Liegt die Standard-Dll im gleichen Verzeichnis wie der COM-Server, wird der Programmlader dort fündig und verwendet auch diese, ist sie nicht dort, sucht er halt weiter.

Das ist ja auch die übliche Methode, um Standard-Dlls unterschiedlicher Version auf dem gleichen Rechner vorzuhalten: bei einer Applikation, die diese benutzt, legt man die Dll einfach ins Applikationsverzeichnis und kann sich sicher sein daß dann auch genau diese verwendet wird, bei einem COM-Server (In oder Out of process) erreicht man das gleiche, indem man die Dll, die der COM-Server verwendet und auch verwenden soll in das Verzeichnis des COM-Servers legt.

Die Frage ist: wieso funktioniert das nicht genauso einfach und problemlos, wenn man DirectCOM.dll verwendet und den Pfad zum COM-Server kennt und an GETINSTANCE übergibt? Ich meine: wo ist da der Unterschied? Im einen Fall wird der Pfad zum COM-Server aus der Registry geholt, im anderen Fall direkt angegeben. Pfad ist Pfad und das Ergebnis sollte in beiden Fällen das gleiche sein.

Und ich bekomme allmählich Bauchschmerzen wenn ich an COM-Server-Ketten denke, die sich vielleicht auch noch gegenseitig beziehen und reg free verwendet werden sollen. Da gibts wahrscheinlich noch Überraschungen.

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
.

Relevant Pages

  • Re: dhRichClient3-Toolset
    ... Das müßte doch in GETINSTANCE bemerkt worden sein ... ... Wenn ich die SQLite dll nicht preloade, ... Mehr Information als den Pfad zum COM-Server hat der ja auch nicht: beide Vorgehensweisen haben als Information nur den Pfad zum COM-Server. ... Deshalb funktioniert mein preload-Trick (preload aus der Applikation heraus, nicht aus dhRichClient3 heraus, dort funktioniert er nicht). ...
    (microsoft.public.de.vb)
  • Re: VFP 7 und XP 64bit
    ... Habe zwar unter meinem Account Admin Rechte. ... Ist dein Comserver eigentlich DLL oder EXE und wenn DLL, ... Deiner EXE, den COM-Server zu finden: ...
    (microsoft.public.de.fox)
  • COM Server <-> keine Konstruktoren?
    ... Ich versuche mit einer VS2005 Applikation auf einen "alten" COM-Server, ... Andere "Delphi - Applikationen" haben aber kein Problem, ... COM-Server zuzugreifen, folglich gehe ich davon aus, dass ich etwas verkehrt ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: ADO Jet-Provider unter XP64
    ... Die DLL muss leider x64 sein. ... Verwende *kein* Access (würde ich bvevorzugen!) ... Schreibe ein COM-Server, welche dann von der 64-Bit DLL angesprochen werden kann ...
    (microsoft.public.de.vc)
  • COM-Server oder DLL mit FoxPro
    ... Ich möchte mit einer VFP Anwendung auf Excel zugreifen. ... Dies Soll entweder über einen COM-Server erfolgen, oder per DLL. ...
    (microsoft.public.de.fox)