Delphi 2009 und Packages

[KEK]

wie ist denn das Gegenstück zu TRxMemoryDate bei der JEDI VCL ... würde mir sehr helfen

lg katrin

[jbg]

Ich würde es mit TJvMemoryDataSet (Unit JvMemoryDataset.pas) probieren.

[KEK]

Erst mal vielen Dank für die Hilfe.

Hab mit viel Aufwand Zwischenklassen für die JEDI geschrieben und teileweise auf einiges austauschen müssen.
Im Groben schon sehr aufwendig das Umsetzen..

Es gibt auch einige Unwegbarkeiten die sich mir nicht erschließen.
Dazu gehört ZB.
Meine eigene MAPI Implementation wollte auch nicht mehr (auch für mich unlogisch .. da ja nix mit Delphi zu tun)
Also hab ich die von JEDI versucht.
Die Funktionen der TJvMail können aber nicht von einem MDIForm aus aufgerufen werden !
Böse Zugriffsfehler (oder verstümmelte Übergaben) sind das Resultat.
Das erst einmal zu finden und nachzutellen ist seeehr zeitraubend ...

Vielleicht hat jemand ja dies schon mal nachvollzogen .. und hilft mir .. so käm ich wieder ein kleines Stück weiter.

Danke
LG Katrin

[jbg]

Zitat von KEK:

Meine eigene MAPI Implementation wollte auch nicht mehr (auch für mich unlogisch .. da ja nix mit Delphi zu tun)

Die MAPI nutzt ANSI-Strings. Mit der Umstellung auf Delphi 2009 ist aber "PChar" und "string" nun "PWideChar" und "UnicodeString". Wenn also die API-Funktionen mit PChar deklariert wurden, dann liegt darin der Fehler.

Zitat:

Also hab ich die von JEDI versucht.
Die Funktionen der TJvMail können aber nicht von einem MDIForm aus aufgerufen werden !
Böse Zugriffsfehler (oder verstümmelte Übergaben) sind das Resultat.

Da hat der Entwickler, der JvMail nach Unicode migriert hat wohl vergessen, dass in einer Schleife die temporären AnsiString Variablen, die der Compiler für den Typecast anlegt, beim nächten Schleifendurchlauf wieder überschrieben werden und somit der bereits in die MAPI übertragene Zeiger auf den AnsiString ungültig wird. Under Delphi 2007 (ANSI) funktioniert der alte Code, weil keine temporären string angelegt werden.

Ich habe den JvMail Code dahingehend gerade ausgebessert.
http://jvcl.svn.sourceforge.net/view...l.pas?view=log

[KEK]

DANKE

Frage -- wo ist der Unterschied ?

FBodyText := Body.Text;
AnsiSubject := AnsiString(FSubject);
AnsiBody := AnsiString(FBodyText);

