Entwicklung für Vista und XP

[choose]

Hallo,

im Forum habe ich einige Beträge zu den neuen Vista- und Office-Themes nebst Komponenten-Suites von Drittherstellern gelesen. Solche Pakte erlauben es, unter XP Anwendungen zu schreiben, die schon heute Aussehen wie die zukünftigen Microsoftprodukte.

Für mich stellt sich jedoch eine andere Frage: Wie kann ich eine Software entwickeln, die sowohl unter Windows XP als auch unter Windows Vista "zeitgemäß" aussieht. Das Theme von Buttons und Fensterrändern übernimmt die Rendering-Engine von Windows größtenteils automatisch. Aber wie kann ich mich bspw. an den neuen Style-Guide halten, ohne Schriftarten wie Sergoe UI hart einzubinden. Denn das würde wohl zu Problemen auf normalen XP-Installationen führen, oder? Wie erzeuge ich ein Fenster, das so aussieht, wie der neue Aero Wizard mit dem Back-Button oben links? In einigen Foren und Blogs kann nachgelesen werden, wie man den Command Link über spezielle Windows-Botschaften erzeugen kann, aber das scheint mir das kleinste Problem...

Habt Ihr irgendwelche Lösungsideen dazu?

[cruso]

Naja also momentan haben wir ja für XP das "XP-Manifest", das sich immer an das gegbene Windows Design anpasst (wenn man das Programm z.B. unter Win2000 ausführt etc). Das Manifest kann man ja als Komponente hinzufügen (ab Delphi 7) oder manuell in das Verzeichnis schieben. Ich denke, dass man das auch in Vista über ne Manifest Datei lösen können wird.

Mein Tipp: Momentan noch abwarten bis Vista kommt. Dann kann man immernoch schnell n' Update rausgeben.

[NicoDE]

Zitat:

Zitat von choose

ohne Schriftarten wie Sergoe UI hart einzubinden.

So wie bisher auch: "MS Shell Dlg" ist ein Alias auf den Shell-Font.

[MathiasSimmack]

Zitat:

Zitat von choose

Wie kann ich eine Software entwickeln, die sowohl unter Windows XP als auch unter Windows Vista "zeitgemäß" aussieht.

Warum ist das wichtig? Oder anders gefragt: Warum definiert man "zeitgemäß" mit "Ich (der Entwickler) bestimme wie mein Programm unter Windows aussieht!"? Das macht vielleicht bei entsprechenden Applikationen Sinn, etwa ein MediaPlayer, der wie eine HiFi-Anlage aussieht, oder ein DVD-Tool, das wie eine Filmrolle daher kommt. Aber ein 08/15-Tool? (Wobei 08/15 nicht böse gemeint ist, da ich selbst nur solche kleinen Tools schreibe.) Hier wäre es mir wichtig, dass sich das Programm an mein (und ich bin hier der Windows-Anwender) Design hält, das ich eingestellt habe. So nett Vista auch aussieht. Ich möchte kein Programm, das mehrere MB groß ist oder MB-große Grafik-Libs installiert, um den Vista-Stil nachzuahmen. Wenn das Programm verbuggt oder generell sch*** ist, dann hilft auch kein gutes Aussehen ... :stupid: Wobei "gut" ohnehin Ansichtssache ist ...

[cruso]

Zitat:

Zitat von MathiasSimmack

Zitat:

Zitat von choose

Wie kann ich eine Software entwickeln, die sowohl unter Windows XP als auch unter Windows Vista "zeitgemäß" aussieht.

Warum ist das wichtig? Oder anders gefragt: Warum definiert man "zeitgemäß" mit "Ich (der Entwickler) bestimme wie mein Programm unter Windows aussieht!"? Das macht vielleicht bei entsprechenden Applikationen Sinn, etwa ein MediaPlayer, der wie eine HiFi-Anlage aussieht, oder ein DVD-Tool, das wie eine Filmrolle daher kommt. Aber ein 08/15-Tool? (Wobei 08/15 nicht böse gemeint ist, da ich selbst nur solche kleinen Tools schreibe.) Hier wäre es mir wichtig, dass sich das Programm an mein (und ich bin hier der Windows-Anwender) Design hält, das ich eingestellt habe. So nett Vista auch aussieht. Ich möchte kein Programm, das mehrere MB groß ist oder MB-große Grafik-Libs installiert, um den Vista-Stil nachzuahmen. Wenn das Programm verbuggt oder generell sch*** ist, dann hilft auch kein gutes Aussehen ... :stupid: Wobei "gut" ohnehin Ansichtssache ist ...

Ich denke, dass choose meint, dass man das Programm unter XP und Vista ausführen können soll und es unter XP den XP-Style und unter Vista den Vista-Style hat.

