Zmiana rozmiaru TOpenDialog

Mam w programie komponent TOpenDialog i wszystko działało dobrze, ale zmieniłem komputer i teraz występuje dziwne zjawisko: okno dialogowe da się zwiększyć, ale nie da się zmniejszyć. Rozmiar jest pamiętany nawet po zrestartowaniu komputera.
Na starym komputerze był Windows7, na nowym jest Windows10. Ten sam program (ta sama kopia exe) uruchamiana na starym komputerze pozwala dowolnie modyfikować rozmiar okna, a uruchamiana na nowym - pozwala je tylko rozszerzyć.

Stąd dwa pytania: pierwsze - jak sobie z tym poradzić. Drugie, bardziej ogólne: gdzie są zapisywane rozmiary okna TOpenDialog pomiędzy sesjami programu.

Nie mam 10tki, więc nie umiem pomóc. Według mnie OpenDialog chyba zawsze da się regulować rozmiarowo. Co do zapisu to ogólnie ostatni katalog i rozmiary czy układ Open lub SaveDialogu, o ile dodatkowo nie przetwarza tego program - przez system zapisywane jest w tej lokalizacji Rejestru HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32, a dla konkretnego typu pliku w tej lokalizacji w podkluczu ...OpenSavePidlMRU.

Tylko do przeglądania polecał bym na przykład darmowy FileManager FAR, ponieważ pod jego pluginem do edycji Rejestru, można sobie podejrzeć dane i widać coś więćej niż Hexy. Ja na przykład ostatnio namieszałem sobie w Windows 7 na tyle, że usunęła się mi większość gałęzi HKEY_CURRENT_USER\Software. Przez to też programy "zapomniały" o domyślnych dla mnie ustawieniach Open/SaveDialogów.

Na przykład VirtualDub nie umiał spamiętać osobnej śćieżki dla plików *.vdscript, a osobnej dla zapisywania wyedytowanych plików *.avi usunięcie tego podklucza i ponowne otwarcie plików i zapis pomogło i teraz już pamiętam. Więcej może doradzi Tobie tutaj jeszcze ktoś inny.

EDIT: a sotty, jest jeszcze opcja ofEnableSizing, może dla pewności zawsze przy tworzeniu OpenDialogu/Formatki go używającej ustawiać wszystkie flagi jakie sobie życzysz, bo może Windows 10 bez tego "olewa" tę flagę i ustawia ją domyśłnie na False przez co dialogu nie da się właśnie resizować. Może spóbuj też poza wywołaniem komonentu na próbę zrobić testowy Open/SaveDialog w WinAPI. W załaczniku masz przykładowy kod tworzony pod Delphi 7, powinno się dać zaadaptować do nowszych Delphi.

Takie rzeczy jakie opisuje @ihuarraquax faktycznie dzieją się pod Windows 10...

Sam miałem taki przypadek, raz zmaksymalizowane okno dialogowe SaveDialog nie da się zmniejszyć/przywrócić; Dotyczy to programu do zarządzania sklepem - nie wiem w jakim języku go pisali; W każdym razie jak na laptopie był Windows 8.1 (oryginalnie) to wszystko działało dobrze - okienko SaveDialog można było przesuwać i zmieniać jego rozmiar; Po aktualizacji systemu do Windows 10 też chwilę działało dobrze, aż pewnego razu okienko SaveDialog pokazało się rozciągnięte na cały ekran i nie ma możliwości zmienić jego rozmiaru; Można klikać podwójnie na belkę czy próbować myszą zmniejszyć rozmiar (kursor poprawnie zmienia się np. na crSizeNS itd.), ale to nic nie daje;

Mnie to na bug powłoki wygląda, bo widać nie jest to zależne od języka programowania; Systemowe okna dialogowe nie mają przecież przycisków maksymalizacji, a ten dialog właśnie tak się zachowuje, jakby został zmaksymalizowany i nie daje się z powrotem zmniejszyć.