FillChar(FMapiMessage, SizeOf(FMapiMessage), #0);
FMapiMessage.lpszSubject := PAnsiChar(AnsiSubject);
FMapiMessage.lpszNoteText := PAnsiChar(AnsiBody);
FMapiMessage.lpRecips := PMapiRecipDesc(FRecipArray);
FMapiMessage.nRecipCount := Length(FRecipArray);
FMapiMessage.lpFiles := PMapiFileDesc(FAttachArray);
FMapiMessage.nFileCount := Length(FAttachArray);

/////// alt
FMapiMessage.lpszSubject := PAnsiChar(AnsiString(FSubject));
FMapiMessage.lpszNoteText := PAnsiChar(AnsiString(FBodyText));
FMapiMessage.lpRecips := PMapiRecipDesc(FRecipArray);
FMapiMessage.nRecipCount := Length(FRecipArray);
FMapiMessage.lpFiles := PMapiFileDesc(FAttachArray);
FMapiMessage.nFileCount := Length(FAttachArray);

auch in CreateRecips kann ich keinen wirklichen Unterschied sehen
wäre interessant für mich

folgendes ergebnis mit neuer JvMail

JVCL Mailtestprogramm in

JEDI Mail + D2009
IDE ausgeführt folgender Fehler http://www.bwc-net.de/aufzeichnung.jpg
Solo-Exe (keine bpl) > Vista, Win 2003, Win2008 + OL2003 o.2007 = General MAPI Fehler
Solo-Exe (keine bpl) > Win2008R2, Win 7+ 2007 = wahlweise mal so mal so General MAPI Fehler oder Zugriffsfehler(Absturz komplett)
Solo-Exe (keine bpl) > Win2003, WinXP + OExpress = geht
Solo-Exe (keine bpl) > Vista, Win2008 + WindowsMail = geht zu 95% spontan General MAPI Fehler

Meine MAPI Umsetzung mit D7
Solo oder bpl > winXP - win7/win2008R2 + OL2003/2007 = geht
Solo oder bpl > win7/win2008R2 + WindowsMail = Fehler keine MAPI gefunden

JEDI Mail mit D7
Solo oder bpl > winXP - win7/win2008R2 + OL2003/2007 = geht
Solo oder bpl > win7/win2008R2 + WindowsMail = Zugriffsfehler(Absturz komplett)

Da die D2009 IDE auch sehr oft einfach (für mich ohne Grund) einfach Fehler produziert und ich mir nach 6 Tagen Test nicht sicher
sein kann, dass noch weitere (für mich) nicht erkennbare Fehler auftreten werden bei der Umsetzung,
werd ich morgen mein altes D7 wieder flott machen.
Chefchen wird sich freuen .. so viele Euronen (hab Codegear nich mehr lieb) ... na dann

Viele dank noch mal für die Hilfe
LG Katrin

[jbg]

Zitat von KEK:

Frage -- wo ist der Unterschied ?

Delphi-Quellcode:

    FBodyText := Body.Text;
    AnsiSubject := AnsiString(FSubject);
    AnsiBody :=    AnsiString(FBodyText);

    FillChar(FMapiMessage, SizeOf(FMapiMessage), #0);
    FMapiMessage.lpszSubject :=  PAnsiChar(AnsiSubject);
    FMapiMessage.lpszNoteText := PAnsiChar(AnsiBody);
    FMapiMessage.lpRecips :=     PMapiRecipDesc(FRecipArray);
    FMapiMessage.nRecipCount :=  Length(FRecipArray);
    FMapiMessage.lpFiles :=      PMapiFileDesc(FAttachArray);
    FMapiMessage.nFileCount :=   Length(FAttachArray);

///////  alt
    FMapiMessage.lpszSubject :=  PAnsiChar(AnsiString(FSubject));
    FMapiMessage.lpszNoteText := PAnsiChar(AnsiString(FBodyText));
    FMapiMessage.lpRecips :=     PMapiRecipDesc(FRecipArray);
    FMapiMessage.nRecipCount :=  Length(FRecipArray);
    FMapiMessage.lpFiles :=      PMapiFileDesc(FAttachArray);
    FMapiMessage.nFileCount :=   Length(FAttachArray);

Es gibt hier keinen.

Zitat:

auch in CreateRecips kann ich keinen wirklichen Unterschied sehen

In CreateRecips gibt es einen Unterschied. Und zwar ist hier eine Schleife im Spiel. Ein "PAnsiChar(AnsiString(S))" führt dazu, dass der Compiler eine temporäre AnsiString Variable (auf dem Stack) anlegt. Der PAnsiChar zeigt dann auf diesen AnsiString und so tut lpszAddress. Beim nächten Schleifendurchlauf wird diese temporäre Variable erneut benutzt und enthält nun einen anderen String. Dummerweise zeigt lpszAddress des vorherigen Array-Elements bereits auf den alten String der nun nicht mehr existiert.

[KEK]

Stimmt .. manchmal sieht man nix obwohl man die Augen auf hat.

LG + schönen Tag