[MathiasSimmack]

Das denke ich nicht, denn dann wäre der Beitrag an sich überflüssig. :lol: Ein simples 08/15-Programm, das keine speziellen Windows-Funktionen verwendet, die auf bestimmte Systeme beschränkt ist, läuft in der Regel von 95 bis Vista und nutzt dann natürlich auch den jeweiligen Fensterstil.

Wenn es wirklich darum geht, warum dann die Frage nach einem "zeitgemäßen" Look der Anwendungen?


btw, das .NET Framework 3.0 erlaubt ein nahezu unbegrenztes Anpassen der eigenen Anwendung. Mit Hilfe von im Programm integrierten Ressourcendeklarationen kann man das Aussehen von fast allen Elementen beliebig ändern. Aus einem gelben Standard-Tooltip habe ich so ein etwas größeres graublaues Element mit abgerundeten Ecken und fester Breite gemacht (s. Bild im Anhang). Und ich bin kein Designer. Stell dir vor, was Leute mit echten grafischen Talenten anstellen könnten. :stupid:

[cruso]

Ich würde es toll finden, wenn sich choose auch nochmal äußern würde, damit wir wissen was er genau meinte und ob seine Frage nun beantwortet ist etc.

[idontwantaname]

@MathiasSimmack: Ich denke, du verstehst da etwas ganz falsch.

Also: choose möchte sein Programm den Guidelines anpassen, welche vom Betriebssystem abhänging sind. So haben wir unter Windows XP in Dialogen die Buttons unten rechts, in Windows Vista sollen sie oben links plaziert sein. (Zumindestens der Zurück-Button.)
Nun sucht choose eine Möglichkeit, seine Anwendung so zu gestalten, dass unter Windows XP die Buttons unten und in Windows Vista die Buttons eben oben sind.

[alias5000]

@idontwantaname: Ich denke, du verstehst da etwas ganz falsch.

Also: ...
:mrgreen:

Scherz beiseite, Choose soll nochmal sagen, was er konkret meint, allerdings hab ich ihn so verstanden, wie es Matthias verstanden hat. Aber man kann nicht sagen, dass einer es so und nicht anders gemeint hat (oder hast du ICQ Kontakt zu ihm?)

Gruß alias5000

[cruso]

Naja als allgemeinen Tipp:

Man könnte die Windows-Version auslesen und sich dann sein Programm passend zurechtbasteln. Oder man schreibt einfach zwei Applikationen. :lol:

[faux]

Zitat:

Zitat von cruso

Mein Tipp: Momentan noch abwarten bis Vista kommt. Dann kann man immernoch schnell n' Update rausgeben.

Und genau dafür gibts Beta-Versionen von Vista. :zwinker:

Grüße
Faux

[cruso]

Zitat:

Zitat von faux

Zitat:

Zitat von cruso

Mein Tipp: Momentan noch abwarten bis Vista kommt. Dann kann man immernoch schnell n' Update rausgeben.

Und genau dafür gibts Beta-Versionen von Vista. :zwinker:

Grüße
Faux

Lohnt sich aber nur für Leute die Software kommerziell vertreiben...
Ich lad mir doch nicht tausende Megabytes runter nur um zu wissen ob der "Zurück"-Button oben links oder unten rechts hinkommt! :lol:

Außerdem werden wohl viele Vista im klassischen Modus laufen haben (bei den Systemvoraussetzungen für Aero Glass) und da sieht das was im Vista- oder XP-Style gut aussieht meist eigenartig aus.

[MathiasSimmack]

Zitat:

Zitat von idontwantaname

Nun sucht choose eine Möglichkeit, seine Anwendung so zu gestalten, dass unter Windows XP die Buttons unten und in Windows Vista die Buttons eben oben sind.

Ich bin nicht sicher, ob es diese Möglichkeit überhaupt gibt. Ich habe für Luckies Win32-API-Tutorials einen Beitrag über Assistenten geschrieben. Jede einzelne Seite ist eigentlich nur eine Dialogressource. Die Reihenfolge der Seiten bis hin zur Anzeige/Aktivierung einzelner Buttons wird durch spezielle API-Funktionen erledigt. Nur sieht so ein API-Assistent unter Vista so aus wie unter Windows XP und entspricht damit nicht den neuen Richtlinien eines Vista-Assistenten. Evtl. gibt es irgendwo noch eine kleine Einstellung, mit der man wenigstens das ändern kann.

Trotzdem hast du noch ein Problem: Die Richtlinien (Guide lines) eines Assistenten unter 9x/ME/NT/200x/XP unterscheiden sich von denen, die für Vista gelten. Headerbereiche, Willkommensseiten, usw. sollten unter Vista nach Möglichkeit nicht mehr verwendet werden.


