Delphi 2009 und Packages

[KEK]

Hallo Ihr Profis
müsst euch was wichtiges fragen.
Mir steht die Aufgabe zu, ein Delphi 7 (win32) Projekt unter Delphi 2009 zum laufen zu bekommen.
Ein prinzipielles Problem stellt sich dar.

Unsere Anwendung besteht aus mehreren Dateien...
der 'Start'-exe welche alle Grundfunktionen übernimmt , einer 'bpl' welche alle Typen deklariert und ein Objekt -welches alle übergreifende Variablen deklariert-, und mehrere 'dll's'.
Alle Teile (exe, dll mit eigenen formularaufruf, und auch code der bpl) nutzen das Objekt in der bpl sozusagen als globale Variable.
Dies funktioniert unter Delphi 7 auch sehr gut und es lässt sich das Programm dadurch auch prima warten und erweitern.

Dieses Prinzip scheint aber unter Delphi 2009 nicht mehr zu funktionieren.
Die Units welche die 'globalen Objekte' beinhalten werden in alle Programmteile kompiliert.
Die Angabe der bpl (wie D7) als Laufzeitpackages ändert daran nix.
Das Ergebnis ist logischerweise reines Chaos und die Programmteile 'reden' nicht mehr über die bpl miteinander.

Nun ist leider die Zeit sehr begrenzt um (für mich) forschungen ins 'blaue' zu wagen - drum hier mal die Bitte ob
ein Wissender mir meine Unwissendheit etwas veringert könnte :-)

Also: Warum verhält sich Delphi 2009 so anders wie Delphi 7 ? Und gibt es eventuell Kompilereinstellungen die unser altes Programm Model am leben lassen ?

Danke + Gruß + schönes WE Katrin

[Bernhard Geyer]

Werden alle Programmteile auch neu kompiliert? Mischung von BPL verschiedener Delphi-Versionen sind nicht möglich. Alles muss mit der gleichen Compilerversion+Patch-Level kompiliert sein. Verwenden die "DLL's" auch Laufzeitpackages und werden hier evtl. Strings übertagen (D7: String=Ansistring, D2009 String=Unicodestring).

Es wurde Grundsätzlich nichts geändert, da sonst auch die IDE nicht mehr funktionieren würde.

[KEK]

Hallo danke für die schnelle Antwort.
Es wird alles neu kompiliert - die DLL's sind auch rein Delphi - übergeben schon Strings aber werden nur vom Haupprogramm geladen.
exe , bpl und dll nutzen natürlich die Laufzeitb. von Delphi ansonst sind alle benöigten Objekte, Formerweiterungen, Datenmodule, etc. in die bpl eingebunden.

Was halt auffällt .. ich beschreib es noch einmal

bpl enthält unit x.pas .. wird dort ordentlich kompiliert.
exe verweißt auf objekt in x.pas kompiliert diese und linkt sie in die exe obwohl ja eigentlich nur der zeiger auf die bpl stehen müsste! Das das nicht gehen kann ist mir klar,
aber warum mach dies der D2009 Kompiler ?

die Quellen sind 1 : 1 von D7 übernommen (halt angepasst AnsiStr etc.) aber die Strktur ist nicht geändert

wär schön wenn du noch mal denken könntest -- mein delphi wiessen is da leider begrenzt

Gruß Katrin

[Bernhard Geyer]

Steht das Package von x.pas auch im Requires-Abschnitt der Exe/DLL/Package? Evtl. musste du diese Requires-Liste neu aufbauen/korrigieren.

[KEK]

Ja ist schon richtig eingetragen -- hät mich sonst nich getraut zu fragen.
Hab das Package auch neu aufgebaut :-(

Für mich unlogisch
hab auch noch ander Sachen die mir dato vollkommen wirr sind.
An der Stelle hab ich alles noch mal auf einen anderen Rechner gehauen mit XP x86.
Aber macht den gleichen Mist.

Vielleicht kommt einer noch auf ne Idee wenn ich das mal noch schreib.

D7 bringt bei GetVersionEx( osInfo ).. dwPlatformId ordentlich eine 2 .... D2009 ne 29 ???
Die MemoryData Klasse der RxLib macht aus einer Integerzuweisung prinzibiell '8Tausend nochwas'
also zB AppendRecord([1,1]) = FieldX.AsInteger = '8Tausend nochwas'
:wall: :wall: :wall:

Ich denk ... weiß nich mehr was ich denk -- Hilfe !

LG Katrin

[jbg]

Zitat:

Zitat von KEK

D7 bringt bei GetVersionEx( osInfo ).. dwPlatformId ordentlich eine 2 .... D2009 ne 29 ???

Also folgendes liefert mir unter Delphi 2009 den Wert 2.

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  osInfo: TOSVersionInfo;
begin
  osInfo.dwOSVersionInfoSize := SizeOf(osInfo);
  GetVersionEx( osInfo );
  ShowMessage(IntToStr(osInfo.dwPlatformId));
end;

Zitat:

Die MemoryData Klasse der RxLib macht aus einer Integerzuweisung prinzibiell '8Tausend nochwas'

Dann liegt dort vielleicht ein Fehler in der Migration der RxLib vor.


Kann es sein, dass irgend ein Komponenten-Package (beispielsweise RxLib) dir dein Delphi zerschießt?

[Muetze1]

Hast du in einem EXE Projekt das entsprechende Package auch als Runtime Package angegeben in den Projektoptionen? Wenn nicht, linkt er das direkt ein.

Ansonsten vllt. ein gewisses Problem mit den Konfigurationswerten in den Projektdateien, welche ignoriert werden? Ich weiss hierbei aber nicht, ob das Problem auch noch für D2009 besteht. Aber vllt. trotzdem mal die Environmentvariable "PLATFORM" überprüfen.

[KEK]

hallo
die laufzeit-package ist eingetragen. die exe startet auch nich, wenn es die bpl nich findet.

den anderen artikel hab ich mal schnell durchgelesen .. da bekomm ich ja bedenken !!
obwohl ich es ja auch schon auf 2 verschiedenen rechnern (mit vollkommen anderen Mainbord + CPU) mit xp, win2008 x86 u. x64 und auch auf win2008R2 porbiert es.
auf win2008r2 wird regelmäßig die pngfilt.dll angemeckter die bds stürzt ab.

werd den angaben im artikel nachgehen.

danke für die antwort - danke lg katrin

[KEK]

mal Nachtrag mit der Hoffnung auf Leser.


Die sehr wunderlichen Sachen haben wahrscheinlich doch ihren Ursprung in der RxLIB.
Nun hab ich nicht das Wissen es so zu debuggen, dass ich erkenne zB warum bei 2 absolut identischen kleinen Projekten einmal die
TRxMemoryData Komp. funktioniert, und einmal nicht.

Darum
Hat jemand eine Umsetzung der RxLIB auf D2009 (außer die gepatchte von Polaris Software die ich habe) ?
Komm ohne Vergleich a la try and error nicht weiter und vernichteStunde um Stunde.

Danke und Grüße Katrin

[Bernhard Geyer]

Die RxLib ist bestandteil von der Jedi VCL und dürfte dort schon übersetzt worden sein.

[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:

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:

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