![]() |
Temp-Ordner als Konstante vor Programmstart?
Hallo leute
ich habe da ein kleines Problem ich benutze in meinem Programm eine DLL die vorhanden sein muss wenn das Programm startet. Also kann ich sie auch nicht als resource hinzu fügen und dann zur laufzeit erzeugen. Eine lösung für das droppen habe ich schon gefunden. Ein anderes Tool schmeißt die benötigte dll in das TEMP-verzeichniss Nun könnt ihr euch vielleicht schon denken wo das problem liegt... Ich möchte das Verzeichniss des TEMP-Ordners als Konstante hinterlegen da er sonst die DLL nicht findet... mit "DLL_FILE = '%temp%\sqlite3.dll'" geht das leider nicht :-( Wie kann ich das realisieren? |
Re: Temp-Ordner als Konstante vor Programmstart?
Hallo,
das geht mit ![]() |
Re: Temp-Ordner als Konstante vor Programmstart?
nun, danke schonmal für die schnelle hilfe :-)
doch leider ist dieser aufruf schon zu spät... ich brauche eine fest hinterlegte konstante (wenn es so eine gibt) mit der man das TEMP-Verzeichniss ansprechen kann vielleicht gibt es da ja sowas... |
Re: Temp-Ordner als Konstante vor Programmstart?
Warum zu spät?
|
Re: Temp-Ordner als Konstante vor Programmstart?
Zitat:
Falls du sqlite3.dll statisch gebunden hast: Wieso lieferst du diese DLL nicht in deinem Anwendungverzeichnis mit? Oder baust deinen Zugriff nicht auf dynamische Bindung (oder bei D2010 auf delay loading) um? |
Re: Temp-Ordner als Konstante vor Programmstart?
Weil die DLL statisch gelinkt wird. Link die DLL dynamisch und füge sie als Ressource hinzu. Dann brauchst du auch nicht diesen komischen Dropper, der eventuell sogar als Virus erkannt wird.
|
Re: Temp-Ordner als Konstante vor Programmstart?
die Konstante wird hier geladen:
Delphi-Quellcode:
und hier ist wird die konstante verwendet:
const
{$IF Defined(MSWINDOWS)} SQLiteDLL = 'sqlite3.dll'; [...] [delphi] function SQLite3_Open(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl; external SQLiteDLL name 'sqlite3_open'; function SQLite3_Close(db: TSQLiteDB): integer; cdecl; external SQLiteDLL name 'sqlite3_close'; function SQLite3_Exec(db: TSQLiteDB; SQLStatement: PAnsiChar; CallbackPtr: TSQLiteExecCallback; UserData: Pointer; var ErrMsg: PAnsiChar): integer; cdecl; external SQLiteDLL name 'sqlite3_exec'; [delphi] nun, wie linke ich denn dynamisch? ja, als resource hinzu fügen kann ich, währe natürlich auch schön :-( aber leider habe ich keine ahnung wie ich "dynamisch linke" |
Re: Temp-Ordner als Konstante vor Programmstart?
Zitat:
Zitat:
![]() |
Re: Temp-Ordner als Konstante vor Programmstart?
gut, habe mir das mit dem dynamischen laden angeschaut...
einziges problem ist nur, das dort UNZÄHLIGE funktionen aufgerufen werden, die ich doch nicht alle so laden kann :wall: es ist leider ziemlich verzwickt... gibt es wirklich keine andere alternative??? :cry: |
Re: Temp-Ordner als Konstante vor Programmstart?
Nimm doch einen vorhandenen SQLite-Wrapper
|
Re: Temp-Ordner als Konstante vor Programmstart?
Zitat:
was soll das denn sein? ich google jetzt schon nen bisschen aber eine schlüssige erklärung hab ich noch nicht entdeckt |
Re: Temp-Ordner als Konstante vor Programmstart?
Ein Wrapper macht genau, das was du benötigst. Er macht Funktionen einer Dll als Prozeduren/Funktionen in Delphi nutzbar
|
Re: Temp-Ordner als Konstante vor Programmstart?
Zitat:
ahhhhh ^^ okay, dann gucke ich mal ob ich eine möglichkeit finde dieses ding zu benutzen... :pale: EDIT: ----------- Ich hab so das gefühl diese Wrapper liefern ja auch eine DLL mit die geladen werden wird -.- also bin ich wieder ganz am anfang angekommen... |
Re: Temp-Ordner als Konstante vor Programmstart?
Zitat:
Und ansonsten bleiben dir halt nur zwei Wege: Entweder der ganz normale, d.h. die DLL im Programmverzeichnis mitliefern wie es so gut wie alle Programme machen. Oder eben auch das Programm ins Tempverzeichnis entpacken. Das wäre eine Notlösung, nicht schön und nicht gut, aber funktioniert... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:14 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz