🚀 go-pugleaf

W dniu 04.07.2019 o 12:13, goo-mlyny@ciach.net pisze:
> Telepie mi się po głowie, że temat był opisany i rozwiązany ale za nic nie mogę tego rozwiązania odszukać. Może ktoś ma lepszą pamięć?
> 
> W kodzie mam banalną konstrukcję:
>    dlg := TOpenDialog.Create(nil);
>    dlg.InitialDir := KatalogCel;
>    dlg.FileName := Cel;
>    try
>      if dlg.Execute() then  //na tej linii się zawiesza
> 
> Jak uruchamiam w IDE - to na tej linii IDE się zawiesza.
> To zjawisko występowało sporadycznie, ale jakoś od kilku dni występuje za każdym uruchomieniem. Delphi 10.3, system W10 64 bit.

   Może ten folder startowy KatalogCel to jakaś lokalizacja sieciowa lub inna, która przymula przy dostępie do niej
albo jest niedostępna?
   A może to okno dialogowe wyświetla się pod innym oknem (z ustawieniem "On top") lub na drugim (wyłączonym) monitorze
i czeka na Twoją reakcję?

A jak w eksploratorze chcesz wejść do tego folderu, to da się szybko?

-- 
Pzdr.
Marek

W dniu piątek, 5 lipca 2019 11:34:02 UTC+2 użytkownik Marek napisał:
>    Może ten folder startowy KatalogCel to jakaś lokalizacja sieciowa lub inna, która przymula przy dostępie do niej
> albo jest niedostępna?
nie - katalog jest lokalny, na C

>    A może to okno dialogowe wyświetla się pod innym oknem (z ustawieniem "On top") lub na drugim (wyłączonym) monitorze
> i czeka na Twoją reakcję?
nie, w 99% nic się nie wyświetla, ten 1% - wyświetli się tylko ramka od okna dialogowego


> A jak w eksploratorze chcesz wejść do tego folderu, to da się szybko?
Da się szybko, zresztą w mojej aplikacji też da się szybko (bez żadnego zawieszania się aplikacji), jeśli uruchomię ją poza IDE.

Użytkownik <goo-mlyny@ciach.net> napisał w wiadomości 
news:55249779-4fde-410d-9f4a-e740cce1b254@googlegroups.com...
...

> A jak w eksploratorze chcesz wejść do tego folderu, to da się szybko?
Da się szybko, zresztą w mojej aplikacji też da się szybko (bez żadnego 
zawieszania się aplikacji), jeśli uruchomię ją poza IDE.

Firewall?

-- 
marfi

> 
> > A jak w eksploratorze chcesz wejść do tego folderu, to da się szybko?
> Da się szybko, zresztą w mojej aplikacji też da się szybko (bez żadnego 
> zawieszania się aplikacji), jeśli uruchomię ją poza IDE.
> 
> Firewall?
> 
> -- 
> marfi

Witam.

Albo antywirus. Mi kiedyś podobne niespodzianki robił BitDefender... co prawda nie z OpenDialog'iem, ale był problem z dostępem do dysków spod IDE (zwłaszcza do C: ).

Pomagało uruchomienie Delphi w trybie administratora...

A z OpenDialog'iem miałem bardzo podobny problem (pokazywała się pusta ramka), ale w przypadku, kiedy próbowałem "przerobić" go dodając nowe opcje.

To tylko sugestie, ale może na coś naprowadzą?

Pozdrawiam
Sławek

W dniu wtorek, 9 lipca 2019 09:24:04 UTC+2 użytkownik sua...@gmail.com napisał:

> 
> To tylko sugestie, ale może na coś naprowadzą?
No nic - będę kombinował. Najgorzej mnie denerwuje, że pamiętam, że miałem już kiedyś ten problem, nie pamiętam rozwiązania, w necie jest też opisany, ale wszystkie linki do rozwiązania prowadzą w miejsca, których już nie ma...

