[Gambas-user] Program producing constant load

[Rolf-Werner Eilert]

Am 20.04.22 um 16:33 schrieb T Lee Davidson:
> On 4/20/22 02:58, Rolf-Werner Eilert wrote:
>> Am 31.03.22 um 12:56 schrieb Rolf-Werner Eilert:
>>> Am 30.03.22 um 14:05 schrieb Bruce Steers:
>>>>
>>>>
>>>> On Wed, 30 Mar 2022 at 11:06, Rolf-Werner Eilert <rwe-sse at osnanet.de 
>>>> <mailto:rwe-sse at osnanet.de>> wrote:
>>>>
>>>>     Am 30.03.22 um 11:32 schrieb Benoît Minisini:
>>>>      > Le 30/03/2022 à 10:54, Rolf-Werner Eilert a écrit :
>>>>      >> For my office use, I made a remake of my calendar program.
>>>>      >>
>>>>      >> Everything running fine so far, but today I saw that when I 
>>>> have
>>>>     the
>>>>      >> program on the active screen, it produces a constant load of
>>>>     about 40
>>>>      >> % (the little faker on my desktop has 4 CPUs and Xosview says
>>>>     1.3 with
>>>>      >> the calendar visible).
>>>>      >>
>>>>      >> top says gbr3 is sucking CPU, but of course no more 
>>>> information.
>>>>      >>
>>>>      >> So my question is, how can I find out what is going on 
>>>> within my
>>>>      >> program? Obviously, there is one event which is fired over 
>>>> and over
>>>>      >> again.
>>>>      >>
>>>>      >> Regards
>>>>      >> Rolf
>>>>      >>
>>>>      >
>>>>      > gbx3 -t displays each ligne executed. It generates a lot of log
>>>>     in the
>>>>      > terminal, but you can see what the program runs exactly.
>>>>      >
>>>>      > Regards,
>>>>      >
>>>>
>>>>     Oh yes, that shows it clearly: There is a large gridview 
>>>> displaying the
>>>>     hours for each day. Obviously, the gridview constantly fires up the
>>>>     Data
>>>>     event which jumps into one function looking for the school 
>>>> holidays.
>>>>
>>>>     The question is, why is Data called over and over again?
>>>>
>>>>     This is an Ubuntu Mate and I chose gb.qt5 and gb.qt5.ext as 
>>>> libraries.
>>>>     May that be the reason? Or should I look for something else? I have
>>>>     other projects running with the same libraries here, they use 
>>>> Gridview
>>>>     as well, and they do not constantly fire the Data event.
>>>>
>>>>
>>>> Lets see the code.
>>>> I suspect there is some code causing the data event to trigger again 
>>>> within the data event.
>>>>
>>>> Like putting any instructions in a _Draw event that cause an object 
>>>> refresh will cause a recursive loop
>>>> BruceS
>>>>
>>>>
>>>>
>>>> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
>>>
>>> Here is a special version Kalender4-Test which uses a special 
>>> directory for its calendar data and should run on other systems too.
>>>
>>> You need the archive and the kaltes.tar.gz of the special directory. 
>>> Unpack or copy the latter to your $home as $home/.kalendertest/... It 
>>> contains only holiday data, everything else is left out, but it runs 
>>> this way and maybe shows the problem.
>>>
>>> Hope this helps!
>>>
>>> Regards
>>> Rolf
>>>
>>>
>>> ----[ http://gambaswiki.org/wiki/doc/netiquette ]----
>>
>> I wouldn't like to leave this open, so I add a report what came out.
>>
>> The real reason for this hassle couldn't be found, no-one seems to 
>> have been able to find the reason for the three calendar GridViews to 
>> fire Data events all the time.
>>
>> So I decided to re-write the Data events in a way the calendar data 
>> are written directly into the GridViews. At least this helped. When 
>> the calendar is visible now the CPU has holidays.
>>
>> I can only explain this with some of the VBox, HBox or whatever 
>> containers listening to - perhaps - mouse events or something like 
>> that and refreshing or arranging its contents over and over again.
>>
>> If someone finds the reason I would be glad to know as this might be 
>> helpful for the next project...
>>
>> Regards
>> Rolf
> 
> Rolf,
> 
> I replied to your thread and informed you what is causing the issue back 
> on April 1. Apparently, you did not get that message.
> 
> See:
> https://lists.gambas-basic.org/pipermail/user/2022-April/075722.html
> 
> 
Oh yes, I completely missed all these messages of 1 April, but they are 
here - thank you so much, I will try to solve it that way.

Regards
Rolf