Newsgroup: it.comp.lang.delphi
Titolo: nascondere libreria nelle risorse

Ho capito che non è possibile inglobare una libreria nell'eseguibile
come fosse una risorsa da rilasciare (nella directory dell'eseguibile)
a seconda delle necessità.
Durante l'avvio dell'eseguibile ho l'errore di libreria non trovata
(anche se non la utilizzo in fase iniziale), evidentemente cerca le
risorse esterne durante l'avvio.
Esiste un "metodo" in cui dire al programma di non cercare la libreria
durante il suo avvio ?
In pratica ho, all'interno dell'eseguibile, alcuni file.exe che,
quando mi occorrono, estraggo dall'eseguibile, utilizzo e
successivamente cancello. Vorrei fare lo stesso con un file.dll anche
se già mi aspetto che sia di difficle realizzazione.

 ha scritto nel messaggio 
news:1171019507.9...@v45g2000cwv.googlegroups.com...



Puoi farlo caricando la libreria in modo statico (credo si dica cosi') col 
LoadLibrary. Cerca con google che trovi di sicuro qualcosa,
Giorgio 

 se già mi aspetto che sia di difficle realizzazione.
Possibile.  Vedi sopra.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Sto sbagliando postando qualcosa di NON testato ... ma mi appresto a
farlo subito :) ... e mi auguro sia di utilità ai posteri ;)
Grazie per le informazioni.
ecco qui:
Small example.
Imagine that you have a dll with ExecScript procedure which have two
parameters (UserID and ScriptName).
In static method you must declare a function as:
procedure ExecScript(UserID: Integer; ScriptName: PChar); stdcall;
far; external 'yourDLLName.DLL';
and in the code you can call it as:
ExecScript(5, 'LogToSystem');
and it's all.
For dynamic mechanism you must:
 {define a procedure type with required parameters of your procedure
in the DLL}
 type
   TDLLFunc = procedure(param1: Integer; param2: PChar);
 {assign a nil - not loaded function}
 const
   DLLFunc: TDLLFunc = nil;
 {handle of loaded dll}
 var
  DLLHandle: THandle;
 { load a library }
 DLLHandle := LoadLibrary(DLLName);
 if (DLLHandle < HINSTANCE_ERROR) then
     raise Exception.Create(DLLName + ' library can not be loaded or
not found. ' + SysErrorMessage(GetLastError));
   try
     { load an address of required procedure}
     @DLLFunc := GetProcAddress(DLLHandle, 'ExecScript');
     {if procedure is found in the dll}
     if Assigned(DLLFunc) then
       DLLFunc(5, 'LogToSystem');
   finally
     {unload a library}
     FreeLibrary(DLLHandle);
   end;

forse ho risolto con un sistema stupido quanto funzionale
purtroppo non posso testare fino in fondo il funzionamento non avendo
la periferica sotto mano :(
dato che ho un file.pas con l'elenco delle function di chiamata alla
libreria mi è bastato correggere:
function FUNZIONE(BaudRate: integer): integer; stdcall; external
'libreria.dll';
con
function FUNZIONE(BaudRate: integer): integer; {$IFDEF WIN32} stdcall;
{$ENDIF} external 'libreria.dll';
magari devo aggiungere una verifica sulla presenza o meno della
libreria.dll ... ma dato che sono io a "estrarla" durante il
funzionamento del programma ... verificherei solo se faccio errori ;)

per dovere di cronaca ho risolto il tutto ...
solo che bisogna utilizzare entrambi i sistemi
in pratica aggiungere {$IFDEF WIN32} stdcall; {$ENDIF}"
alla definizione della funzione descritta nel primo sistema:
TDLLFunc = procedure(param1: Integer; param2: PChar);
diventa
TDLLFunc = procedure(param1: Integer; param2: PChar);  {$IFDEF WIN32}
stdcall; {$ENDIF}
avevo perso quasi ogni speranza quando mi è venuto di "provare" questa
aggiunta
non capisco perche senza " {$IFDEF WIN32} stdcall; {$ENDIF}" il tutto
funzionava ma, il ritorno delle funzioni chiamate nella DLL, erano
falsati (nel senso che non corrispondevano ai valori delle chiamate
reali)

 reali)
E' ovvio, la clausola stdcall stabilisce l'ordine in cui vanno passati i
parametri sullo stack, per quella specifica funzione.  In ogni caso, puoi
elminare l'ifdef se compili su Win32.


quindi era la mancanza di "stdcall" a causare il problema
dell'incongruenza dei dati
compilo su XP quindi proverò ad eliminare l'ifdef ...
mi viene a mente quello che scriveva qualcuno riguardo il "funziona e
non so perchè ... so perchè ma non funziona" o qualcosa del genere ;)
la cosa importante è che ogni giorno imparo qualcosa di più :)
adesso stò impazzendo per capire a fondo il TbyteDynArray (più che
come funziona ... come viene utilizzato nella libreria che stò
utilizzando)

 non so perchè ... so perchè ma non funziona" o qualcosa del genere ;)
Io lo trovo deprimente.  Se ci si impegnasse a studiare di più, forse si
capirebbero anche i "perché".


l'unica cosa che ho trovato "deprimente" fino ad ora è l'help in linea
di turbo delphi ;)
la cosa che mi manca di più sono i codici di esempio esplicativi ...
leggere la funzione e basta mi costringe ad andare a tentoni e/o
meglio su google (quando posso)
decisamente un altro pianeta: Wordware.Publishing.Inside.Delphi.
2006.Nov.2005.INTERNAL-BBL
IMHO (è so che probabilmente sbaglio) ho dato una "studiata" alle cose
basilari e poi mi sono buttato nella realizzazione dl mio primo
programma, studiando ed imparando, quello di cui ho bisogno man mano
che mi si presenta il problema d'avanti (per il mio carattere funziona
solo se faccio così ... altrimenti mi annoio e finisco con il lasciar
perdere)
dicevo che probabilmente sbaglio dato che ci si rende conto in ritardo
che, aumentando la complessità del programma, si sarebbero potute
utilizzare altre strade (vedi quando ho deciso di cambiare tutto il
sorgente dall'utilizzo di un singolo Form, con vari TPageControl,
all'utilizzo di Frame)
comunque sono d'accordo sul fatto che "trovare" una soluzione al
problema e non riuscire a capirne il motivo lascia l'amaro in bocca
(apro un'altra Discussione su di un argomento "amaro" di questa
mattina)

 meglio su google (quando posso)
Sě, al momento del passaggio al nuovo formato della documentazione 
(adottato per consentire l'integrazione dell'help Win32/.NET Borland e 
Microsoft in un'unico luogo) si sono perse cose piccole ma fondamentali 
come gli esempi che, comprendo bene, possono rendere piů difficile la 
vita di chi si trova ad apprendere Delphi.
Pare che CodeGear si sia data da fare con diverse assunzioni mirate 
proprio a questo frangente, quindi confido che la prossima versione 
recuperi il "gap".
"Cross your fingers..." ;-)
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)