We have a Windows Form application for our fingerprint scanning for time keeping and it takes too much time for just initializing the control for the finger print scanning, around 5 to 10 minutes. So we need to create a loading form so that users will know that the application doesn't hang and they need to wait, but the cause of the long running process was inside the InitializeComponent() method from the initialization of the form.
My question is, how can I move the InitializeComponent() method to another thread so that I can show a loading form while initializing the form where the biometrics scanner control is, because it creates an error when accessing a UI control from another thread other than the main thread?
My code is in C#, Framework 2.0, build in Visual Studio 2008.
Please help, thanks in advance.
You can remove your control for the finger print scanning from the visual designer and create this control from the code using an additional background thread and writing a progress information during this process.
SO has lot of data about it:
How to update the GUI from another thread in C#?
Accessing UI in a thread
Best Way to Invoke Any Cross-Threaded Code?
you can find a lot more.
If still need help, post a comment.
You can find your InitializeCompoent(); method in yourForm.designer.cs, and from there you can modify it.
Related
I am developing a desktop application for pdf file management using C#.
When I search any folder for *.pdf the application stops responding for some time, which is undesired behavior.
I am using XmlWriter to write data (i.e. file name,author name,subject). Also I have a label to show current scanning of file but it only show last file after complition of scanning.
This is a classic problem.
Basically the thread which displays the application is the thread which is doing all the work. So any updates/responsivness of the GUI will have to wait until its finished.
The solution to this is to make it multithreaded. The simplest way is to use a Background Worker thread which will do the writing searching and whatever, and just leave the main thread free.
http://www.dotnetperls.com/backgroundworker
If you can update your program, .NET 4.0 has new IO functions that return before finishing:
For example EnumerateFiles:
http://msdn.microsoft.com/en-us/library/dd383458.aspx
In addition to Haedrian's answer, I'd say that you could use the ProgressChanged event of BackGroundWorker to handle updating your progress indicators.
More specifically, you could raise that event with ReportProgress method, passing the name of the file curently scanning, and in the BackGroundWorker.ProgressChanged event handler you could update the label you want to use to show the file under scanning
If you don't like to create an extra thread you can call
Application.DoEvents();
in the loop. This keeps application responding and updates the label.
I have something working but I'm not sure it is OK and if it will cause problems later on.
I have a Win32 C++ app which does some video processing and uses Direct3D for display (not my code). My task is replacing the GUI with a C# GUI.
I've made the C++ code into a dll.
I've created a GUI in C# and have a panel intended for the video-display. I pass this panel's HWND to the dll, and everything seems to work just fine.
But - that panel is being accessed by a thread other than the one it was created on, which shouldn't be done.
Part of me wants to "leave well enough alone" but this feels wrong and I suspect it will cause problems down the line. Such as when we want to catch click-events on the panel, which will be on the main or UI thread ... which created the panel.
ANy suggestions on how I should be doing this?
Thank you
Thanks
I think you already know the answer to this. Windows have thread affinity. All operations on a window should be performed from the thread that created it.
Given this rule, I can't imagine that the DLL is responsible for moving window access onto a different thread and presume it is your code that does it. The solution is for you to create and access the window in the same thread that calls the DLL.
The main problem I've seen with this technique is that your UI can flicker. If you are early enough in the process to use WPF you may want to take a look at D3DImage if not what you are doing now will mostly work.
I want to show an loading image when i launch my desktop application. can anybody tell me how to show this in C#? Results required as happens in visual studio 2005/2008 when we launch this application.
What you are looking for is actually a splash screen. Look at this codeproject article. It explains really well how you should do this.
http://www.codeproject.com/KB/cs/prettygoodsplashscreen.aspx
What i did in my previous project was, that make the Form1 (display form) and make it wait for a while, then close it after that launch the Form2 which is the actual application.
But that was way back when i was a fresher. Now what i might do is, have a Form1 which ill launch and in the backgroundworker do all major UI processing work such as if any loading of data needs to be done, etc stuffs and keep every thing ready in memory. Then ill close the Form1 or make it hide or invisible and launch the Form2 which is the main app form and pass all the information required to it.
I am attempting to write a specialized onscreen keyboard (OSK) for an application I'm writing in C#. To facilitate this, I've created a form which has several buttons on it representing keys, and clicking them calls SendKeys and sends out the appropriate keys.
This form is owned by the main window that is shown when the application first starts, using the Owner property. This way, the OSK pops up whenever the user focuses the application, and it stays on top of the main window if it said main window is dragged over it.
This all works great, but because I have modal dialogs that I also want to use with the OSK, I attempted to create it in a separate thread, complete with its own message loop (via Application.Run) so it could still be usable with any modal dialogs in the main thread.
The problem with this is that, obviously, being in a separate thread can cause InvalidOperationExceptions because of cross-threaded calls. One specific example of this is when calling Application.Run(osk) from the new thread, a cross thread error occurs because it is attempting to update the window's handle with the owner (the main window).
My question is, is it possible to have an owned form on a thread that is separate from the owner in a safe manner? And, if failing that, is it possible to emulate an owned form's characteristics (namely being Always On Top for only the main window, and popping up when the main window is focused)?
Thanks, and sorry if this is confusing.
I think this is actually a bug in Windows Forms. Somewhat inevitable due to the way it checks for access to the Handle property by the wrong thread. The SDK docs for SetParent are not explicit about it, it states the requirement is that both windows belong to the same application. No mention of having to belong to the same thread. I know for a fact that the 'same application' requirement is not hard, there's appcompat code in Windows that makes this work for windows from different processes. Adobe Acrobat ab/used this for a long time. Which definitely absolves the 'same thread' requirement.
Well, punt the problem and try it out. Set Control.CheckForIllegalCrossThreadCalls to false before you set the owner, back to true afterward. And test the heck out of it. If you have trouble then try pinvoking SetParent() directly instead of setting the Owner. Windows Forms actually uses SetWindowLongPtr which is not recommended by the SDK.
I'll take a stab at this. Try running the OSK as a separate process.
Try using ShowDialog for the OSK as well instead of Application.Run - ShowDialog creates a message loop and ends it when the window is closed, and perhaps will solve your problems.
new Thread(() => new OSK().ShowDialog());
Why not use Control.Invoke to make cross-threaded calls to avoid InvalidOperationException?
lets say you are adding a feature to an old and running windows form application now the whole application is running in one thread and the application is really big and have many forms so you cant refract it to run in multithreads, now the application gui freeze everytime you make a process , is there is any way to have an indicator that its loading or in progress while its freezing ? without changing the whole design of the software to support threads etc ?
by the way i dont want it to stop freezing its ok to freeze i just want it to to indicate that its doing something !
any idea would be appreciated, thanks...
See BackGroundWorker componet if application is written using .net 2.0 or higher version.
You can set the form's Cursor property to Cursors.WaitCursor upon starting the long running action, and reset it to Cursors.Default upon finish. While your action executes you can call Application.DoEvents() but it may cause side effects if other events trigger in the mean time.