Article View: pl.comp.lang.delphi
Article #294561Re: TOpenDialog i zawieszenie IDE
From: wloochacz
Date: Thu, 11 Jul 2019 12:53
Date: Thu, 11 Jul 2019 12:53
30 lines
1344 bytes
1344 bytes
W dniu 10.07.2019 o 14:22, Jan Drawski pisze: /ciach/ > Czyli ten sam OpenDialog w czystym programie działał już poprawnie? Na komputerach klienta czysty program nie działał poprawnie. I czysty program zżera pamięć na komputerach klienta. > Na > szybko spojrzałem i kiedyś jak mi coś nie działało to starałem się > skorzystać bezpośrednio z interfejsu IFileDialog, używałem też: > 1. TOpenFileName(OFN.Flags := OFN_EXPLORER or OFN_LONGNAMES or > OFN_FILEMUSTEXIST or OFN_PATHMUSTEXIST or OFN_HIDEREADONLY or > OFN_DONTADDTORECENT or OFN_FORCESHOWHIDDEN;) > 2. TBrowseInfo (browse_info.ulFlags := BIF_RETURNONLYFSDIRS;) > // or BIF_NEWDIALOGSTYLE; or BIF_USENEWUI; - not for multithreaded > 3.TFileOpenDialog (OD.Options := [fdoPickFolders];). Sprawa ma już dość czasu, aby nie pamięć szczegółów. Poza tym, szkoda mi było prądu na dokładne rozpoznanie "po co, na co i dlaczego". O ile dobrze pamiętam, to jeśli OpenDialog nie miał włączonego podglądu pliku to zachowywał się poprawnie i pamięć nie znikała w tempie katastrofalnym. Ja raczej stawiałem na jakiś ShellExtension, które oni mieli wszędzie poinstalowane (jakiś viewer w powłoce systemu dla plikow CAD/CAM), a którego my nie mieliśmy. Tak czy siak, metoda czołgowa zadziałała w moim przypadku idealnie. -- wloochacz
Message-ID:
<5d27153e$0$31099$65785112@news.neostrada.pl>
Path:
polish.pugleaf.net!archive.newsdeef.eu!apf1.newsdeef.eu!not-for-mail
References:
<65bcdba9-eabb-45aa-acb8-b6726c89a90f@googlegroups.com> <5d248d3c$0$541$65785112@news.neostrada.pl> <ce364576-2e21-42e7-bfb0-bb9206003e8a@googlegroups.com> <5d24a0b0$0$508$65785112@news.neostrada.pl> <5d25bd26$0$17346$65785112@news.neostrada.pl> <5d25d86e$0$525$65785112@news.neostrada.pl>