Fenster Datei öffnen unter Win10, nur vergrössern aber nicht verkleinern?

[Cypheros]

Dann lass ich die 1.2er XP-kompatibel und pack den aktuellen Dialog in die 2.0er. Dananch hatten sowieso schon einige Kunden gefragt.
Vielleicht fixt MS ja den Bug mit den XP-kompatiblen Dialogen noch.

Knöpfe bastle ich da nicht rein, nur Checkboxen und auch nur wenn die erweiterten Optionen beim Datei öffnen aktiviert sind, sonst fass ich das Fenster nicht an.

Hab das gerade mit einem Miniprogramm getestet, da ist das auch so. Hat nichts mit den Checkboxen zu tun.

Das liegt an der Manifestdatei, wo du festlegen kannst ob Theming verwendet wird oder nicht. Läßt Du die Manifestdatei weg, wird der XP-kompatible Dialog verwendet und Du kannst nicht verkleinern, was wiederum ein Bug in Windows 10 ist.

Siehe: Enabling Visual Styles

[Mam]

Hmmm

Was Du da so erzählst ist doch alles Schnee von Vor-Vorgestern, das gilt doch bei W10 gar nicht mehr!
Du brauchst kein Manifest mehr für die Visual Styles, Du brauchst auch nicht mehr den Aufruf Application::EnableVisualStyles(); beim Programmstart (er hatte eh nur einen Funktion bei Xp/2003, später war er nur Placebo).

Lässt man beides (ich hab gar kein Manifest zum Weglassen  ) weg, KOMMT DERSELBE DIALOG RAUS (und lässt sich auch schön resizen).

Es ist mir also recht schleierhaft, wie Du es schaffst, den anderen Kram hervorzulocken, ausser, Dein Delphi macht da irgendwas selber und nicht so ganz richtig.

Irgendwas ist faul im Staate Dääähnemarggggg...

Ich mach mal das Demo nochmal so richtig manuell, ohne Frameworks usw... (sche@²³²³ Tipparbeit...)

[Mam]

Grrr.. so langsam artet das in Arbeit aus, ohne, dass sich nur eine Deiner Aussage halbwegs bewahrheitet 

Also, hier nochmal von vorne: eine REINE W32 Applikation, nix managed, nix Framework, nix MFC, so richtig "Windows-zu-Fuß": (lauffähig ab Windows 3.1)

[attach=1]

Wie man sieht, "Visual Styles" kennt dieses Teil noch gar nicht, von Manifesten hat es auch noch nie im Leben gehört, ist ein rein statisch gelinktes EXE File...
(war mir zuviel Arbeit einen Button einzubauen, deshalb wird hier der Dialog über das Dateimenü oder ALT-O aufgerufen).
Was sehen wir?
DENSELBEN OpenFileName Dialog wie immer! MIT SKIN, RESIZABLE, OHNE BUGS!

Die "Umleitung" ist also voll transparent, funktioniert auch für Uraltprogramme.

Das bedeutet im Umkehrschluß, dass der Doc da aktiv was vermatschen muß, sonst würde er auch hier ankommen...

Und da hat nix mit irgendwelchen Manifesten zu tun!

[Cypheros]

OK, ich gebe auf. Du hast Recht, ich bin zu doof einen Datei-Dialog richtig aufzurufen.

15 Jahre lang hat es mit "If OpenDialog1.Execute = mrOK then" geklappt aber da hab ich er mir wohl zu einfach gemacht.

Da hätte ich lieber vor 15 Jahren mit VC angefangen und für die gleiche Funktion mindestens 2 Seiten programmiert, dann hätte ich das Problem jetzt nicht.

Was solls. Die nächste Version von TS-Doctor 2.0 nutzt den Vista-Dialog, sobald ich rausgefunden habe, wie ich da einen Zusatz-Button einbaue um die Einstellungen zu ändern.

[Mam]

OK, ich gebe auf. Du hast Recht, ich bin zu doof einen Datei-Dialog richtig aufzurufen.

