[Mouse cursor over window]: When I type in textboxes, on a .NET C# 4.0 window, the mouse cursor disappears and this is strange by itself.
[Mouse cursor outside window]: When I type in textboxes and press ENTER key to do some stuff in the UI thread, and then while doing that stuff, I move the mouse cursor over the window, the mouse disappears.
What can I do to keep the mouse always visible?
When typing in a text box (in any application) Windows will automatically hide your cursor. Some UI person will probably say that it's to prevent distractions, this is just my guess. If you move your mouse again, it will reappear.
The reason that your cursor is staying invisible while doing work in the UI thread is just that: Your application is busy doing work on the UI thread. Because your operation is happening there Windows is not able to redraw the area of the screen where your application is. That's why the mouse "disappears" again.
The two issues while manifesting similarly are different.
If you know that you need to do a lot of work, but it doesn't interact with the User Interface at all, you should kick off that work in a separate thread, so that your application continues to feel responsive to your user.
If you eventually need to do cause something to happen to the UI from another thread, you'll need to check out the Control.Invoke method.
Related
I'm updating a very large Windows Forms app to .Net Maui to make it into a cross platform app. Ideally, I would have the time to rewrite everything, but I don't. The client wants it yesterday. I'm already using a ton of the allotted time replacing the Windows Forms style interface with the XAML version. I've tried not to tinker too much with the code since the app was behaving flawlessly. Still, I've had to make a lot of changes because the Maui controls aren't always accessed the same ways as Windows Form's controls. Almost all of the methods and functions in the original app are synchronous. But some of the .Net Maui functions that I use to replace them are asynchronous. One function that is giving me a lot of trouble is the awaitable DisplayAlert(). Execution moves right onto the next statement in the code without waiting for the alert to be displayed or the user to respond. The function can be made awaitable, but to do this, the entire method within which it appears must be marked Async, which creates its own problems. There are literally hundreds of calls to The Windows Forms version of DisplayAlert(). Any solution that isn't basically a drop in replacement is going to cost tons of time.
I've been trying to create a blocking popup function that waits for the user's response before executing the next line of code within a synchronous block of code. In the XAML markup I've defined a popup "panel" with a frame, two labels and 3 buttons. Ideally, the code behind should be a function with the same parameters and behaviors as DisplayAlert() except that it blocks. It should display the panel, wait for a user response (button click/press), hide the panel, and finally return the text string of the button that was clicked...all within the same function.
Using simple method's like while loops to determine if a button was pressed block the thread from detecting that a button was press. Moving the panel display to a different thread than the button press, does nothing since the panel can only be displayed on the main thread. Invoking on the main thread has not been successful...at least not the way I wrote the code. I'm hoping someone can provide a very simple example of a blocking DisplayAlert() function that can be used within a non-async method.
In my console application, SendKeys.SendWait("^c") is called to copy some selected text to the clipboard.
It works fine, but if my console application has focus when this is called, then, instead of throwing an exception, it just closes my application. And then after that things start acting up, like my mouse wheel affecting the zoom instead of scrolling up and down.
Why dose this happen.
ctrl+cis the signal for a Console window to close.
And the reason the mouse wheel is affecting zoom after it closes is because the application never got a chance to release the ctrl key.
This can be fixed by changing the ConsoleMode or changeing the Console.TreatControlCAsInput Property.
Thanks for the help
Scenario I have a splash screen with a marque progressbar that is suppose to animate, indicating to the user that programming is initializing and starting up.
This (splashscreen) form is the first thing to start off - even before Application.Run(theMainForm).
Question: How do I update this splash screen to enable functionality (such as the animated progress bar).
Note I'm aware that Application.Run() is the message loop/pump for windows and that is NOT my question
You can put it in its own thread starting from Application.Run, take a look: http://www.codeproject.com/Articles/5454/A-Pretty-Good-Splash-Screen-in-C
In any .NET 2.0 Winforms application, if you run the code in Debug Mode, and you either hit a breakpoint or otherwise Step Into the code line by line, and you want to see the GUI of the application being debugged, then .NET does not draw the application screen.
For example, I have an application which writes some messages to a TextBox on a Form. When I debug the code step by step, or when a breakpoint is hit, I want to see what all messages are logged in the TextBox, but if I press Alt-Tab to switch from VS2005 window to the WinForms application window, all I see is white color. The form is not redrawn, until you press F5 in the debug mode in VS2005.
What is the reason for this, and is there a way to overcome this, without introducing any threads in the code?
What is the reason for this
While you're debugging, you're effectively blocking the UI thread - you're manually stepping through its execution flow. The UI thread can't draw the UI while you're stopping it from executing.
and is there a way to overcome this
You could try calling Application.DoEvents() manually, but I'd generally recommend against it.
It would be better to just wait until you got to the end of the method and let the UI redraw itself normally. If your method is very long (in terms of time) then bear in mind that when not debugging, the UI still wouldn't be able to update itself while that method is executing. This may cause you to change your design (it's hard to tell just from the information we've got at the moment).
The reason for this is because you can only have one UI thread, and when you enter your method that updates that code that code begins blocking the UI thread. It will not update until your method exits.
Here is a good SO on message pumps, which are what drive the UI updates
You should be able to use Add Watch/Quick Watch to look at any values at the time of debugging. This sounds like what you are really looking for, anyway.
Like everyone else has said in answers and comments, the UI thread is blocked so it cannot be redrawn.
However, if all you want to do is see the GUI, and not interact with it, and you are running Windows 7/8 (which sounds unlikely since you're using VS2005) and haven't disabled aero peek, you can mouse over your application in the task bar and Windows will show the preview thumbnail. When you mouse over the thumbnail, you can "peek" at the application even when the breakpoint is blocking the UI thread.
I am working in a machine vision project.In my project i am using camera for print inspection.
In my application i am using one picturebox for displaying a image on screen and two buttons.In two buttons one button for live display and another for fullscreen.With the livedisplay button I am displaying image in picturebox in a while loop. in the same time while process in while loop i have to press fullscreen button. but I can't press fullscreen button because while the loop is running it doesn't allow me to push any of the buttons of the form. (The loop is a while) Why is this happening? How can I click this button while the loop is running?
Welcome to the wonderful world of multi-threading. You need to put your while loop on a separate thread, so your UI remains responsive. Threading is a long, deep concept, and there are a million ways to do it.
Probably the path is least resistance is to use the BackgroundWorker threading model. See here for more details.
One solution can be rather than running a while loop; use a timer with some interval and on timer tick update the image in picture box. You can start the timer when user clicks on Liveupdate button. You can keep the interval very low(e.g. 100ms) so that your updates will give feeling of being LIVE. This will give some interval in between two updates when application can take input for other user action like other button click.