W dniu 2019-07-04 o 12:13, goo-mlyny@ciach.net pisze:
> Telepie mi się po głowie, że temat był opisany i rozwiązany ale za nic nie mogę tego rozwiązania odszukać. Może ktoś ma lepszą pamięć?
> 
> W kodzie mam banalną konstrukcję:
>    dlg := TOpenDialog.Create(nil);
>    dlg.InitialDir := KatalogCel;
>    dlg.FileName := Cel;
>    try
>      if dlg.Execute() then  //na tej linii się zawiesza
> 
> Jak uruchamiam w IDE - to na tej linii IDE się zawiesza.
> To zjawisko występowało sporadycznie, ale jakoś od kilku dni występuje za każdym uruchomieniem. Delphi 10.3, system W10 64 bit.
> 
> Ktoś, coś?
> 
> Andrzej

Coś (część sugestii pewnie już była):
1. Program antywirusowy, firewall, spyware (kiedyś miałem problemy z 
SpyBootem). Czasami wyłączenie takiego programu nic nie daje bo jakiś 
serwis od niego dalej potrafi coś mieszać.
2. Sprawdenie jak jest na innych komputerach. Wtedy będzie wiadomo czy 
to wina kompa (też np. w katalogach, plikach może być coś skopane) czy 
softu.
3. Część OpenDialogów się sypie jak jest włączone o ile dobrze pamiętam 
"MULTITHREADED".
4. Zmiana lub ustawienie katalogu startowego.
5. Czy czysty projekt z takim OpenDialogiem dobrze działa? Może gdzieś 
nadpisujesz pamięć i efekty akurat tu widać albo jakaś biblioteka coś 
miesza.

-- 
Janek

W dniu wtorek, 9 lipca 2019 14:49:02 UTC+2 użytkownik Jan Drawski napisał:

> Coś (część sugestii pewnie już była):
> 1. Program antywirusowy, firewall, spyware (kiedyś miałem problemy z 
> SpyBootem). Czasami wyłączenie takiego programu nic nie daje bo jakiś 
> serwis od niego dalej potrafi coś mieszać.
> 2. Sprawdenie jak jest na innych komputerach. Wtedy będzie wiadomo czy 
> to wina kompa (też np. w katalogach, plikach może być coś skopane) czy 
> softu.
> 3. Część OpenDialogów się sypie jak jest włączone o ile dobrze pamiętam 
> "MULTITHREADED".
A możesz na ten temat coś więcej napisać, bo to mi trochę coś się kojarzy, ale nie mogę sobie przypomnieć istoty sprawy.

> 4. Zmiana lub ustawienie katalogu startowego.
Jeszcze posprawdzam, liczyłem, że ktoś ma mniejszą sklerozę, niż ja :)

> 5. Czy czysty projekt z takim OpenDialogiem dobrze działa?
W tej chwili działa źle, zrobiłem nowy projekt, tylko z wywołaniem OpenDialog i w IDE d...
Coś się zmieniło w ciągu ostatnich kilku tygodni, bo problemu jeszcze niedawno nie było, niestety nie potrafię żadnej zmiany skojarzyć...

>> "MULTITHREADED".
> A możesz na ten temat coś więcej napisać, bo to mi trochę coś się kojarzy, ale nie mogę sobie przypomnieć istoty sprawy.

Jak się korzysta z jakiegoś API Windows (nie pamiętam konkretnie przy 
czym) to MS zaleca korzystanie z tego. Ustawiam tak: CoInitializeEx(nil, 
COINIT_MULTITHREADED);
Google pewnie wie więcej na ten temat. Z niektórych komponentów nie 
można skorzystać, jest problem z parentami.

> Jeszcze posprawdzam, liczyłem, że ktoś ma mniejszą sklerozę, niż ja :)

Tak to jest jak się coś robi za szybko :)

>> 5. Czy czysty projekt z takim OpenDialogiem dobrze działa?
> W tej chwili działa źle, zrobiłem nowy projekt, tylko z wywołaniem OpenDialog i w IDE d...
> Coś się zmieniło w ciągu ostatnich kilku tygodni, bo problemu jeszcze niedawno nie było, niestety nie potrafię żadnej zmiany skojarzyć...