15 Jahre lang hat es mit "If OpenDialog1.Execute = mrOK then" geklappt aber da hab ich er mir wohl zu einfach gemacht.

Selbst die Hardcorevariante ist da nicht komplizierter:

Code Auswählen Erweitern



case ID_FILE_OPENFILE:
if (RunOpenFile(hWnd)==true)
{
// User hat Namen ausgewählt
};
break;



Nö, der Aufruf ist richtig, mehr ist hier auch nicht nötig.
Der "Fehler" muß irgendwo im Umfeld liegen, in der Definition oder dem Teil, wo Du die Buttons reinbaust. Oder in dem Teil, wo Du die OPENFILE Struktur füllst ? (falscher "sizeof" Wert -> falsche Version des Dialogs!).

Code Auswählen Erweitern



BOOL RunOpenFile(HWND h)
{
OPENFILENAME ofn ;

ZeroMemory(&ofn, sizeof(ofn));

ofn.lStructSize = sizeof(ofn); //<<<<<<---- HIER lauert Gefahr! Bei mir ist das aktuell 152 (X64) und 88 (Win32)
ofn.hwndOwner = h;
ofn.lpstrDefExt = (LPCWSTR) "txt"; // this->DefaultExtension;
ofn.lpstrFile = FileName;
ofn.lpstrFile[0] = '\0';
ofn.nMaxFile = MAX_PATH;
//ofn.lpstrFilter = this->Filter;
//ofn.nFilterIndex = this->FilterIndex;
//ofn.lpstrInitialDir = this->InitialDir;
ofn.lpstrTitle = (LPCWSTR) L"W32 Test für den ollen Programmierhansel"; // this->Title;
ofn.Flags =  OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST; // this->Flags;

GetOpenFileName(&ofn);

if (_tcslen(FileName) == 0) return false;

return true;
}



Da hätte ich lieber vor 15 Jahren mit VC angefangen und für die gleiche Funktion mindestens 2 Seiten programmiert, dann hätte ich das Problem jetzt nicht.

Ich hab doch nur die Hardcore Variante gewählt um sicherzustellen, dass da nicht irgendwo unsichbar ein Framework "mir die Arbeit abnimmt" und Einstellungen vornimmt, die ich nicht kenne und nicht sehe. Ansonsten bin ich auch nicht mehr Masochist genug um mit reinem C und Win32 eine Anwendung zu erstellen, die komplexer ist, als ein Taschenrechner.
Aber "2 Seiten" ist, wie man oben sieht, stark übertrieben 
(allerdings ist das hier wirklich Trivialzeuchs, bei anderen Sachen kann man sich echt die Finger wundtippen)

Was solls. Die nächste Version von TS-Doctor 2.0 nutzt den Vista-Dialog, sobald ich rausgefunden habe, wie ich da einen Zusatz-Button einbaue um die Einstellungen zu ändern.

Versuch doch mal simpel vorher, KEINEN Button einzubauen und schau, was passiert!
Kommentier den Kram auf und ruf den Dialog ohne Extras auf.
Nur zum Test, nur für MAMi 

Und für weitere Tests solltest Du Folgendes in Erwägung ziehen:

An OFNHookProc hook procedure is an application-defined or library-defined callback procedure that is used with the Explorer-style Open and Save As common dialog boxes. The hook procedure receives notification messages sent from the common dialog box. The hook procedure also receives messages for any additional controls that you defined by specifying a child dialog template.

If you do not specify the OFN_EXPLORER flag when you create an Open or Save As common dialog box, and you want a hook procedure, you must use an old-style OFNHookProcOldStyle hook procedure. In this case, the dialog box will have the old-style user interface.

Das wäre mal ein Flag, dem man nachgehen sollte. Und es ist ja wohl auch kein Problem das Flag zu setzen, wenn man erkannt hat, auf Windows 10 zu laufen...

[Mam]

Also hier mal "des Rätsels Lösung":

