Delphi 2010 - TEdit PasswordChar = #0 Bug lässt Cursor verschwinden

[berens]

Hallo,
ich habe folgendes Problem unter Delphi:

Ich möchte, dass ein Edit-Feld, wenn es betreten wird das Passwort im Klartext anzeigt, und nach dem Verlassen wieder nur Sternchen. Soweit kein Problem.


Man nehme ein leeres Formular mit zwei TEdit, und weise OnEnter und OnExit jeweils zu:

Delphi-Quellcode:

unit Unit2;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm2 = class(TForm)
    Edit1: TEdit;
    Edit2: TEdit;
    procedure Edit1Enter(Sender: TObject);
    procedure Edit1Exit(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form2: TForm2;

implementation

{$R *.dfm}
{$R w7_ohneAdmin.res}

procedure TForm2.Edit1Enter(Sender: TObject);
begin
  (Sender as Tedit).PasswordChar := #0;
end;

procedure TForm2.Edit1Exit(Sender: TObject);
begin
  (Sender as Tedit).PasswordChar := '*';
end;

end.

Meines Wissens sollte auch in Delphi 2010 trotz Unicode etc. "#0" immer noch als "keine Sternchen sondern normalen Text anzeigen" gültig sein; ist ja auch der Standardwert im Objektinspektor.

Startet man nun das Programm (man kann in beiden Editfeldern beliebig eintippen, man sieht den Cursor, alles ganz normal) und wechselt das zweite Mal in das selbe Edit, sieht man keinen Cursor mehr! Man kann zwar tippen, löschen, nach links uns rechts gehen (mit einem unsichtbaren Cursor!) etc., aber man sieht ihn halt nicht mehr. Auch nach erneutem hin- und herwechseln oder Maus-anklicken bekommt man ihn nicht mehr sichtbar...

Kennt jemand das Problem, bzw. kann das jemand mit Delphi 2010 nachvollziehen? Problem von Delphi, oder mache ich was falsch?



Embarcadero® Delphi® 2010 Version 14.0.3593.25826 incl. Update 5

[jaenicke]

In neueren Versionen von Delphi funktioniert das korrekt so.

[Glados]

Zitat von jaenicke:

In neueren Versionen von Delphi funktioniert das korrekt so.

Ich habe das gerade in Tokyo (ohne Update 1) in einem bestehenden, umfangreichen Projekt getestet: funktioniert nicht.
In einem frischen Projekt funktioniert es ebenfalls nicht.

Windows 7, Delphi Tokyo ohne Update 1: kein Cursor im Edit nach zweitem Enter.

[jaenicke]

Oh stimmt, ich hatte es nicht in OnEnter drin, das ist auch das Problem.

Einfacher Workaround:

Delphi-Quellcode:

const
  WM_ENTERED = WM_APP + 1292;

type
  TForm21 = class(TForm)
    Edit1: TEdit;
    Edit2: TEdit;
    procedure Edit1Enter(Sender: TObject);
    procedure Edit1Exit(Sender: TObject);
  protected
    procedure WMENTERED(var Message: TMessage); message WM_ENTERED;
  end;

var
  Form21: TForm21;

implementation

{$R *.dfm}

procedure TForm21.Edit1Enter(Sender: TObject);
begin
  PostMessage(Handle, WM_ENTERED, NativeUInt(Pointer(Sender)), 0);
end;

procedure TForm21.Edit1Exit(Sender: TObject);
begin
  (Sender as TEdit).PasswordChar := '*';
end;

procedure TForm21.WMENTERED(var Message: TMessage);
begin
  TEdit(Message.WParam).PasswordChar := #0;
end;

// EDIT:
Ach so:
Hintergrund ist, dass durch das Vorgehen im OnEnter das Handle des Editfenster zerstört und neu erzeugt wird. Mit dem Postmessage passiert das erst danach.

[Uwe Raabe]

Ich kann den Fehler hier auch bei dem neuesten Tokyo bestätigen.

Das habe ich auf die Schnelle als Workaround dazu gefunden: set TEdit.PasswordChar property in TEdit.onEnter event causes TEdit can not show selection and cursor in Delphi XE seattle.

Einen passenden QP-Eintrag suche ich allerdings noch vergebens.

[berens]

Danke für die Beiträge und die Lösung von jaenicke, das sieht durchaus sehr professionell aus, auch die Info mit dem zerstörten Handle hat mir weitergeholfen.

Unter Delphi 2010 stellt sich das nun wie folgt da: beim zweiten Betreten erscheint das Feld nun komplett "leer", das Programm friert kurz ein, und danach flimmert sich der Cursor am Anfang des leeren Edit-Feldes einen ab... Funktioniert bei mir also leider nicht.

Ich habe mir erlaubt, in Anbetracht dessen, dass es wohl ein grundlegenderes Problem von Delphi oder Windows ist/sei könnte, eine Quick-and-Dirty-Lösung zu basteln, da für eine so unbedeutende Funktion mit so großen Problemen eine schnelle unkomplizierte Lösung für mich sinnvoller ist, als die Ursache zu beheben (die evtl. in Windows oder Delphi liegt, und sich eh meinem Zugriff entzieht)...

Delphi-Quellcode:

procedure TForm2.edtPasswordEnter(Sender: TObject);
begin
  Timer1.Tag := 1;
  Timer1.Enabled := True;
end;

procedure TForm2.edtPasswordExit(Sender: TObject);
begin
  Timer1.Tag := 0;
  Timer1.Enabled := True;
end;

procedure TForm2.Timer1Timer(Sender: TObject);
begin
  // Der Timer hat ein Interval von 10 ms
  Timer1.Enabled := False;
  if Timer1.Tag = 0 then begin
    edtPassword.PasswordChar := '*';
  end else begin
    edtPassword.PasswordChar := #0;
  end;
end;

Beim Betreten oder Verlassen des Edit-Feldes löse aktiviere ich nun den Timer. Je nachdem ob der Text sichtbar (1) oder unsichtbar/verschlüsselt (0) sein soll, erhält der Timer einen anderen Tag. Der Timer ändert dann den Passwordchar, da nach ~10ms davon auszugehen ist, dass das Handle vom TEdit korrekt freigegeben und neu erzeugt wurde, so dass der jetzige Befehl problemlos klappen sollte.



Edit:
Die von Uwa Raabe verlinkte Lösung funktioniert scheinbar auch zuverlässig:

Delphi-Quellcode:

procedure TForm2.edtPasswordEnter(Sender: TObject);
begin
  SendMessage(edtPassword.Handle, EM_SETPASSWORDCHAR, 0, 0);
end;

procedure TForm2.edtPasswordExit(Sender: TObject);
begin
  SendMessage(edtPassword.Handle, EM_SETPASSWORDCHAR, Ord('*'), 0);
end;

Edit2: Lösung scheint zuverlässig zu funktionieren. Bitte beachten: Neuere Windows-Versionen verwenden -trotz "*" als PasswordChar- den gefüllten Kreis "●". Das sieht natürlich komisch aus, wenn man das Programm startet, das Passwort steht in ● da, man klickt rein, verlässt es wieder, und da stehen *... Ich habe jetzt mal im Objektinspektor den PasswordChar direkt auf "●" gesetzt, und bei OnEditExit nun Ord('●') stehen, damit auf jeden Fall durchgehend das selbe Zeichen drin steht.

[Glados]

Zitat:

Ich kann den Fehler hier auch bei dem neuesten Tokyo bestätigen.

Ist es denn wirklich ein Fehler oder ist es sogar so gewollt (das sich zerstörende Handle)?

Zitat:

if Timer1.Tag = 0 then begin

Das Tag des Timers zu setzen und auszulesen, nenne ich mal einen wahren Workaround. Quick&Dirty

[Uwe Raabe]

Zitat von Glados:

Zitat:

Ich kann den Fehler hier auch bei dem neuesten Tokyo bestätigen.

Ist es denn wirklich ein Fehler oder ist es sogar so gewollt (das sich zerstörende Handle)?

Das kann ich auch nicht sagen. Ich hoffe mal, jemand hat sich was dabei gedacht, als er für Delphi 2009 den Code in SetPasswordChar geändert hat.