Dzięki. W sumie to dobra wiadomość, że problem występuje nie tylko u mnie, bo jeśli rzeczywiście jest powszechniejszy i do tego związany z Windows 10, to jest nadzieja, że przy którejś aktualizacji systemu wszystko samo wskoczy na swoje miejsce. Już tak miałem. Bezskutecznie walczyłem o małe ikony na pulpicie (które uparcie powracały do rozmiaru średniego) - pewnego dnia same zrobiły się małe. Bezskutecznie próbowałem usunąć wadliwy kafelek z ekranu startowego - któregoś dnia sam zniknął. W obu przypadkach - po aktualizacji.

A tymczasem robię eksperymenty, i doszedłem do czegoś takiego (może komuś się przyda): jeśli programowi (exe) zmienić nazwę, to od nowa mam okno TOpenDialog w sensownym rozmiarze. I znowu mogę je rozciągać, nie mogąc zwęzić, ale jakby co, to zawsze mogę dodać kolejną literę do nazwy. Bo to naprawdę irytujące, jak plik wybieram w lewym górnym rogu ekranu, a OK klikam w prawym dolnym, zwłaszcza jeśli muszę tę operację wykonywać setki razy.

Oczywiście jakby ktoś miał jeszcze jakiś pomysł na rozwiązanie bez czekania na niewidzialną rękę Microsoftu, to napiszcie.

Trzeba by sprawdzić, czy okna otwarte przez WinAPI (GetOpenFileName i GetSaveFileName) tak samo się zachowują.

Dlatego też dołączyłem kod WinAPI. Mogą przetestować. A co do tego, że przy innej nazwie exeka rozmiar wraca do domyślnego. To zapomniałem wspomnieć. Iż w podanej poprzednio przeze mnie lokalizacji rejestru we wpisach jako hex są też podane nazwy pliku wykonywalnego z open/savedialogiem i ścieżki do lokalizacji wybranego pliku.

A może jakieś takie drutowanie by Ci w czymś pomogło:

procedure TForm1.Timer1Timer(Sender: TObject);
var
  r: TRect;
begin
  if not (Hnd = INVALID_HANDLE_VALUE) then
  begin
    GetWIndowRect(Hnd, r);
    if (r.Width > 700) or (r.Height > 700) then
      SetWindowPos(Hnd, HWND_TOP, 0, 0, 600, 600, SWP_NOMOVE)
    else
      Timer2.Enabled := False;
  end;
end;

Uchwyt pobrany w OnShow (wcześniej ma wartość 0 i można narozrabiać w systemie):

Hnd := GetParent(OpenDialog.Handle);

Nie znalazłem na szybko komunikatu przy którym SetWindowPos by odniosło pożądany efekt.
Nie testowałem tego na Win 10 tylko na Win 8.1 ale może...

Sprawdziłem. Standardowy dialog i dialog Olesia zachowują się inaczej (dialog Olesia resizuje się bez problemu) i, co ciekawsze, inaczej wyglądają na ekranie. W załączniku projekt i dwa zrzuty.

Poprawka. Zaktualizowałem załącznik. Poprzednio zbyt pospieszyłem się.

Metodą prób i błędów zmieniałem (skopiowane pod inną nazwę) Dialogs.pas, a dokładnie DoExecute objektu TSaveDialog i doszedłem do pewnych wniosków. Jak zakomentuję linię

    Flags := OFN_ENABLEHOOK; 

oraz fragment

   if (ofOldStyleDialog in Options) or not NewStyleControls then
      lpfnHook := DialogHook
    else
      lpfnHook := ExplorerHook; 

i w końcu zamiast

     Result := TaskModalDialog(Func, OpenFileName);

wstawię

 Result := GetSaveFileName(OpenFileName);

to opisany w tym wątku objaw znika. Czy reszta działa tak, jakbyśmy chcieli, to nie wiem. I nawet nie mam pomysłu, co sprawdzać.