Also doch zwei Assistenten programmieren? Ehrlich gesagt, ich habe mich bisher noch nicht weiter damit beschäftigt. Vllt. findet sich im Windows SDK ein kleiner Beitrag darüber.

[MathiasSimmack]

Zitat:

Zitat von MathiasSimmack

Nur sieht so ein API-Assistent unter Vista so aus wie unter Windows XP und entspricht damit nicht den neuen Richtlinien eines Vista-Assistenten. Evtl. gibt es irgendwo noch eine kleine Einstellung, mit der man wenigstens das ändern kann.

Ja, gibt es. :stupid: Ich habe mal ein wenig experimentiert, und voilà: Es ist zwar nicht perfekt, aber das Bild zeigt den Beispielassistenten aus den Win32-API-Tutorials im neuen Vista-Look. Es reicht das Flag PSH_AEROWIZARD. Natürlich muss man dafür sorgen, dass dieses Flag nur unter Vista eingesetzt wird. Bei den anderen Systemen wäre PSH_WIZARD97 nötig, damit der Assistent dieses Zurück/Weiter-Feeling hat. :mrgreen:

[choose]

Hey,

ich möchte in der Tat ein(e) Programm/Codebasis für die Betriebssysteme Win2k, WinXP und Vista pflegen und dabei sowohl die jeweiligen Themes als auch die Guidelines unterstützen. In der Vergangenheit war das relativ unkompliziert. Zum einen gab es "offizielle" Guidelines meines Wissens erst seit Windows XP (so dass sie sich nicht widersprachen) und zum Anderen ließen sie sich größtenteils erreichen, indem man die Controls entsprechend platzierte. Andere Controls änderten ihr Verhalten mit entsprechenden CreateParams oder Windows-Botschaften, die von vorherigen Versionen ignoriert wurden. So zeigt ein Passwort-Edit unter Win2k noch Sternchen, während man unter XP die Kreise mit automatischem Hint bei aktiviertem Caps-Lock sieht.

Ich rede weniger von Buttons oder Listen, die sich ins Bild einfügen, auch einfache Controls wie der CommandLink lassen sich durch neue Botschaften (s.o.) erzeugen. Ich gehe davon aus, dass sich die ListViews und andere Controls gleichfalls aufbohren lassen.

Viel mehr interessiert mich, wie die unterschiedlichen Layouts und Konzepte erreicht werden können. Wizard Pages, Durchsuchbarer Content, Dialogboxen mit Details, Fußnoten und abweichenden Buttonbeschriftungen. Auch interessiert mich, wie ich das Glass im ClientArea erzeugen soll und damit zu arbeiten habe, wenn ich sonst schon einen Alpha-Kanal verwende.

Die Beispiele, die ich dazu finde, richten sich vornehmlich an .net und -nun kommt's- ich muss eine Win32-Anwendung weiterpflegen.

[choose]

Hallo Mathias,

Zitat:

Zitat von MathiasSimmack

[..] Es ist zwar nicht perfekt, aber das Bild zeigt den Beispielassistenten aus den Win32-API-Tutorials im neuen Vista-Look. Es reicht das Flag PSH_AEROWIZARD. Natürlich muss man dafür sorgen, dass dieses Flag nur unter Vista eingesetzt wird. [..]

genau von solche Angaben interessieren mich! Hat sich sonst schon jemand mit dem Thema beschäftigt?

[faux]

Zitat:

Zitat von cruso

Lohnt sich aber nur für Leute die Software kommerziell vertreiben...
Ich lad mir doch nicht tausende Megabytes runter nur um zu wissen ob der "Zurück"-Button oben links oder unten rechts hinkommt! :lol:

Ich habe ja nicht gesagt, dass du dir die Beta laden sollst, sondern nur, dass sie für sowas da ist. Es gibt hier sicherlich einige im Forum die das für dich testen würden. ;)

Grüße
Faux

[MathiasSimmack]

Zitat:

Zitat von choose

So zeigt ein Passwort-Edit unter Win2k noch Sternchen, während man unter XP die Kreise mit automatischem Hint bei aktiviertem Caps-Lock sieht.

Die Kreise von XP erscheinen bspw. nur, wenn du ein Manifest verwendest. Das Thema wird bspw. auch in den Win32-API-Tutorials angesprochen. Vielleicht wirfst du mal einen Blick rein. Ich bin nämlich auch so ein Spielehansel. Luckie hat damals noch mit Windows 2000 gearbeitet. Was denkst du, wer einfach die ganzen Windows XP-Themen in die Tutorials geschrieben hat? :stupid:

Zitat:

auch einfache Controls wie der CommandLink lassen sich durch neue Botschaften (s.o.) erzeugen. Ich gehe davon aus, dass sich die ListViews und andere Controls gleichfalls aufbohren lassen.

