Thank you Mirek and good job! As previously in addition ot SourceForge release I created release on GitHub:
- https://github.com/ultimatepp/ultimatepp/releases/tag/2023.2

Another, related issue is with TimeCallback that does not work at all in that same window either. Not even before using the context menu.

Unfortunately, this is a very complex program and I have not yet been able to build a separate test case to demonstrate the issue. Simple test cases do not reproduce this issue.

Also, make sure that all other timer (and GUI in general) lambdas are with [=]....
You should only use [&] if you are sure that lambda is invoked immediately (e.g. with CoDo).

Hi Mirek

These sentences are very interesting.
Quote:

Also, make sure that all other timer (and GUI in general) lambdas are with [=]....
You should only use [&] if you are sure that lambda is invoked immediately (e.g. with CoDo).

I almost understand why you say that but, for didactic reasons, could you explain why to include capture by value rather than by reference.

struct MyApp ... {
   Button btn;
   String a;
   ...
};

void MyApp::MyApp()
{
    String b;
    btn << [&] { a = b; };
}

Hi,

It does not make difference if I use [=] here. However, I would not dare to point to local temporary variables with timer anyway. Instead, my timer sets are mostly of type

timer.Set(THISBACK(UpdateRoutine));

In that case the reference is all about using 'this'.

INTERESTINGLY: The entire timer system freezes when I open the secondary window. Ctrl::TimerProc() does not get called at all until I close that secondary window.

UPDATE: While the secondary window is open, there is not a single WM_TIMER coming into Ctrl::UtilityProc(). The execution of thread is not frozen within TimerProc() though. Windows is just no longer sending WM_TIMER messages in.

Best regards,

Tom

koldo wrote on Wed, 15 November 2023 08:38

Hi Mirek

These sentences are very interesting.
Quote:

Also, make sure that all other timer (and GUI in general) lambdas are with [=]....
You should only use [&] if you are sure that lambda is invoked immediately (e.g. with CoDo).

I almost understand why you say that but, for didactic reasons, could you explain why to include capture by value rather than by reference.

struct MyApp ... {
   Button btn;
   String a;
   ...
};

void MyApp::MyApp()
{
    String b;
    btn << [&] { a = b; };
}

This creates a dangling reference to b. In fact, if the lambda execution is not 'immediate' (before next statement basically), in most of GUI cases it makes only sense to work with member variables (e.g. 'a' in this case). But then, [=] in fact captures 'this' and that is likely MORE efficient than capturing all member variables individually.

Note that capturing this by [=] was deemed confusing by C++ comittee and they tried to improve on it with [=, this], unfortunately currently it is hard to make code compatible both ways.

Mirek

[=] in fact captures 'this'