ShlObj -> PickIconDlg() - merkwürdiges Verhalten

[Dalai]

Delphi-Quellcode:

   IconFile := '';
[...]
   if ( PickIconDialog( Handle, IconFile, IconIndex ) = True ) then

Das IconFile ist immer ein Leerstring. Zudem definiert PickIconDlg den Parameter pszIconPath als InOut (nicht direkt, aber durch die Beschreibung wird es klar). Das dürfte aber in Verbindung mit dem Cast nach PWideChar Probleme geben.

Grüße
Dalai

PS: Bitte nie auf = True vergleichen!

[KodeZwerg]

Ich habe von HolgerX eine sehr gut funktionierende Lösung erhalten.

Hier die Funktion:

Delphi-Quellcode:

  function PickIconDialog(var Filename: WideString; var IconIndex: Integer ): Boolean;

implementation

function _PickIconDlg(AHwnd : HWND; pszIconPath : PWideString; cchIconPath : DWORD; var piIconIndex : integer):integer; stdcall; external 'Shell32.dll' name 'PickIconDlg';

function PickIconDialog(var Filename: WideString; var IconIndex: Integer ): Boolean;
var
  tmp : Array[0..MAX_PATH-1] of WideChar;  // Min Size of pszIconPath must be MAX_PATH
begin
  Result := False;
  FillChar(tmp[0], MAX_PATH * SizeOf(WideChar),0);
  Move(FileName[1],tmp[0],Length(FileName)* SizeOf(WideChar));
  if (_PickIconDlg( 0, @tmp[0], MAX_PATH, IconIndex ) <> 0 ) then
  begin
    Filename := Widestring(tmp);
    Result := True;
  end;
end;

Hier der Aufruf:

Delphi-Quellcode:

procedure TfrmMain.btnGetIconClick(Sender: TObject);
var
  IconFile: WideString;
  IconIndex: Integer;
begin
  IconFile := '';
  IconIndex := 0;
  if edIconLocation.Text <> '' then
    IconFile := edIconLocation.Text;
  try
    IconIndex := StrToInt( edIconIndex.Text );
  except
    IconIndex := 0;
  end;
  if ( PickIconDialog( IconFile, IconIndex ) = True ) then
    begin
      edIconLocation.Text := IconFile;
      try
        edIconIndex.Text := IntToStr( IconIndex );
      except
        edIconIndex.Text := '0';
      end;
      Image1.Picture.Icon.Handle := ExtractIcon( hInstance, PWideChar( IconFile ), Cardinal( IconIndex ) );
    end;
end;

Zeile Image1.Picture.Icon.Handle funktioniert nur wenn vorher bereits ein Icon drinnen liegt (tut es in meinem Fall)
Falls eins fehlt, per TIcon eins zur Laufzeit generieren, Image1.Picture.Assign() glaub ich wars und dann TIcon löschen.

edIconLocation und edIconIndex ist jeweils ein Edit-Feld mit einem Dateinamen und Index-Wert.
Wenn ich es wie oben beschrieben Aufrufe zeigt mir der Dialog nun alles brav an und zwängt sich nicht mehr ungewollt woanders rein (also der Filename Rückgabe-Wert).

Hier der Original Auszug aus meiner ShlObj.pas:

Delphi-Quellcode:

function PickIconDlg(hwnd: HWND; pszIconPath: LPWSTR; cchIconPath: UINT; 
  var piIconIndex: Integer): Integer; stdcall;

implementation

function PickIconDlg;                             external shell32 name 'PickIconDlg' delayed;

Vielen Dank!

[KodeZwerg]

Zitat von Dalai:

Delphi-Quellcode:

   IconFile := '';
[...]
   if ( PickIconDialog( Handle, IconFile, IconIndex ) = True ) then

Das IconFile ist immer ein Leerstring. Zudem definiert PickIconDlg den Parameter pszIconPath als InOut (nicht direkt, aber durch die Beschreibung wird es klar). Das dürfte aber in Verbindung mit dem Cast nach PWideChar Probleme geben.

