wparam bei PostMessage in 64-Bit-Windows

[DelphiKlaus]

Hallo,

ich habe ein Problem bei einem mit Delphi 6 erstellten 32-Bit-Programm.

Ich schicke in diesem Programm aus dem Hauptfenster mit Postmessage eine Nachricht an genau dasselbe Hauptfenster, damit die Bearbeitung dieser Nachricht erst nach dem kompletten Erstellen des Fensters erfolgt. Das funktioniert nun auch schon seit Jahren einwandfrei unter 32-Bit Windows 7. Jetzt habe ich das Programm mal von einem Bekannten unter einer 64-Bit Windows 7-Version starten lassen. Da funktioniert das Postmessage nicht richtig. Der als wparam übergebene Wert kommt nicht an. Zwar ist wparam in 32-Bit-Versionen von Windows 7 ein 32-Bit-Wert, und unter 64-Bit-Versionen ein 64-Bit-Wert. Aber das dürfte doch nichts ausmachen. Ich kann halt in einem 32-Bit-Programm nur die unteren 32-Bit nutzen, und mehr will ich auch gar nicht. Ich kann ja auch in Delphi 6 nur einen 32-Bit-Wert übergeben, da wparam als longint definiert ist.

Ich konnte das Problem jetzt erstmal durch den Einsatz einer globalen Variablen umgehen; aber schön ist die Lösung nicht. Weiss jemand, wo ich genauere Informationen zu Postmessage einer 32-Bit-Anwendung in einem 64-Bit-Windows bekomme? Ich hab leider bisher keine Antwort zu meinem Problem gefunden.

Viele Grüße

Klaus

[himitsu]

Es ist und bleibt eine 32-Bit-Anwendung, auch wenn die in einem 64-Bit-Windows läuft (wobei sie ja in Wirklichkeit im WOW64 läuft)
und demnach bleibt auch WParam 32 Bit, da alles in der Anwendung immernoch 32 Bit ist und auch die 32 Bit-APIs genutzt werden.

[DelphiKlaus]

Danke für die schnelle Antwort.

Genauso dachte ich auch. Aber der als wparam übergebene Wert kommt definitiv nicht an. Ich übergebe keine Adresse, sondern den Wert direkt. Sollte eigentlich kein Problem sein.

[Sherlock]

Das einzige, das mir in Sachen wParam in der Vergangenheit Ungemach bereitete, war die Umdeklaration des wParam von INT_PTR nach UINT_PTR in XE2 (eventuell auch vorher, aber ich bin von 2007 nach XE2 "gesprungen"). Allerdings steht da, Du hättest Delphi 6...also keine Gefahr von der Richtung.

Sherlock

[jaenicke]

Ich wüsste zwar auch nicht was dabei schief laufen könnte, aber es hört sich so an als ob das sehr einfach in einem kleinen Testprogramm nachstellbar sein sollte, oder?
Das könntest du dann nämlich einfach hier anhängen. Das würde sicher am schnellsten Erkenntnisse bringen.

[Der schöne Günther]

Ich bin da jetzt kein Guru, aber ich hätte doch mal getippt, dass eher an der Message (ihrem Inhalt) selber statt

Delphi-Quellcode:

PostMessage(..)

an sich liegt: Nicht dass die Gegenseite ein 64 Bit-Prozess ist und in den Daten etwas anderes erwartet als verschickt wird?

Oder ist das dumm?

[jaenicke]

Das kann ja nicht sein, denn er hat ja geschrieben, dass er die Message an sich selbst schickt.

(Das ist eine typische Methode um etwas direkt nach der ersten Anzeige des Formulars auszuführen. Besser als der Quatsch mit OnActivate oder einem Timer, der auch manchmal dafür benutzt wird.)

[DelphiKlaus]

Vielen Dank für die Antworten.

Ich vermute mittlerweile, dass die Ursache eine andere ist. Die ist mir dann aber auch nicht verständlicher. Ich zeig mal einen Ausschnitt aus dem Code:

Delphi-Quellcode:

    procedure wmPasswortDialog            (var Message_vb         : TMessage); message wm_PasswortDialog;


procedure TFormPasswort_dd.FormCreate (Sender : TObject);

begin 
  Inherited;

  if FileExists (ChangeFileExt (Application.ExeName, '.Tresor')) then
    begin
      PasswortAnforderung := dtPasswortBestaetigen;

      ...
      ...
    end
  else
    PasswortAnforderung := dtPasswortDefinieren
end;

procedure TFormPasswort_dd.FormShow (Sender : TObject);

begin 
  Inherited;

  ...
  ...

  PostMessage (Self.Handle,
               wm_PasswortDialog,
               PasswortAnforderung,
               0)
end;

procedure TFormPasswort_dd.wmPasswortDialog (var Message_vb : TMessage);

begin
  if Message_vb.wParam ...... then

  ...
  ...
end;

In FormCreate wird die Variable PasswortAnforderung gesetzt, in FormShow wird sie mit PostMessage weitergeleitet und in wmPasswortDialog kommt sie nicht an. Deshalb hatte ich erstmal den Verdacht, dass es am PostMessage liegt.

Aber könnte es sein, dass die FormShow-Methode schon durch das Inherited im FormCreate aufgerufen wird. Dann wäre die Variable PasswortAnforderung natürlich noch nicht definiert. Nur wäre mir dann nicht klar, wieso bei einem 32-Bit-Windows FormCreate und FormShow nacheinander ablaufen, bei einem 64-Bit-Windows dahingegen das FormShow schon ablaufen sollte, bevor das FormCreate komplett abgearbeitet ist.

Ich hab das Programm mal auf die wesentlichen Teile reduziert und mit ShowMessages die einzelnen Aktionen ausgegeben. Als Ausgaben kommen jetzt bei mir:

- FormCreate startet
- FormCreate nach Inherited
- FormCreate: PasswortAnforderung := dtPasswortDefinieren
- FormCreate endet
- FormShow startet
- FormShow sendet mit PostMessage
- wmPasswortDialog 1
- FormShow endet

Das ist das, was ich erwartet hatte.

Ich habe das Testprogramm (Quellen und Exe-File) als Zip-Datei angehängt. Vielleicht kann das mal jemand unter einem 64-Bit-Windows ausprobieren und gucken, ob die Meldungen in der gleichen Reihenfolge erscheinen.

Vielen Dank schon mal

Klaus

[himitsu]

Wenn in der DFM das Visible auf True steht, dann könnte man zwar vermuten, daß die Form bereits im Create sichtbar wird, aber (ich glaub) bei aktuelleren delphis wird die Sichtbarkeit gemerkt (Visible geht nicht direkt an die Sichtbarkeit weiter) und erst nachher wird der gespeicherte Visible-Wert (TFormState: fsVisible) richtig gesetzt.

Achtung: OldCreateOrder beeinflusst das Verhalten (ich weiß aber nicht wann das umgebaut wurde und seit wann es somit diese Option gibt)


Inherited: Es handelt sich hier doch um das TForm.OnCreate-Event?
Wenn ja, dann macht inherited dort rein garnichts.
(außer es gibt im Vorfahren eine Methode, welche ebenfalls "FormShow" heißt ... z.B. bei abgeleiteten Forms, wo man im Vorfahren die Events nutzte, anstatt die Methoden zu überschreiben)

[Sherlock]

Windows 8.1 x64 machts so wie Du es erwartest.

Sherlock