Auch wenn Du es nicht hören willst: ES LIEGT AN DEINEN ZUSÄTZLICHEN CHECKBOXEN!

Sobald man bei dem Dialog angibt, eine eigene Erweiterung mit einschleifen zu wollen, IST RESIZING DEAKTIVIERT!

Code Auswählen Erweitern


          ofn.Flags =  OFN_HIDEREADONLY|OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST; // this->Flags;
          if (Yes) ofn.Flags |= OFN_EXPLORER|OFN_ENABLEHOOK;


Ist das Flag OFN_ENABLEHOOK gesetzt, ist kein Resize mehr möglich, ist OFN_EXPLORER gesetzt, so zeigt er den "normalen" Dialog an, ansonsten gibts nur viele Listboxen und Dropdownlisten, mit denen man sich durchklicken kann.

Lässt man den Hook weg, so ist alles wieder "normal", inklusive Resize.

(ich hab da nun ein Testprogramm, das BEIDE Versionen aufruft und somit den direkten Vergleich erlaubt)

Nach dem nächsten Kaffee schau ich mir mal an, was die neuen FlagsEx so machen, vielleicht ist da ja noch was drin...

Update: die ExFlags kannse vergessen.
Ich hab ein nettes Beispielprogramm von M$ gefunden, das zeigt alle Variationen des neuen (Vista) Dialogs und wie man da eigene Objekte mit einbaut. Leider sind die Originallinks schon wieder veraltet, man findet es aber noch hier: https://code.msdn.microsoft.com/CppShellCommonFileDialog-17b20409.
Leider in einer für Dich etwas kryptischen Sprache gehalten, aber ich geh mal davon aus, Du kriegst das schon hin 

Und wenn man es begriffen hat (also bei mir 3min später), siehts dann so aus:
[attach=1]

[Cypheros]

OK, habs hingekriegt mit den Vista-Dialogen. Ist zwar nicht schön aber es funktioniert. MS hat die die Klasse so gekapselt, dass man nur noch per Interface drauf zugreifen kann. Man kann zwar Buttons und Checkboxe hinzufügen aber nicht, wo und wie die erscheinen.

@Mam: Sollte aber nun gehen mit der Beta 14. Check mal.

[Mam]

ist ok und funktioniert einwandfrei 
(geht doch, wenn man lange genuch nachtritt  )

Das mit dem "nicht so schön" war ja wohl einer der Hauptgründe für M$ um den Dialog umzustellen. Die Templates vorher waren doof, da konnte man ja ALLES vergrützen, wenn man wollte. So ist wenigstens sichergestellt, dass die Grundfunktion und das Grundaussehen einheitlich sind, was dem Sinn des Namens "CommonDialog" ja irgendwie mehr entspricht.
Ausserdem fand ich den neuen Aufbau als Klasse mit netten Methoden zur Beeinflußung ausgesprochen angenehm (solange man nicht die Hardcore-Win32-C Ebene als Basis hat, da kämpfst Du dann gegen Windmühlen). Sollte doch wohl kein Problem gewesen sein, das Dingen einzubauen ? War vorher mit CallbackHook deutlich komplizierter und gefährlicher.

