🚀 go-pugleaf

Dodatkowo jeszcze ustaliłem że błąd pojawia się kiedy wątek poboczny chce coś zmienić w formie głównej za pomocą Synchronize() 
a błąd występuje w bibliotece ExtCtrls w procedurze TTimer.UpdateTimer;

> Dodatkowo jeszcze ustaliłem że błąd pojawia się kiedy wątek poboczny chce coś zmienić w formie 
> głównej za pomocą Synchronize()
> a błąd występuje w bibliotece ExtCtrls w procedurze TTimer.UpdateTimer;

Ilość timerów dostępnych na raz dla aplikacji jest mocno ograniczona. XDBGrid również używa timerów,
ale tworzy je i niszczy dynamicznie, czyli istnieją tylko wtedy, gdy coś odliczają, a potem są 
niszczone (zwalniają handle).

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/

> Ilość timerów dostępnych na raz dla aplikacji jest mocno ograniczona. 
> XDBGrid również używa timerów,
> ale tworzy je i niszczy dynamicznie, czyli istnieją tylko wtedy, gdy coś 
> odliczają, a potem są niszczone (zwalniają handle).
> 

Mały eksperyment,  tworzę timery w pętli.
Wyjątek pojawił sie trochę przed 5000 a limitem okazałą się ilość 10.000 
"USER Object"


A tutaj tez ktoś o tym napisał
https://blogs.msdn.microsoft.com/oldnewthing/20090827-00/?p=16963

Czyli poszedł bym tropem sprawdzenia zużycia zasobów

M

W dniu środa, 24 stycznia 2018 16:28:51 UTC+1 użytkownik Krzysztof Szyszka napisał:
> > Dodatkowo jeszcze ustaliłem że błąd pojawia się kiedy wątek poboczny chce coś zmienić w formie 
> > głównej za pomocą Synchronize()
> > a błąd występuje w bibliotece ExtCtrls w procedurze TTimer.UpdateTimer;
> 
> Ilość timerów dostępnych na raz dla aplikacji jest mocno ograniczona. XDBGrid również używa timerów,
> ale tworzy je i niszczy dynamicznie, czyli istnieją tylko wtedy, gdy coś odliczają, a potem są 
> niszczone (zwalniają handle).
> 

Ale skąd to ograniczenie wynika?
To system narzuca czy środowisko Delphi - czy może jakieś deklaracje wielkości używanej pamięci w projekcie?

W dniu środa, 24 stycznia 2018 19:51:10 UTC+1 użytkownik mmm napisał:
> > Ilość timerów dostępnych na raz dla aplikacji jest mocno ograniczona. 
> > XDBGrid również używa timerów,
> > ale tworzy je i niszczy dynamicznie, czyli istnieją tylko wtedy, gdy coś 
> > odliczają, a potem są niszczone (zwalniają handle).
> > 
> 
> Mały eksperyment,  tworzę timery w pętli.
> Wyjątek pojawił sie trochę przed 5000 a limitem okazałą się ilość 10.000 
> "USER Object"
> 
> 
> A tutaj tez ktoś o tym napisał
> https://blogs.msdn.microsoft.com/oldnewthing/20090827-00/?p=16963
> 
> Czyli poszedł bym tropem sprawdzenia zużycia zasobów
> 
> M

ok. to widzę już że to ograniczenie systemowe, problem w tym że raczej nie jest możliwe żebym tyle zegarów tworzył...
Statycznych mam ~15, dynamicznych też raczej wiele nie ma, gridy jeśli tworzą na chwilę to w jednym czasie odświeżam góra 3 ...

A inaczej - można to jakoś sprawdzić ile program obecnie używa?

> 
> A inaczej - można to jakoś sprawdzić ile program obecnie używa?
> 
https://docs.microsoft.com/pl-pl/sysinternals/downloads/process-explorer

M

W dniu środa, 24 stycznia 2018 16:28:51 UTC+1 użytkownik Krzysztof Szyszka napisał:
> > Dodatkowo jeszcze ustaliłem że błąd pojawia się kiedy wątek poboczny chce coś zmienić w formie 
> > głównej za pomocą Synchronize()
> > a błąd występuje w bibliotece ExtCtrls w procedurze TTimer.UpdateTimer;
> 
> Ilość timerów dostępnych na raz dla aplikacji jest mocno ograniczona. XDBGrid również używa timerów,
> ale tworzy je i niszczy dynamicznie, czyli istnieją tylko wtedy, gdy coś odliczają, a potem są 
> niszczone (zwalniają handle).

Coś mnie tknęło żeby pociągnąć temat XDBGrida i tutaj znalazłem punkt zaczepienia.

