ShlObj -> PickIconDlg() - merkwürdiges Verhalten

[KodeZwerg]

Hallo Gemeinde,

ich habe gerade den Vorteil dieser Funktion entdeckt aber weiß nicht so richtig wie ich sie korrekt anwenden muss.
Information habe ich dafür selbst noch nicht viele gefunden. Emba und meine Hilfe zucken mit Achseln.

Hier ist ein Wrapper den ich geschustert habe:

Delphi-Quellcode:

uses
  ShlObj;

...

function PickIconDialog( IconHandle: HWND; var Filename: string; var IconIndex: Integer ): Boolean;
var
  tmp : String;
  idx: Integer;
begin
  Result := False;
  tmp := Filename;
  idx := IconIndex;
  if ( PickIconDlg( IconHandle, PWideChar( tmp ), 1023, idx ) <> 0 ) then
    begin
      Filename := String( tmp );
      IconIndex := idx;
      Result := True;
    end;
end;

und so in etwa rufe ich das ganze auf:

Delphi-Quellcode:

procedure TfrmMain.btnGetIconClick(Sender: TObject);
var
  IconFile: String;
  IconIndex: LongInt;
begin
  IconFile := '';
  IconIndex := 0;
  try
    IconIndex := StrToInt( edIconIndex.Text );
  except
    IconIndex := 0;
  end;
  if ( PickIconDialog( Handle, 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;

In theory klappt es, praktisch erhalte ich auch tatsächlich immer den korrekten Namen plus Index.
Aber anscheinend ist mir dennoch da ein Fehler passiert.

Hier meine Fehl-Erscheinungen:
Edit Felder die vor dem Aufruf keinen Inhalt besaßen, haben nach dem Aufruf unsichtbar den Wert von "IconFile" gespeichert.
Manchmal wird mir im Edit Feld für Wert IconFile nichts angezeigt (Wert ist auch dort unsichtbar)

Frage, kennt sich jemand mit dieser Funktion aus und weiß wie sie ordentlich bedient wird?
Frage, hat Delphi eventuell solch einen praktischen Dialog bereits on-board und ich weiß davon nichts?

Vielen Dank fürs Lesen!

[Delphi.Narium]

guckst Du hier: https://www.delphipraxis.net/27491-d...n-auswahl.html

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

Zitat von Dalai (Beitrag 1417765)

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.

Delphi-Quellcode:

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

*updated*

Dankeschön!

[Dalai]

Zitat:

Zitat von KodeZwerg (Beitrag 1417770)

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

Achso, alles klar :).

Zitat:

Delphi-Quellcode:

  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

Delphi-Quellcode:

= True

wegzulassen, also so

Delphi-Quellcode:

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:

Zitat von Alter Mann (Beitrag 1417794)

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:

Zitat von EWeiss (Beitrag 1417790)

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

[HolgerX]

Hmm..

Zitat:

Zitat von EWeiss (Beitrag 1417799)

Zitat:

Zitat von Alter Mann (Beitrag 1417794)

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

Wenn ich bei PickIconDlg auf 'Abrechen' Clicke, dann wird '0' zurück geliefert, somit hat der User nichts ausgewählt... ;)

Es stimmt also die Beschreibung von MS..

Das bei Boolean/Bool/Longbool nicht mit z.B. '= True' geprüft werden soll, ist ja bereits in diversen Threads hier im Forum besprochen worden und sollte eigentlich kein Thema mehr sein ;)

[EWeiss]

Zitat:

Wenn ich bei PickIconDlg auf 'Abrechen' Clicke, dann wird '0' zurück geliefert, somit hat der User nichts ausgewählt...

Richtig!

Aber nicht wenn du diese Funktion aufrufst.

Delphi-Quellcode:

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

Diese wurde im nachhinein geändert.
Nur so wie sie war und wo ich drauf geantwortet habe ist sie unsinnig weil das Result immer True ist.
Also nochmal!

Das kann in dem fall niemals eintreten.

Delphi-Quellcode:

Returns 1 if successful; otherwise, 0.

Somit stimmt meine Aussage.

Zitat:

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

gruss

[EWeiss]

Zitat:

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;

Du hast es wirklich geschafft da noch einen? Nein mindestens 4x Fach draufzusetzen.

Ein klassischer Deadlock rekursiver Aufruf inklusive Stackoverflow.
von deinem else ohne irgendwas mal abgesehen. (Rückgabe undefiniert).
Wow wie kann man in einer Zeile Code so viele Fehler produzieren und sich damit auch noch rühmen.

Gratulation :thumb:
Das alles kann ich dieser einen Zeile entnehmen ohne sie selbst ausprobieren zu müssen.
Versuche doch mal den unterschied zu ergründen zwischen Funktion <> Property(Getter\Setter) vielleicht kannst du dann deiner einen Zeile (Funktion) noch etwas produktives abgewinnen.

Sorry: Ich bin auch nicht perfekt wie denn auch.. aber veralbern lasse ich mich von dir auch nicht.

gruss

[KodeZwerg]

Ich wollt mich damit nicht rühmen, nur dem Unsinn noch einen drauf setzen, habe aber auch erst beim zweiten mal lesen gemerkt das Du in dem Moment was anderes Meintest.
Thread ist ja erfolgreich geschlossen, Danke nochmals.

Bilder sagen manchmal mehr als tausend Worte, deshalb mal in Anhang eins rangepappt damit man sieht woran ich überhaupt dran bin und worum es mir ging.

[EWeiss]

Zitat:

Thread ist ja erfolgreich geschlossen, Danke nochmals.

Dito! Und für mich gegessen :)

Hatte erst die Tage selbst ein Problem das ich ohne @Silhwan Hilfe nicht gefunden hätte.
Habe bei meinem Mixer immer wieder nach dem beenden einer Session einen neuen SessionThread erstellt und mich gewundert warum bei mir plötzlich 4x mal die Session der Soundmachine addiert wurde.
Na ja niemand ist perfekt aber gut.. gehört hier nicht hin.

Projekt sieht gut aus ;)

gruss

[KodeZwerg]

Zitat:

Zitat von EWeiss (Beitrag 1417827)

Projekt sieht gut aus ;)

Sowas vom Meister der GUIs zu hören, das baut ungemein auf! Dankeschön!
Ich gebe mir viel Mühe und portiere es gerade nach 64bit, da sind noch viele GUI macken zu beheben.
Die Art und Weise wie ich Dateien einlese dauert auch noch zu lange und bedarf Optimierung.
Dann gibt es da generell noch ein .lnk Problem da muss ich erst noch mehr lesen wie das geht, als "Ziel" habe ich momentan nur Datei oder Ordner als "Okay" drinnen aber Windows ist in der Lage da auch andere Sachen einzutragen, Systemordner und solch Zeugs, vielleicht wird die Information ja als Bytes wiedergegeben... mal schauen, da bin ich auf jeden Fall noch fleißig am rummachen bevor es hier groß publik wird.

Ich bin auch Drittanbietern dankbar Speicherlecks aufzudecken, das hilft ungemein :-)