In a windows desktop application (windows forms), I've created a while loop in (c#):
bool stop = false;
while (!stop){
...
// code to update a label that displays the number of times the loop executed.
...
}
When a button is clicked, "stop" is made true and the loop will stop.
However, I don't get the chance to click the button after the application runs because it becomes unresponsive.
that's one thing.
The other thing that puzzles me more is why the label is not showing the number of loops. It's like the program is just looping and doing nothing.
If you are wondering, I'm trying to write code for a game loop.
Windows applications work by responding to Windows messages.
All WinForms events actually come from Windows messages like WM_PAINT or WM_MOSUEMOVE.
The .Net Framework's Application class runs a message loop which asks Windows for the next message, then processes the message as appropriate.
For example, if the user clicks a button, Windows sends your program a WM_CLICK message. .Net's message loop converts this into a Click event and runs any event handlers that you registered.
While your code is running, the application is busy responding to whatever message it received, and it cannot respond to messages.
Therefore, it appears frozen.
You should replace your loop with a Timer component.
Move the loop body into the Tick handler and set the Interval to something like 20 or 50.
Related
I am developing an app in uwp where I dont want to exit the application on back button click(on mobile).Instead of exiting I want to run it in background(it also uses a timer which triggers every 5 second).
Could anybody please help me on this.
Thanks..
A few things to mention:
A UWP app does not exit on pressing back button. It generally goes into a suspended state. It starts running in background only if you have registered a background task.
A background task can be triggered using a time trigger. But the minimum time period between 2 triggers is 15 minutes. So, you might want to look into some other to handle this.
You might want to look at these if you want to understand more clearly
https://blogs.windows.com/buildingapps/2016/04/28/the-lifecycle-of-a-uwp-app/
https://blogs.windows.com/buildingapps/2016/06/07/background-activity-with-the-single-process-model/
I want to get event when windows store app is closing or page is closing same way as we get "Closing" event in Desktop application.
Can anybody suggest me?
Try this:- https://msdn.microsoft.com/en-us/library/windows/apps/hh986968.aspx
refer:- How to save data on Windows Store App Close?
If you look at the very first figure, you can see that there are only 3 events related to application lifecycle:
Activated - Raised when program first starts
Suspended - Raised when program is suspended (i.e. the user returns to the Start Screen or another app)
Resuming - Raised when the program is awakened from its suspended state.
The fourth transition - the one to the "Not Running" state - has no such notification event. The reason is: you don't really know when the app will fully close. Nor should you - Microsoft wants you to perform all of your state-saving logic in the transition from "Running" to "Suspended." In this way, they can free up resources when they deem necessary.
Even if the user forces the program to terminate (by right-clicking it and selecting "Close" from the task menu), you will enter the "Suspended" state for exactly 10 seconds before the program is terminated. So you can rest easy that your state-saving logic will always be executed.
I have a large WPF app with few threads ( all threads use dispatcher.invoke to update the GUI) and many grids and controls. At any give time only 2 or three grids are visible so the user can interact with the controls. I also have an external device which sends a signal to my app and I then update the GUI so the user knows the signal was fired.
I do the update through a dispatcher since the signal detection is on another thread. So everything is fine until intermittently it takes 5 minutes for the dispatcher.invoke with normal priority to call my method. when this happens as soon as I click the GUI then method gets called immediately. So it seems that message pump is asleep or hung and as soon as I click on the GUI it wakes up and process my message. I have done this several times so I am sure that message queue wakes up upon refreshing the GUI.
So is this a bug in WPF message pump queue where it occasionally goes to sleep and wakes up when the GUI is refreshed? or what is the reason for this behavior and what to do about it.
Thanks in advance
Is the ScrollToCaret in WinForms buggy?
I have a server that processes messages, a server that allows irc style communication.
I'm working on a WinForms gui that interacts with the server.
The WinForms gui has a component that does reads/writes to the newtork. This component launches a thread to do continuous reading (receive) on the socket. This thread takes a delegate that allows the read message to be processed right away instead of being placed on an internal read queue that is built into the component. Then I have the main form that shows chat messages received and sent, among other things. Chat messages are stored in a RichTextBox. The chat log is update via method of the main form:
private void UpdateChatWindow(string text)
{
lock (rtxt_msgLog)
{
rtxt_msgLog.Text += Environment.NewLine + text;
rtxt_msgLog.SelectionStart = rtxt_msgLog.Text.Length;
rtxt_msgLog.ScrollToCaret();
}
}
The above method is called from the main form as well as the thread that does the continuous reading of a socket.
If I have one GUI window open, the msgLog updates fine, scrolls to bottom. Focus() is not an issue, as the RichTextBox is never in focus as indicated by Focused property which always returns 'false'.
Weirdness stars when I launch a second GUI and log into the server. I start receiving
on the first GUI launched when I do a send from it, while the second GUI works fine - receives the message sent from the first GUI, scrolls correctly to the bottom of the msgLog. After I send a few messages on the Error GUI, the error stops occurring on the first GUI and moves on to the second GUI. Now I receive the Error when trying to do a msg send on the second GUI. While all this is happening. When I send a msg on the first (now a non Error GUI) both GUIs scroll as they should. But when I send a msg on the Error GUI, none of the GUIs scroll, but they do receive the msg.
Interestingly enough, the Error never occurs when writing a received msg to the msgLog, which also makes use of the UpdateChatWindow method kicked off from the component thread I mentioned at the beginning. The send is initiated on the main form, so a separate thread from the one started by the network read/write component.
After typing this post up, I went back to my open GUIs and for the next few tries the Error was jumping between the GUIs, once shows up on the first GUI, next on the second, then back on the first, finally it's back on the second GUI and stays there. While the error was jumping between the GUIs, one GUI scrolled while the other did not, which also changed based on where the error was occurring.
I did see something on this site that might explain this. Is the reason behind my weirdness related to:
"you are not able to directly do UI operations from another thread than the main UI thread"
Or is there more to it?
UPDATE 1
Apparently there are some conflicts on my system, WinXP SP2 64bit. May even have to do with my numerous .Net runtimes installed. GUI works without a hitch on my laptop WinXP SP3 32bit. Have 3 windows open and all work flawlessly. As soon as I open a GUI on my development comp, join the same server as the 3 laptop GUIs are on, the new GUI gets this Error, while the GUIs on the laptop are still fine. Typed in my problem into google and it seemed from the results like it may be a system configuration issue and it looks to be just that :(
I have a WP7 app that sometimes has to make a long (5-25 sec) processing.
With Mango, when the app is set to Dormant state while it was processing (ex: the user presses the Windows button or locks the screen), when the user comes back, the app crashes.
I tried on the emulator and on my device, same behavior.
If I reproduce it in debug mode on Visual Studio, it doesn't crash so it's hard to find what is really happening.
To reproduce it, start a new Windows Phone project, add a button on MainPage.xaml & add an event handler on the click event that executes an infinite loop:
while (true)
{
System.Threading.Thread.Sleep(100);
}
My question is: What is really happening? Why does it crash? Isn't fast app switching supposed to just pause the app process and resume it?
EDIT:
Another thing I noticed is that when running the heavy process, the deactivated & activated events do not seem to be raised when I get out/in the app.
Found the answer on the official Windows Phone forum (link). Here it is:
Why it crashes:
From the time the app is deactivated, it has exactly ten seconds to
finish up what it is doing. If the code takes more than ten seconds,
the OS will terminate the app.
Why the deactivated & activated events are not raised when I get out/in the app:
If the process is blocking the UI thread this also blocks the message
dispatch loop so I suspect that this is the reason why your app never
gets a chance to detect and handle the events.
Your problem is simple. WP7 cant really put your threads in a dormant state when you are under heavy processing in this fast time and will save a corrupt state. This state will crash when its reactivated.
It works in the debugger because the debugger makes everything slower and then WP7 has more time.
From Documentation:
When the user navigates forward, away from an application, after the Deactivated event is raised, the operating system will attempt to put the application into a dormant state. In this state, all of the application’s threads are stopped and no processing takes place, but the application remains intact in memory. If the application is reactivated from this state, the application does not need to re-create any state, because it has been preserved.
Source: http://msdn.microsoft.com/en-us/library/ff817008(v=vs.92).aspx