Mir ist übrigens noch ein möglicher Grund für das Versagen der alten Version eingefallen, wenn Du sportlichen Ehrgeiz hast, kannst Du ja mal nachschauen:
* ein großes Risiko der Template Version liegt in den RessourceIDs und der IDs der Usermessages.
* die IDs werden meist (wenn man faul ist) bei Erzeugung des Objektes vom Compiler vergeben, einfach durch Hochzählen.
* ursprünglich gab es mal den Hinweis "fang mit WM_USER" (irgendwas um die 5000) "an und zähl hoch". Irgendwann wurde das auch von M$ vergessen und man findet so tolle Sachen wie IDD_OK=1 und UserMessages mit 53
* im Laufe der Jahre (und Windowsversionen) brauchte M$ für interne Funktionen immer mehr dieser blöden 16Bit IDs für sich selber.
Es kann also passieren, dass beim Kompilieren von alter Software auf neuer Entwicklungsumgebung eine doppelte Vergabe der IDs passiert, kein Compiler kriegt davon was mit, da die IDs einfach DEFINES sind, und es natürlich keine Plausibilitätsprüfung gibt. Visual Studio zeigt Dir zwar ne Liste der selbstdefinierten IDs mit Namen und Werten, aber die Windowsdinger sind tief in den Headerfiles verborgen und nicht einzusehen.
Nehmen wir an, Du hast für Deinen Dialog eine Message IDM_MY_OWN_CHECKBOX_CLICKED definiert, die den Wert 4711 hat und seit Windows 10 gibt es eine "normale" Windowsmessage IDW_RESIZE_SMALLER mit ebenfalls dem Wert 4711. Deine Hookfunktion fängt die Nachricht 4711 ab, bearbeitet brav Deine Checkbox und quittiert auch brav die Nachricht. Damit gilt sie als "abgearbeitet" und wird nicht weiter an die DefWindowsProc() durchgereicht. Das Resize Kommando kommt also niemals dort an!
Musst mal mit nem Debugger den Dialog aufrufen und die Windows Messages mittracen.
(aber, nachdem Du ja jetzt erfolgreich den Weg des Updates beschritten hast, ist das nur akademische Kür)

[Mam]

Na ja, so einen kleinen Haken hat der "neue" Dialog doch noch: er wehrt sich erfolgreich gegen jegliche Skin-ning Attacken 

Sieht ein wenig "überraschend" aus, das so eine "dunkle" Anwendung auf einmal ein helles Fenster öffnet.
Da ich aber der Feind aller nutzlosen Skins bin, wäre ich froh, wenn man den Mist beim restlichen Doc auch gleich nachhaltig loswerden würde (jaja, ich weis, kann man abschalten (tut MAM auch  ), aber der Ballast wird trotzdem immer mit rumgeschleppt...).

Diese Skinseuche gehört abgeschafft (genau wie eine "graphische Ergänzung" die ich mal mit meinen Kumpels in der Jugend erfunden habe und die seit damals sich virulent verbreitet hatte und nur noch nervte. Zum Glück stirbt sie seit einigen Jahren langsam wieder aus)

@BossXxX: Dein "Problem" wird sich mit dem Update auf 2.x dann erledigt haben, stay tuned.

[BossXxX]

2.x nett, aber im moment ist nichts dabei was ich brauche, ich hasse neue Skins, neues Aussehen, ich mag keine Veränderungen.. also fällt das schon mal weg, und speed, ich hab hier nen doppelt raid, also von einem auf nen anderen raid, das ist mir schnell genug. reicht nicht mal um zwischen durch pippi zumachen

[Mam]

ich hasse neue Skins, neues Aussehen, ich mag keine Veränderungen...

Aaah, ein Ebenezer Scrooge unter uns! 

Sehr löblich, dass Du Dich dann auf das Windows-10-Risiko eingelassen hast, keine neue Skin, kein neues Aussehen und vor allen Dingen keine Veränderung 

[BossXxX]

das ist das andere leidige thema, das eine muss, das eine kann....

[Djfe]

der alte Doc ist auf ca. 30mb/s begrenzt, der neue kann locker auf 100-200mb/s auffahren, da ist die CPU dann der Flaschenhals (zumindestens bei meiner Kiste ^^)

[Mam]

da ist die CPU dann der Flaschenhals (zumindestens bei meiner Kiste ^^)

Nö, muss was anderes sein. Ich hab mal spaßeshalber (und weil ich dank böser Erkältung zeitweise taub war) die Kiste "hochgekitzelt", auch mit 5,3Ghz wurde es nicht mehr schneller (Normaltakt: 4,1Ghz OHNE Lüfter :-) ). Und 7 Cores waren dabei eh arbeitslos...

Bin mir also nicht so wirklich sicher, wo denn nun die Spaßbremse lauert...

[BossXxX]

bei mir ist der doc immer über 50 mb/s .....