Leider nicht. :( Viele Dinge stehen tatsächlich erst ab Windows XP zur Verfügung, und dann meist nur, wenn du ein Manifest nutzt. Sei es die Gruppierung der List-View, die Markierung der Spalten. Auch das SysLink-Control (quasi der Hyperlink in einer Windows-Anwendung) ist erst ab Windows XP vorhanden. Da hast du unter älteren Versionen kein Glück und müsstest wirklich auf zusätzliche Komponenten oder das .NET Framework ausweichen.


Mich hat´s gerade gepackt: ich werde mal den Assistenten aus den Tutorials vista-risieren, damit er vernünftig aussieht (Titelleiste usw.). :zwinker: Der ist mit Delphi 5 und dem Win32-API entwickelt worden. In dem Fall genügt wirklich nur ein neues Flag, um den Look zu ändern. Aber genau das ist das Problem mit Borland. Borland hat leider nie einfach mal ein neues Unitpaket mit aktualisierten und neuen Flags geschnürt. Man sollte sich immer gleich eine neue Delphi-Version kaufen. Und selbst dann waren nicht immer sofort alle neuen Dinge möglich.

Bei Microsoft dagegen holst du dir das PSDK oder (weil du von Vista redest) das Windows SDK, und du erhältst einen Satz Headerdateien. Was glaubst du, wo ich den Wert von PSH_AEROWIZARD her habe? :) Ich habe bei mir das Windows SDK installiert (1gig-ISO von Microsoft, musst du mal suchen, nimm die June CTP!) mit Dokumentationen zum API, zum .NET Framework und auch zu Vista. Der Blick da rein lohnt sich auf jeden Fall.

[NicoDE]

Zitat:

Zitat von MathiasSimmack

Was denkst du, wer einfach die ganzen Windows XP-Themen in die Tutorials geschrieben hat?

Nunja, bisher haben alle die Manifest-Datei als Resource einkompiliert. Das dumme daran ist nur, dass man sie deshalb nicht mehr ändern kann (zum Beispiel um im Manifest einzutragen, dass das Program Admin-Rechte benötigt).

[choose]

Zitat:

Zitat von MathiasSimmack

Viele Dinge stehen tatsächlich erst ab Windows XP zur Verfügung, und dann meist nur, wenn du ein Manifest nutzt.

Und genau das meine ich: Ich gehe nicht davon aus, das es über irgendwelche Tricks möglich ist, Rückwirkend für Win2k Themes oder andere WinXP/Vista-Verhalten zu aktivieren. Vielmehr Suche ich nach Möglichkeiten, die von Vista- und XP-Nutzern erwarteten Konzepte zu verfolgen, ohne dass ich jede Applikation mehrfach schreiben muss. Im Fall einer Manifestdatei klappte das in der Vergangenheit prima: Unter Win2k hatte sie keinen Effekt, unter WinXP kamen die Themes zum Vorschein. Und Dinge wie das Flag für den Wizard bekomme ich über eine Versionsprüfung auch hin.

In der Vergangenheit habe ich einige Komponenten selbst geschrieben, um bspw. auf die SysLinks zu verzichten. Auch unter Win2k konnten so Links innerhalb der Applikation verwendet werden. Mit den Command Links werde ich das wahrscheinlich ähnlich machen. Was aber passiert aber mit den "Task Dialogs", die nun die einfachen Meldungsboxen ablösen? Muss ich das abermals über eine eigene Komponente abdecken, damit ich die Phrasen in den Meldungen nicht zweimal entwerfen muss?

Und was ist mit dem übrigen Aero-Sachen? Bin ich gezwungen spezielle "Panels" einzuführen, damit sie unter Vista den gewünschten Glas-Effekt haben?


Vielen Dank für den Hinweis zum SDK, Mathias.

[MathiasSimmack]

Zitat:

Zitat von NicoDE

Zitat:

Zitat von MathiasSimmack

Was denkst du, wer einfach die ganzen Windows XP-Themen in die Tutorials geschrieben hat?

Nunja, bisher haben alle die Manifest-Datei als Resource einkompiliert. Das dumme daran ist nur, dass man sie deshalb nicht mehr ändern kann (zum Beispiel um im Manifest einzutragen, dass das Program Admin-Rechte benötigt).

:gruebel: Davon hörte ich zwar schon in Bezug auf Inno Setup und Vista, aber woher hätte ich das damals beim Schreiben wissen sollen, Nico? Bin doch kein Hellseher. Ich wollte damit nur sagen, während Luckie einfach nur Informationen mitteilte (so und so benutzt man dies und das), habe ich noch ein paar Spielereien (= Neuigkeiten von XP) ergänzt, weil ich XP hatte, Luckie aber nicht. :mrgreen:


PS: Den Glas-Effekt im Clientbereich kannst du vergessen. Wer so was macht, der muss besch**** sein. :zwinker: Den Glas-Effekt würde ich wirklich nur auf die Kanten und Titelleiste des Fensters beschränken. Im Clientbereich hat das nichts zu suchen, und mir ist bisher in Vista noch kein Assistent oder sonst was begegnet, der ein durchscheinendes Panel besaß, auf dem Buttons sitzen, o.ä.

[MathiasSimmack]

Noch ein PS:

Zitat:

Zitat von choose

Was aber passiert aber mit den "Task Dialogs", die nun die einfachen Meldungsboxen ablösen? Muss ich das abermals über eine eigene Komponente abdecken, damit ich die Phrasen in den Meldungen nicht zweimal entwerfen muss?

Musst du nicht. Auch hier dürfte eine Versionsprüfung reichen. Wenn du ins Windows SDK schaust, dann such mal im Index nach "Task Dialog" bzw. "TaskDialogIndirect". Ich bin per Google gerade darüber gestolpert. Aber glücklicherweise wird das Thema auch im SDK abgehandelt. Es läuft also darauf hinaus, dass du dir einen Wrapper schreiben musst, der unter XP die typische Messagebox anzeigt und unter Vista dann eben den neuen Dialog.

[choose]

Zitat:

Zitat von MathiasSimmack

Den Glas-Effekt im Clientbereich kannst du vergessen. Wer so was macht, der muss besch**** sein. :zwinker:

In Fällen, in denen der Rand (wie hier zu sehen) etwas erweitert werden soll, kann ich mir das sehr gut vorstellen...

[choose]

Hallo Mathias,

Zitat:

Zitat von MathiasSimmack

Es läuft also darauf hinaus, dass du dir einen Wrapper [für Task Dialog] schreiben musst, der unter XP die typische Messagebox anzeigt und unter Vista dann eben den neuen Dialog.

Wenn man sich auf den kleinsten Nenner einigt, klar. Dann schreibe ich Dialoge, die einfach nur "Ja" und "Nein" erwarten. Wenn meine Benutzerführung allerdings die Möglichkeiten der Task Dialogs ausnutzen möchte (Radiobuttons, Command Links, Detail Knopf, etc.) könnten sie auf herkömmliche Weise nicht gezeigt werden. Das ist wie bei den SysLinks: Drauf verzichten hätte man einfach können, wenn ich unter XP aber solche Links bieten möchte und mein GUI darauf aufbaut, muss eine geeignete Lösung für Win2k her...

[MathiasSimmack]

Zitat:

Zitat von choose

Wenn meine Benutzerführung allerdings die Möglichkeiten der Task Dialogs ausnutzen möchte (Radiobuttons, Command Links, Detail Knopf, etc.) könnten sie auf herkömmliche Weise nicht gezeigt werden.

Dann geht es jetzt aber um mehr als nur die Pflege einer API-Anwendung. Pflege setzt voraus, dass die Anwendung bereits existiert. Tut sie das, dann dürfte sie bisher auch ganz gut ohne den Vista-Schnickschnack ausgekommen sein. Warum jetzt auf Biegen und Brechen so etwas einbauen und dann Probleme auf den älteren Betriebssystemen riskieren? Das würde ich dann doch wieder mehr in diese Thematik einordnen. ;)

[MagicAndre1981]

Zitat:

Zitat von MathiasSimmack

mir ist bisher in Vista noch kein Assistent oder sonst was begegnet, der ein durchscheinendes Panel besaß, auf dem Buttons sitzen, o.ä.

Doch die Anzeige aller verfügbaren Gagdets für die Sidebar und das sieht soooooo geil aus :love: :love: :love: :love: . Ick will das auch haben :cry:

[MathiasSimmack]

Zitat:

Zitat von choose

Task Dialog

Mal technisch: Ich sitze gerade hier mit Vista und Delphi 5. :shock: Auf die UI muss ich verzichten, aber der Kommandozeilencompiler geht. Die einfache Variante des Dialogs, "TaskDialog", habe ich hinbekommen:

Delphi-Quellcode:

unit Vista;

interface;

const
  TD_WARNING_ICON       = -1;
  TD_ERROR_ICON         = -2;
  TD_INFORMATION_ICON   = -3;
  TD_SHIELD_ICON        = -4;

  // TASKDIALOG_COMMON_BUTTON_FLAGS
  TDCBF_OK_BUTTON            = $0001; // selected control return value IDOK
  TDCBF_YES_BUTTON           = $0002; // selected control return value IDYES
  TDCBF_NO_BUTTON            = $0004; // selected control return value IDNO
  TDCBF_CANCEL_BUTTON        = $0008; // selected control return value IDCANCEL
  TDCBF_RETRY_BUTTON         = $0010; // selected control return value IDRETRY
  TDCBF_CLOSE_BUTTON         = $0020; // selected control return value IDCLOSE

  function TaskDialog(hwndParent: HWND; hInstance: longword;
    pszWindowTitle: PWideChar; pszMainInstruction : PWideChar;
    pszContent: PWideChar; dwCommonButtons: dword; pszIcon : PWideChar;
    var pnButton: integer): HRESULT; stdcall;