Grüße
Dalai

PS: Bitte nie auf = True vergleichen!

Ich habe im Editor vieles rausgeschnippselt ums aufs wesentliche zu reduzieren, IconFile war auch oben drin mit Edit-Feld zuweisung, sorry ist dem reißwolf vorgeworfen worden.
  if not ( PickIconDialog( IconFile, IconIndex ) = False ) then *updated*

Dankeschön!

[Dalai]

Zitat von KodeZwerg:

[...] sorry ist dem reißwolf vorgeworfen worden.

Achso, alles klar .

Zitat:

  if not ( PickIconDialog( IconFile, IconIndex ) = False ) then *updated*

Ne, so meinte ich das nicht. Es geht mir nicht um die Invertierung des Vergleichs sondern nur um den direkten Vergleich mit True. Besser ist es, das = True wegzulassen, also so if PickIconDialog( IconFile, IconIndex ) then [...] .

Grüße
Dalai

[KodeZwerg]

Achso meinst Du das. Ich Vergleiche meist alles mit was bestimmten (wenn ich Wert selbst gesetzt habe). Mir ist bekannt das idR nur False = 0 (oder -1 oder höchst möglicher negativwert) hat und True alles darüber aber was kann passieren wenn ich innerhalb Delphi funktionen wo ich selbst ein Delphi True oder Delphi False setze und später auf eben dieses kontrolliere ?

Wenn in aufgerufener funktion als result true gesetzt wird, unter was für Umständen ist es kein True?

Beispiel:

Delphi-Quellcode:

function IsTrueReallyTrueOrDoesItFoolMe: Boolean;
begin
  Result := True;
end;

[EWeiss]

Zitat:

Wenn in aufgerufener funktion als result true gesetzt wird, unter was für Umständen ist es kein True?

Weil eine solche Übergabe schlichtweg unsinnig ist.
Ohne das vorher irgendein vergleich stattfindet.

Ja ich weis ist nur ein Beispiel.. aber trotzdem.

gruss

[Alter Mann]

Code:

Returns 1 if successful; otherwise, 0.

[EWeiss]

Zitat von Alter Mann:

Code:

Returns 1 if successful; otherwise, 0.

Kann ja nicht stimmen die Funktion liefert immer 1 zurück somit hinkt dein vergleich. "Ohne das vorher irgendein vergleich stattfindet."

gruss

[KodeZwerg]

Zitat von EWeiss:

Zitat:

Wenn in aufgerufener funktion als result true gesetzt wird, unter was für Umständen ist es kein True?

Weil eine solche Übergabe schlichtweg unsinnig ist.
Ohne das vorher irgendein vergleich stattfindet.

Ja ich weis ist nur ein Beispiel.. aber trotzdem.

gruss

Um dem Unsinn noch ein drauf zu setzen, bitteschön mit Vergleich.

Delphi-Quellcode:

function IsTrueReallyTrueOrDoesItFoolMe: Boolean;
begin
  if not IsTrueReallyTrueOrDoesItFoolMe then Result := True else;
end;

[Dalai]

Es gibt nicht nur den Typen Boolean sondern auch BOOL und LongBool, die beide gerne bei WinAPI-Funktionen verwendet werden. Deren Definitionen von True und False unterscheiden sich aber unter Umständen von der von Boolean. Daher sollte man sich gar nicht erst angewöhnen, mit True und False zu vergleichen. Es ist schlicht unnötig und verursacht potentiell Fehler beim Verhalten der Software - sozusagen eine Diskrepanz zwischen dem, was der Programmierer sich denkt und dem, was er tatsächlich an Code geschrieben hat.

Nicht nur hier im Forum wurde das Thema bereits intensiv diskutiert. Da finden sich mit Sicherheit bessere und detailliertere Begründungen.

Grüße
Dalai