Wiem, że to może brzmieć trochę niedorzecznie ale możesz sprawdzić jak 
będzie przy nieaktywnym połączeniu z internetem. Czasami coś może się 
starać coś przesłać, odczytać i jak się nie udaje to mogą zdarzać się 
takie problemy. W WMI były takie niespodzianki.

-- 
Pozdrawiam
Janek

W dniu 09.07.2019 o 16:11, Jan Drawski pisze:
>>> "MULTITHREADED".
>> A możesz na ten temat coś więcej napisać, bo to mi trochę coś się 
>> kojarzy, ale nie mogę sobie przypomnieć istoty sprawy.
> 
> Jak się korzysta z jakiegoś API Windows (nie pamiętam konkretnie przy 
> czym) to MS zaleca korzystanie z tego. Ustawiam tak: CoInitializeEx(nil, 
> COINIT_MULTITHREADED);

Głównie chodzi o inicjalizowanie COMów.
Np. IXMLDocument albo jakieś ADO, albo dowolny inne coś działające jako 
Component Object Model.

> Google pewnie wie więcej na ten temat. Z niektórych komponentów nie 
> można skorzystać, jest problem z parentami.
> 
>> Jeszcze posprawdzam, liczyłem, że ktoś ma mniejszą sklerozę, niż ja :)
> 
> Tak to jest jak się coś robi za szybko :)
> 
>>> 5. Czy czysty projekt z takim OpenDialogiem dobrze działa?
>> W tej chwili działa źle, zrobiłem nowy projekt, tylko z wywołaniem 
>> OpenDialog i w IDE d...
>> Coś się zmieniło w ciągu ostatnich kilku tygodni, bo problemu jeszcze 
>> niedawno nie było, niestety nie potrafię żadnej zmiany skojarzyć...
> 
> Wiem, że to może brzmieć trochę niedorzecznie ale możesz sprawdzić jak 
> będzie przy nieaktywnym połączeniu z internetem. Czasami coś może się 
> starać coś przesłać, odczytać i jak się nie udaje to mogą zdarzać się 
> takie problemy. W WMI były takie niespodzianki.
> 
Miałem (może) podobny przypadek, ale jednak ciut inny.
Problem również dotyczył OpenDialog, ale zachowywało się to tak, że 
otwarcie OpenDialog powodowało, że proces który go odpalił masowo zżerał 
pamięć.
I to w tempie ok. kilku MiB na sekundę.
Tak czy siak normalna aplikacja umierała w kilkanaście minut od otwarcia 
OpenDialog z braku pamięci.

Nie znaleźliśmy rozwiązania i w końcu zdecydowałem, że napiszemy sobie 
taki wrapper na OpenDialog (jako osobny program/proces), którego jedynym 
zadaniem jest obsługa OpenDialog.

Ciekawe jest to, że takie zachowanie było tylko u jednego klienta, ale 
na wszystkich jego komputerach.


-- 
wloochacz

> Miałem (może) podobny przypadek, ale jednak ciut inny.
> Problem również dotyczył OpenDialog, ale zachowywało się to tak, że 
> otwarcie OpenDialog powodowało, że proces który go odpalił masowo zżerał 
> pamięć.
> I to w tempie ok. kilku MiB na sekundę.
> Tak czy siak normalna aplikacja umierała w kilkanaście minut od otwarcia 
> OpenDialog z braku pamięci.
> 
> Nie znaleźliśmy rozwiązania i w końcu zdecydowałem, że napiszemy sobie 
> taki wrapper na OpenDialog (jako osobny program/proces), którego jedynym 
> zadaniem jest obsługa OpenDialog.
> 
> Ciekawe jest to, że takie zachowanie było tylko u jednego klienta, ale 
> na wszystkich jego komputerach.

Czyli ten sam OpenDialog w czystym programie działał już poprawnie? 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];).

-- 
Janek

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

> 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.
Tez bym celował ze to bedzie to.

Najszybsza metoda aby to sprawdzić to wyłączyć wszystko co 
niestandardowe za pomoca programu Autoruns (ze stajni Sysinternals)
na zakładce Explorer

M