implementation

const
  comctl32 = 'comctl32.dll';

function TaskDialog; external comctl32;

end.

Im Original ist die Deklaration der Buttons eigentlich vom enum-Typ, aber egal. Das funktioniert auch erst mal so. Merkwürdig finde ich das mit den Symbolen. Hier mal die Originaldeklaration der Funktion

Code:

WINCOMMCTRLAPI HRESULT WINAPI TaskDialog(__in_opt HWND hwndParent, __in_opt HINSTANCE hInstance, __in_opt PCWSTR pszWindowTitle, __in_opt PCWSTR pszMainInstruction, __in_opt PCWSTR pszContent, TASKDIALOG_COMMON_BUTTON_FLAGS dwCommonButtons, __in_opt PCWSTR pszIcon, __out_opt int *pnButton);

PCWSTR ist doch, IMHO, ein PWideChar, oder? Demzufolge müsste meine Delphi-Deklaration von oben ja korrekt sein. Klappt nur nicht. Versuche ich ein Symbol zu laden, dann sehe ich die Box überhaupt nicht. Bisher klappt es nur mit nil:

Delphi-Quellcode:

if (TaskDialog(0, 0, 'Test TaskDialog', 'So eine etwas dickere Überschrift',
      'Dies ist der eigentliche Inhalt.', TDCBF_YES_BUTTON or TDCBF_NO_BUTTON or
      TDCBF_CANCEL_BUTTON, nil, i) = S_OK) then
begin
  case i of
    IDYES:
      MessageBox(0, 'Ja', nil, 0);
    IDNO:
      MessageBox(0, 'Nein', nil, 0);
    IDCANCEL:
      MessageBox(0, 'Abbrechen', nil, 0);
  end;
end;

An sich sollte aber auch

Delphi-Quellcode:

(TaskDialog(0, 0, { ... } MAKEINTRESOURCEW(TD_INFORMATION_ICON), i)

klappen. Wo also liegt der Fehler?



@André: Wenn es für dein Programm einen guten Grund gibt, einen komplett durchsichtigen Hintergrund zu nutzen, dann nur zu. Andernfalls solltest du erst mal ausprobieren, wie das aussieht, was andere dazu sagen und die Sache dann wieder vergessen. :lol: Nichts für ungut, aber bei den Gadgets macht das noch halbwegs Sinn. Die Startleiste ist ja auch transparent.



PS: Aaaah, Problem (wieder mal :stupid:) selbst gelöst. Die Icon-Werte waren falsch. Und das aus der Headerdatei des Windows SDK :roll: Egal:

Delphi-Quellcode:

  TD_ICON_BLANK             =   100;
  TD_ICON_WARNING          =   101;
  TD_ICON_QUESTION          =   102;
  TD_ICON_ERROR             =   103;
  TD_ICON_INFORMATION          =   104;
  TD_ICON_BLANK_AGAIN          =   105;
  TD_ICON_SHIELD          =     106;

geht dann aber (s. neues Bild im Anhang).

[MathiasSimmack]

Am "TaskDialogIndirect" sitze ich gerade (s. Bild im Anhang). Aber damit mache ich morgen weiter. Der Code ist fertig. Ich muss mir nur noch angucken, was für Spielchen man damit noch so alles machen kann. :stupid:

[choose]

Hallo Mathias,

das sieht ja schon richtig gut aus! Wie sieht im Augenblick Dein Entwicklungszyklus aus? Codieren unter XP und unter Vista laufen lassen oder tatsächlich in der Konsole kompilieren und mit Notepad entwickeln? Du hast nicht zufällig vor, die Ergebnisse in Form einer Funktionssammlung mit Delphi-Typen und etwas Komfort zur Verfügung zu stellen, oder?

[MathiasSimmack]

Die Deklaration vom ersten Dialog, "TaskDialog", hast du ja bereits. Der läuft wirklich nur unter Vista, und ein Manifest ist zwingend erforderlich, sonst kommt auch unter Vista die Meldung, die Funktion könne nicht gefunden werden.
Der erste Dialog war nicht so tragisch. Etwas komplizierter war das Record (unser Luckie würde "Struktur" sagen :stupid:) für "TaskDialogIndirect". Aber wie du im Bild sehen kannst, hast du da auch mehr Möglichkeiten. Ich schraube gerade eine kleine Demo zusammen, die beide Dialoge aufruft. Ich muss noch ein paar Sachen testen, damit ich auch weiß wovon ich rede, und dann erscheint das ganze als Artikel inkl. Quellcode.

btw, Delphi 5 läuft jetzt auch unter Vista. Nur am Anfang kommt die Meldung, irgendein Verzeichnis kann nicht umbenannt werden. Aber damit kann ich leben. Ich brauche es eh nur für Notfälle, falls ich mal direkt unter Vista kompilieren will. Ansonsten, ehrlich gesagt, hätte ich mir Delphi da nicht mehr installiert. :oops:


Ich hätte nicht gedacht, das mal zugeben zu müssen, aber ich muss mich echt wieder in Delphi eingewöhnen. Bei CSharp hätte ich dafür schon eine NativeMethods-Klasse zusammengeschraubt. :)

