[DELPHI] - Owner in DLL

[bDaniele]

Salve,
sto scrivendo una dll in d7, il problema è questo: quando creo un istanza di una classe, quindi un oggetto, chi è l'owner?

in poche parole, quando faccio MyLabel:=TLabel.Create(??????)

(La creazione di 1 label è un esempio)

[bDaniele]

mi correggo:

ho questo codice nella mia dll,

function Descriz(const Minsan: ShortString) : ShortString;
var Prod : TTable;
begin
    Check(dbiInit(nil));
    Prod:=TTable.Create(nil);
    Prod.DatabaseName:='c:\';
    Prod.TableName:='Prodotti.dbf';
    Prod.Open;
    if Prod.Locate('MINSAN10',Minsan,[])
    then result:=Prod.FieldByName('Descriz').AsString;
    Prod.Free;
end;

sul rigo Prod.Open ottengo una violazione d'accesso: Ecception EDatabaseError in module MyDll.dll at 0000xxxx

qualcuno può aiutarmi.

[alka]

Per quanto riguarda l'Owner, puoi tranquillamente lasciarlo a nil, anzi devi siccome provvedi a distuggere autonomamente l'istanza di TTable richiamando il metodo Free, anche se io includerei il blocco tra la Create e la Free all'interno di un costrutto "try...finally".

Il problema che hai riscontrato potrebbe essere dovuto a qualche problema nell'accesso alla tabella; formalmente non vedo errori nel codice, pertanto la causa è da ricercarsi altrove.

Accertati che la prima unit elencata nella clausola uses del progetto sia "ShareMem"...

[bDaniele]

Ciao Marco, il try è un'abitudine oramai, ma l'ho risparmiato nel 3d per evitare qualche rigo.

ho risolto:
l'errore stava nel DataBaseName,in pratico il percorso che assegnavo non esistema.
Il messaggio d'errore potrebbe essere anche un pò più preciso in ogni modo ora tutto ok.

PS: chiunque dovesse scrivere dll con delphi, è fortemente consigliabile usare i pChar anzichè le string.

[alka]

Ciao Marco, il try è un'abitudine oramai, ma l'ho risparmiato nel 3d per evitare qualche rigo.

Immaginavo...

ho risolto:
l'errore stava nel DataBaseName,in pratico il percorso che assegnavo non esistema.
Il messaggio d'errore potrebbe essere anche un pò più preciso in ogni modo ora tutto ok.

Probabilmente manca la gestione delle eccezioni tipica delle applicazioni Delphi all'interno del modulo risultante dalla DLL, quindi i messaggi appaiono così come li hai visti e non con la classica visualizzazione del messaggio descrittivo.

PS: chiunque dovesse scrivere dll con delphi, è fortemente consigliabile usare i pChar anzichè le string.

Why???

[bDaniele]

Originariamente inviato da alka
PS: chiunque dovesse scrivere dll con delphi, è fortemente consigliabile usare i pChar anzichè le string.
Why???

Ho scritto una funzione con questo prototipo
function Encrypt(aParam : string) : string;

contenuta in una dll, quando vado ad usarla il pc si pianta e l'utilizzo di memoria cresce esponenzialmente.

se modifico il prototipo così:
function Encrypt(aParam : shortstring) : shortstring;

tutto ok!


Probabilmente i pChar migliorano ancora un pò il tutto in quanto viene allocato sullo stack solo il puntatore.

correggimi se sbaglio.

saluti.

[alka]

Nel codice che hai scritto non fai uso in alcun modo di PChar...non lo hai scritto nemmeno una volta.

L'unica considerazione che si deve fare riguardo alle stringhe è che esse sono memory managed: il "memory manager" di Delphi provvede alla loro allocazione e deallocazione in automatico a seconda delle esigenze e di quello che fa il codice; questo vale per le variabili di tipo string.

Questo tipo di variabili, infatti, è un puntatore ad un'area che contiene i dati relativi alla stringa memorizzati in un formato che comunque non deve essere tenuto in considerazione (cioè non ci si deve basare su di esso poichè potrebbe cambiare ad ogni versione di Delphi). Queste stringhe si possono "castare" a PChar e ci pensa Delphi a tramutarle in stringhe terminate dal carattere nullo per poterle passare ad una DLL di Windows o ad una DLL utente.

Il tipo shortstring è diverso, è solamente un array statico di caratteri, quindi non ha di questi problemi.

In breve, affinchè le stringhe vengano correttamente passate da un'applicazione ad una DLL usando il tipo autogestito string, è necessario includere come prima unit del progetto (clausola "uses" del DPR) "ShareMem", sia nell'applicazione sia nella DLL.

Se si usa shortstring, il problema non si pone (ma le stringhe possono avere al massimo 255 caratteri).