VistaTaskDialog

[Willie1]

Hallo, (ich bin's shcon wieder)
bei der Umstellung gibt es noch ein weiters Problem.
Ich habe mir vor 10 Jahren eine Komponente gebaut (mit Hilfe einer Tipp-Sammlung von Michael Puff), um den VistaTaskDialog unter Delphi 2005 nutzen zu können. Finde ich besser als die von Embarcadero, die nervt! Nur ein Problem: von Caption und Text wird nur der erste Buchstabe angezeigt. Jetzt ist doch alles mit String 16-Bit. Da müsste es doch gehen. Willie.

[himitsu]

Meinst du?
http://michael-puff.de/Programmierun...skDialog.shtml

Ich hätte jetzt an ein Problemchen mit Unicode gedacht, da der Michael mit Delphis vor 2009 gearbeitet hatte.
Aber in de Artikel sieht es eigentlich OK aus (seh überall PWideChar)

Oder ist dein Code noch auf ANSI ausgelegt (die A-Typen und -Funktionen) und du gibst jetzt Unicode-Strings rein? Dann muß du das erst auf die Unicode-API (W) umbauen.




Ich fand die Klasse auch doof, drum hatte ich mir die auch in eine eigene Funktion verlagert und befülle den TTaskDialog aus den Parametern.
Joar, direkt die Delphi-Klasse, anstatt manuell über die WinAPI.

[Willie1]

Hallo Himitsu,
ich weiß es nicht mehr genau. Ich habe im Quelltext vermerkt Tippsammlung von Michael Puff. PAnsiChar kommt da nicht vor, nur PChar jetzt doch gleich PWideChar.
Mein Source ist nicht lang, kannst du dir ansehen. Danke.
Willie.

[himitsu]

Michael zu fragen, ob er das aktualisiert, wird derzeit auch etwas schwer.


Ja, vor allem Char, PChar und String sind teilweise ein Problem, wenn hier Typen vermischt werden.
Bis Delphi 2007 war PChar = PAnsiChar und ab Delphi 2009 ist es PWideChar.

Drum wird "oft" empfohlen alle auf AnsiChar/PAnsiChar/AnsiString zu ändern, damit es wieder dem "alten" Frmat entspricht.
Allerdings ist PChar per se nicht falsch, wenn eben alles zusammenpasst.

z.B.:
MessageBoxA + PAnsiChar und AnsiString
MessageBoxW + PWideChar und WideString UnicodeString
MessageBox + PChar und String

Mit ANSI hätte man dann ja auch bei Unicode ein paar Verluste, wenn man Zeichen rein gibt, die aber nichts ins ANSI rein passen.

[himitsu]

Also in dem Fall war es eigentlich falsch, denn Michael hätte hier PAnsiChar verwenden müssen,
da explizit SHMessageBoxCheckA verwendet wurde, was aber nicht so leicht auffällt, da nicht der Name verwendet wurde und auch der Typ nicht A heißt.

Zitat:

SHMessageboxCheck := GetProcAddress(hLib, PChar(185));

185 ist die ID für SHMessageBoxCheckA.

Die ID für SHMessageBoxCheckW kenn ich jetzt nicht, also würde ich hier mal schauen, ob es nicht doch besser über den Namen geht.

Delphi-Quellcode:

type
  TSHMessageBoxCheck = function(hWnd: THandle; Text, Title: PWideChar;
    dwType: DWORD; Default: Integer; RegVal: PWideChar): Integer; stdcall;

SHMessageboxCheck := GetProcAddress(hLib, 'SHMessageBoxCheckW');

Hätte Michael hier ANSI verwendet, dann hätte dir der Compiler sofort eine Warnung gezeigt,
da PAnsiChar und PWideChar/PChar nicht kompatibel sind.

Der Rest darf auf PChar und String bleiben, da PChar und PWideChar mit der UnicodeAPI kompatibel sind. (früher kompatibel mit PAnsiChar, bei der ANSI-API)
Und selbst im unwahrscheinlichen Fall (im Delphi), oder z.B. im FreePascal, wird der Compiler nun eine eventuelle Inkompatibilität melden.

[Willie1]

Ich glaube, das habe ich verstanden.
Es gibt aber ein weiteres Problem bei dieser Komponente. Unter dem Schlüssel Key:='Software\Microsoft\Windows\CurrentVersion\Explorer\DontShowMeThisDialogAgain' speicherte das alte Delphi ab, wenn der Dialog nicht mehr gezeigt werden soll. Dabei ist der Wert egal ob YES oder NO. Wenn er vorhanden ist, wird nichts gezeigt. Das neue Delphi speichert es woanders ab, ich kann es nicht finden. Ich habe die Registry komplett durchsucht. Es ist gespeichert, der Dialog wird nicht mehr gezeigt!

Ich habe den Schlüssel in der Microsoft-Doku gefunden: Software\Microsoft\Windows\CurrentVersion\Explorer \LowRegistry\DontShowMeThisDialogAgain .

Ich finde es absolut blöd, wenn ein Hinweis oder Dialog NIE mehr gezeigt wird. Schließlich kann ein/e anderer(e User/in das Programm benutzen oder man kann es mal vergessen. Deshalb finde ich das Zurücksetzen = Löschen des Wertes wichtig.


Nachtrag: Das Fenster zeigt jetzt den richtigen Inhalt. Wichtig, ich habe auch verstanden, woran es gelegen hat! Willie.

[himitsu]

Wenn dein Programm 32 Bit ist, dann wird es in der Registry eines 64 Bit Windows umgeleitet, nach
Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Explorer (falls ich mich im Ziel jetzt nicht täusche)

Diese Umleitung ließe sich z.B. durch Reg := TRegistry.Create(KEY_WOW64_64KEY); abschalten.
Wie im Dateisystem, gibt es hier auch in der Registry eine Redirection.

[Willie1]

Unsere Antworten hatten sich gerade gekreuzt. Ich hatte noch einen Nachtrag geschrieben. Den regulären Schlüssel-Pfad habe ich in der Doku gefunden.
Schönen Abend Willie.

[Dalai]

@himitsu
Im HKCU werden Schlüssel unter \Software nicht in dieser Art umgeleitet - im Gegensatz zu HKLM. Und die Unit benutzt ausschließlich HKCU.

Grüße
Dalai

[himitsu]

Zitat von Dalai:

Im HKCU werden Schlüssel unter \Software nicht in dieser Art umgeleitet - im Gegensatz zu HKLM. Und die Unit benutzt ausschließlich HKCU.

OK.

Sah dort auch ein Software\WOW6432Node, weswegen ich dachte das ist dort auch. (obwohl es dort schon relativ leer aussah)