[MathiasSimmack]

Okay, grundsätzlich hätte ich den Artikel fertig. Das einzige Problem ist momentan die Checkbox. Das Erzeugen derselben und das Reagieren in der Callback-Funktion ist kein Ding. Der Rückgabewert ist das, womit ich zurzeit Schwierigkeiten habe. Hier die Original-Deklaration:

Code:

HRESULT TaskDialogIndirect(
    const TASKDIALOGCONFIG *pTaskConfig,
    int *pnButton,
    BOOL *pfVerificationFlagChecked
);

Der letzte Parameter ist ein Zeiger auf einen bool-Wert. Lt. SDK ist dieser Wert TRUE, wenn der Haken in der Checkbox gesetzt war, und FALSE, wenn er das nicht war. Irgendwie klappt das nur nicht. :gruebel: Wenn ich die Variable initialisiere (mit FALSE), dann erhalte ich grundsätzlich auch FALSE zurück. Wenn ich die Variable nicht initialisiere, dann liefert die Funktion TRUE, selbst wenn ich gar keine Checkbox im Dialog nutze. :roll: Irgendwo ist da noch der Wurm drin.

Soll ich den Artikel trotzdem erst mal veröffentlichen? Das Thema Checkbox würde ich ausklammern, und wir reden darüber, wenn Artikel und Demo online sind.

[MagicAndre1981]

Zitat:

Zitat von MathiasSimmack

Soll ich den Artikel trotzdem erst mal veröffentlichen? Das Thema Checkbox würde ich ausklammern, und wir reden darüber, wenn Artikel und Demo online sind.

JUpp, mach das und schreib einen Hinweis, dass das Thema CheckBox später kommt.

[Luckie]

Und hier der versprochene Artikel; http://www.michael-puff.de/Developer...skDialog.shtml
Auch wenn es nirgens steht, Mathias ist der Autor und übernimmt somit die volle Verantwortung. Fragen bitte an Mathias richten.

(Tippfehler bitte an mich per PN.)

@Mathias: Als PDF hast du da snicht noch zufällig vorliegen? Wie ich hier: http://www.michael-puff.de/Developer...ortEvent.shtml (Oben rechts.)

[MathiasSimmack]

Müsste ich bei Gelegenheit mal zusammenbauen.
Aber was ist denn eigentlich aus meinem schönen Delphi-Stylesheet geworden? :cry:

[Luckie]

Der wird noch benutzt. Ich habe nur meinen Stylesheet für die Codeblöcke benutzt.

[MathiasSimmack]

Das Problem ist nur, dass dein Stylesheet nichts mit meinen Klassenangaben anfangen kann. Wenn du das wieder korrigieren könntest, wäre ich dir dankbar. Notfalls passe ich die Farben in der "delphi8.css" an deine Vorgaben an, aber ich formatiere den Quellcode nun mal mit meinem Tool. :stupid:

[MathiasSimmack]

Ich habe mal mit einer CSharp-Klasse für den einfachen TaskDialog (nicht TaskDialogIndirect!) angefangen. Die Anwendung ist ähnlich wie die MessageBox. Vom einfachen Aufruf nur mit dem Inhalt bis hin zum kompletten Aufruf inkl. Titel, Buttons, usw. Nur mit dem Symbol habe ich noch Probleme. Grundsätzlich sieht die Deklaration so aus:

Code:

[DllImport(Win32Libraries.ComCtl32, CharSet = CharSet.Auto, SetLastError = true)]
internal static extern void TaskDialog(
          IntPtr hwndParent,
          IntPtr hInstance,
          string pszWindowTitle,
          string pszMainInstruction,
          string pszContent,
          TaskDialogButtons dwCommonButtons,
          string pszIcon,
          [In,Out] ref int pnButton);

/* ... */