1. Problem występuje kiedy wczytanie danych realizowane jest przez wątek poboczny. Przy prostym Active := False / True - nie ma problemu 

2. Problem jest związany z kolumną w XDBGrid który wyświetla dane odświeżanego DataSet'a, a dokładnie wyjątek występuje od chwili kiedy do XDBGrida dodałem kolumnę nie podlinkowaną do żadnego pola DataSet'a a jedynie służącą do oznaczania rekordów CheckBox'ami (CheckBox := True)

Kiedy usunąłem tą kolumnę problem przestał występować.

- pytanie więc czy coś źle konfiguruję tą kolumnę? (wyłącznie dodanie kolumny i zmiana CheckBox := True)

W dniu 2018-01-25 o 14:45, ExM pisze:
/ciach/

To trochę OFF topikowo, ale timery są be.
Lepszym, i to zdecydowanie, patentem jest throttling/debouncing events, 
czyli programowania reaktywne.
Kto był na zlocie, to może zakodował:
http://delphi.pl/zlot/zlot2017/prezentacje/ReactiveX_SG.pdf

A mamy i dla Delphi port ReactiveX:
https://bitbucket.org/sglienke/spring4d/src/638cae2c3a7a32db87f3a17bc7ce2c6b27472b0c/Source/Reactive/?at=feature/1.3-rx

I jakiś (nie tykałem) poza Springowy:
https://github.com/Purik/RxDelphi

Używać czy nie, to zależy.
Ale zaprzyjaźnić się z tym paradygmatem i go poznać zdecydowanie warto, imo.

-- 
wloochacz

> Coś mnie tknęło żeby pociągnąć temat XDBGrida i tutaj znalazłem punkt zaczepienia.
>
> 1. Problem występuje kiedy wczytanie danych realizowane jest przez wątek poboczny. Przy prostym
> Active := False / True - nie ma problemu
>
> 2. Problem jest związany z kolumną w XDBGrid który wyświetla dane odświeżanego DataSet'a, a
> dokładnie wyjątek występuje od chwili kiedy do XDBGrida dodałem kolumnę nie podlinkowaną do
> żadnego pola DataSet'a a jedynie służącą do oznaczania rekordów CheckBox'ami (CheckBox := True)
>
> Kiedy usunąłem tą kolumnę problem przestał występować.
>
> - pytanie więc czy coś źle konfiguruję tą kolumnę? (wyłącznie dodanie kolumny i zmiana CheckBox :=
> True)

Kolumnę z CheckBoxem konfigurujesz dobrze, bo tu nie można nic popsuć :-) Fakt, że kolumna
z CheckBoxem nie ma podlikowanego pola z DataSet wcale nie oznacza, że ona nic nie robi ;-)

Paradoksalnie, ona robi (w tle) znacznie więcej, niż kolumna z polem z DataSet, bo żeby pokazać stan
CheckBoxa musi za każdym razem pobrać z DataSet bookmark wyświetlanego rekordu i sprawdzić,
czy jest on na liście SelectedRows. Usuwasz kolumnę z CheckBoxem, to usuwasz również jedno
z intensywnie używanych w tle połączeń kontrolki VCL z DataSet.

A przyczyna problemów leży prawdopodobnie w tym, o czym już było w Twoim innym wątku:
"Problem z synchronizacją wątków i DB". Moje zdanie na ten temat znasz, bo je tam napisałem.
Jak masz szczęście, to wszystko (niby) działa, nie masz szczęścia, to szukasz przyczyn głupich
błędów.


-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/ 

> To trochę OFF topikowo, ale timery są be.
> Lepszym, i to zdecydowanie, patentem jest throttling/debouncing events, czyli programowania 
> reaktywne.

A możesz mi napisać, jak bez Timera można zareagować na zdarzenie, które nie nadchodzi w określonym 
czasie?

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/

On Thu, 25 Jan 2018 18:20:31 +0100, Krzysztof Szyszka wrote:

>> To trochę OFF topikowo, ale timery są be.
>> Lepszym, i to zdecydowanie, patentem jest throttling/debouncing events, czyli programowania 
>> reaktywne.
> 
> A możesz mi napisać, jak bez Timera można zareagować na zdarzenie, które nie nadchodzi w określonym 
> czasie?

Np. tak:

https://jonlennartaasenden.wordpress.com/2016/11/23/delayed-execution-for-delphi/

-- 
pozdrawiam
Roman Tyczka

> Używać czy nie, to zależy.
> Ale zaprzyjaźnić się z tym paradygmatem i go poznać zdecydowanie warto, 
> imo.
> Jakiej wersji Delphi wymagają te projekty co podałeś ?
Bo sprawdziłem na "10.1 update 1" i sypało problemami przy kompilacji 
przykładów.

