0

I tried to make a while (work){....} inside button event called start to do some stuff like label changing in the same form with random values and I have another button called stop I want to make the work=false; so the while should be break

the problem is when I clicked start button and the form froze and did nothing how I can do that like stay in the while loop and access all other events

Olivier Jacot-Descombes
  • 104,806
  • 13
  • 138
  • 188
Steve Younes
  • 3
  • 1
  • Please explain what you're actually trying to achieve, rather than just how you're trying to achieve it, because the way you're trying to achieve it isn't going to work. – jmcilhinney Oct 20 '22 at 12:18

1 Answers1

1

As long as the loop runs, no events (like your other button's click) can be processed. This results in freezing the UI.

Better use a Timer instead of an infinite loop. The timer will not freeze the UI but call a Tick event at defined intervals and allow other events to be processed between two ticks. It is then easy for another button to stop this timer.

Since you have not mentioned any UI technology (is it WinForms, WPF, WebForms, MAUI, Xamarin, ...?) and not shown any code, it is difficult to give you example code.

Olivier Jacot-Descombes
  • 104,806
  • 13
  • 138
  • 188
  • It wouldn't result in freezing the UI if not done on the UI thread. – YungDeiza Oct 20 '22 at 12:33
  • 1
    @YungDeiza only the UI thread can update the UI. So your loop would have to post a message to the UI thread anyway, and you would not want to send to many messages, so you need some form of delay, and in the end you would just have made a very poorly implemented timer. So a standard timer is absolutely the way to go. – JonasH Oct 20 '22 at 12:36
  • @JonasH The whole loop doesn't need to run on the UI thread, if only the actions that update the UI are run on the UI thread, it wouldn't be blocked. If you do not really need to do many updates very frequently then you can add a delay to the loop. Timers are more resource intensive than while loops so may not be the best solution for short-lived events. – YungDeiza Oct 20 '22 at 13:18
  • The OP wants to display random values in a label. The timer interval can be chosen to be very short and then call `label.Resfresh()` to update the label immediately. – Olivier Jacot-Descombes Oct 20 '22 at 13:25
  • 1
    @YungDeiza "Timers are more resource intensive than while loops", eh? no? A dedicated thread would be more resource intensive than a timer. A background thread might be motivated if there is a lot of cpu processing needed, but creating a random value is in no way intensive enough to need a background thread. – JonasH Oct 20 '22 at 13:33
  • @JonasH where do the timers run -> on a different thread. Not saying Timers are bad but just that the loop is a perfectly viable option. – YungDeiza Oct 20 '22 at 13:59
  • @Olivier Jacot-Descombes that may result in overlapping actions running. Repeat - Not saying Timers are bad but just that the loop is a perfectly viable option. – YungDeiza Oct 20 '22 at 14:00
  • 2
    @YungDeiza I'm not sure about the internal details of timer implementations, But I would assume it is simply an entry in a OS maintained list that keeps track of all the timed work the OS needs to perform, and in the end the OS will use a hardware timer to do the actual signaling. I'm fairly sure it is *not* implemented as a loop on a thread, and that would *not* be a good option. And UI timers *do not* allow overlapping actions, all actions would be invoked on the UI thread, and a thread can only do one thing at a time. – JonasH Oct 20 '22 at 14:09
  • @JonasH, you're right about the UI thread preventing overlapping actions although you might get a lot queued up. I need to have a look at the Timer implementation, you might right about that. – YungDeiza Oct 20 '22 at 14:35
  • @JonasH, they seem to use threads according to a quick browse here: https://stackoverflow.com/questions/1416803/system-timers-timer-vs-system-threading-timer – YungDeiza Oct 20 '22 at 14:44
  • @YungDeiza I see nothing that indicates that any of the timers are implemented as a loop on a thread. As far as I can see, it mostly discuss what thread the 'Tick' event is invoked in, i.e. UI thread or threadpool thread. The actual timing mechanisms would still be provided by the OS. – JonasH Oct 20 '22 at 14:53
  • All things done in the UI thread (this is the thread you are in, if you do not do multitasking) cannot overlap! I.e., an event cannot interrupt a running event handler. New events are added to the message queue. When the user code (like a button click handler) has finished, the next message in the queue is processed. If the queue is empty, the application is idle and waits for the next message. This is how an event-driven UIs work. – Olivier Jacot-Descombes Oct 20 '22 at 15:26