public enum TaskDialogIcon
{
   Blank = 100,
   Warning,
   Question,
   Error,
   Information,
   BlankAgain,
   Shield
}

Wenn ich aber, ähnlich wie bei Delphi, den Icon-Wert in einen String umwandle, dann erscheint der Dialog nicht. Nur wenn ich null nehme, klappt es. Anbei mal der Code der Show()-Methode mit allen Parametern, weil hier der eigentliche Aufruf des Dialogs drin steckt:

Code:

public static TaskDialogResult Show(IntPtr hwndParent, IntPtr hInstance,
   string content, string dialogTitle, string mainInstruction,
   TaskDialogButtons buttons, TaskDialogIcon icon)
{
   if (!SupportedOS.IsWindowsVistaOrHigher())
   {
      throw new NotSupportedException
         ("Your operating system does not support this dialog.");
   }
   int dialogResult = 0;

   NativeMethods.TaskDialog
      (hwndParent,
       hInstance,
       dialogTitle,
       mainInstruction,
       content,
       buttons,
       GetIconValue(icon),
       ref dialogResult);
   return (TaskDialogResult)dialogResult;
}

static string GetIconValue(TaskDialogIcon icon)
{
//   return ((int)icon).ToString();
   return null;
}

Die Funktion "GetIconValue" würde also den numerischen Wert von TaskDialogIcon liefern. Etwa 104 für Information. Also in etwa nach dem Prinzip, was

Delphi-Quellcode:

MAKEINTRESOURCEW(104)

bei der Delphi-Version machen würde. Aber das klappt nicht. Wo liegt mein Denkfehler?

[Elvis]

Zitat:

Zitat von MathiasSimmack

bei der Delphi-Version machen würde. Aber das klappt nicht. Wo liegt mein Denkfehler?

Dein Denkfehler ist, das du den String "104" übergibst, anstatt dem Integer 104.
Du bräuchtest im Import nicht einmal string als typen nehmen sondern einfach direkt TaskDialogIcon.
Sicherheitshalber könntest du TaskDialogIcon so deklarieren, dass es von Int32 "ableitet", aber wirklich nötig sollte das nicht sein. Enum sind ja per default 32Bit-Integer.
Ungetestet, aber es sollte so gehen:

Code:

[DllImport(Win32Libraries.ComCtl32, CharSet = CharSet.Auto, SetLastError = true)]
internal static extern void TaskDialog(IntPtr hwndParent,
                                       IntPtr hInstance,
                                       string pszWindowTitle,
                                       string pszMainInstruction,
                                       string pszContent,
                                       TaskDialogButtons dwCommonButtons,
                                       [MarshalAs(UnmanagedType.LPWStr)]
                                       TaskDialogIcon pszIcon,
                                       [In, Out] 
                                       ref int pnButton);


public enum TaskDialogIcon : int
{
    Blank = 100,
    Warning,
    Question,
    Error,
    Information,
    BlankAgain,
    Shield
}

[MathiasSimmack]

Die Anregung war prima. :thumb: Ich musste tatsächlich den (Feld)Marshal bemühen, allerdings so:

Code:

[DllImport(Win32Libraries.ComCtl32, CharSet = CharSet.Auto, SetLastError = true)]
internal static extern void TaskDialog(
   IntPtr hwndParent,
   IntPtr hInstance,
   string pszWindowTitle,
   string pszMainInstruction,
   string pszContent,
   TaskDialogButtons dwCommonButtons,
   [MarshalAs(UnmanagedType.U4)]
   TaskDialogIcon pszIcon,
   [In,Out] ref int pnButton);

Jetzt funktioniert es.

[MathiasSimmack]

Ich wollte übrigens noch verraten, dass sich das Rätsel mit der Checkbox auch erledigt hat. Wollt ihr wirklich den Grund wissen? Der typische Fall von "die rechte Hand weiß nicht was die linke macht". Rechte und linke Hand sind in dem Fall die Doku-Schreiber und die Programmierer bei Microsoft. :lol: Im SDK und im MSDN steht die Deklaration von "TaskDialogIndirect" so drin, wie ich es hier gezeigt habe. Tatsächlich fehlt da aber noch ein PInteger für die Radiobuttons:

Code:

HRESULT TaskDialogIndirect(
    const TASKDIALOGCONFIG *pTaskConfig,
    int *pnButton,
    int *pnRadioButton,
    BOOL *pfVerificationFlagChecked
);

Dadurch verschiebt sich der Parameter zum Prüfen der Checkbox um eine Stelle, und siehe da: nun klappt es. Und wo habe ich das gefunden? In einem CSharp-Sample im Windows SDK. :roll:


Aktuelles Projekt und aktueller Artikel liegen schon bei Luckie im Postfach und werden sicher auch bald online gehen.