M

W dniu 2018-01-25 o 22:13, Roman Tyczka pisze:

> https://jonlennartaasenden.wordpress.com/2016/11/23/delayed-execution-for-delphi/
>

Pytanie jak efektywne jest to podejscie. Repeat ze sleepem 1ms może 
trochę zjadać CPU.


-- 
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

> >> To trochę OFF topikowo, ale timery są be.
> >> Lepszym, i to zdecydowanie, patentem jest throttling/debouncing events, czyli programowania
> >> reaktywne.
> >
> > A możesz mi napisać, jak bez Timera można zareagować na zdarzenie, które nie nadchodzi w
> > określonym
> > czasie?
>
> Np. tak:
>
> https://jonlennartaasenden.wordpress.com/2016/11/23/delayed-execution-for-delphi/

Skoro już piszesz jako "adwokat diabła" i podajesz linka, to może pokusiłbyś się o jakiś komentarz?

Jakoś nadal nie widzę tu żadnych zalet, żeby zamiast prostego timera w głównym wątku, uruchamiać
osobny wątek do odliczania czasu zakończony callbackiem, szczególnie wtedy, gdy po upływie czasu
zamiast banalnego ShowMessage, trzeba wykonać jakieś złożone zadanie w głównym wątku.

Zresztą sam autor na wstępie napisał, że jest to realizacja funkcji windowsowego Timera dla
systemów, które go nie posiadają, żeby mógł przenieść swoją bibliotekę z VCL na FMX:

"Now I did make a version of this library earlier which was VCL only (using the Windows API)
but lately I decided to upgrade it to use threads – and thus the library is now platform independent
and FMX compatible."


-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/ 

On Fri, 26 Jan 2018 21:04:31 +0100, Krzysztof Szyszka wrote:

>>>> To trochę OFF topikowo, ale timery są be.
>>>> Lepszym, i to zdecydowanie, patentem jest throttling/debouncing events, czyli programowania
>>>> reaktywne.
>>>
>>> A możesz mi napisać, jak bez Timera można zareagować na zdarzenie, które nie nadchodzi w
>>> określonym
>>> czasie?
>>
>> Np. tak:
>>
>> https://jonlennartaasenden.wordpress.com/2016/11/23/delayed-execution-for-delphi/
> 
> Skoro już piszesz jako "adwokat diabła" i podajesz linka, to może pokusiłbyś się o jakiś komentarz?

Nie jestem adwokatem żadnego diabła, grupa jest publiczna to się
udzieliłem. A co do komentarza... co tu komentować? Autor sam skomentował.
 
> Jakoś nadal nie widzę tu żadnych zalet, żeby zamiast prostego timera w głównym wątku, uruchamiać
> osobny wątek do odliczania czasu zakończony callbackiem, szczególnie wtedy, gdy po upływie czasu
> zamiast banalnego ShowMessage, trzeba wykonać jakieś złożone zadanie w głównym wątku.

Nie twierdzę, że to coś lepszego od timera tylko alternatywa skoro timery
mają ograniczenia.
Poza tym od ponad dekady mamy procesory z coraz większą liczbą rdzeni, dziś
już single core szukać ze świecą, za to cały świat teraz narzeka, że
software nie nadąża za hardwarem, bo programiści nie korzystają z
wielordzeniowości, więc... korzystajmy :-)
 
> Zresztą sam autor na wstępie napisał, że jest to realizacja funkcji windowsowego Timera dla
> systemów, które go nie posiadają, żeby mógł przenieść swoją bibliotekę z VCL na FMX:
> 
> "Now I did make a version of this library earlier which was VCL only (using the Windows API)
> but lately I decided to upgrade it to use threads – and thus the library is now platform independent
> and FMX compatible."

No nie, on napisał, że zrobił to dlatego, że w SMS miał takie rozwiązanie i
brakowało mu go w Delphi. A dopiero potem przerobił z WinAPI tak, że stało
się multiplatformowe.

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-01-26 o 18:29, Piotr Rezmer pisze:
> W dniu 2018-01-25 o 22:13, Roman Tyczka pisze:
> 
>> https://jonlennartaasenden.wordpress.com/2016/11/23/delayed-execution-for-delphi/ 
>>
>>
> 
> Pytanie jak efektywne jest to podejscie. 
Bardziej, niż wystarczajaco.

> Repeat ze sleepem 1ms może trochę zjadać CPU.
Z tego co wiem, czytałem i testowałem, jest dokładnie odwrotnie.

-- 
wloochacz