I'm working on a winforms application that works with database a lot, and 90% of my forms need to load some initial data from database on Form_Load.
I've been told to use threading to show the form, and then go and fetch data and fill the form with data, otherwise the customer can't see the form until the postman goes to the db and comes back with data :)
I've done some simple tasks with threads before, but this case is a bit confusing to me. I have a mainForm which is the MdiParent and other forms are MdiChild like below:
ChildForm child = new ChildForm { MdiParent = Program.mainForm };
and my mainForm (the MdiParent is static in Program.cs)
I don't know whether I should use Thread? BackgroundWorker? Other solutions?
I would be way more than happy if your kind replies could help me through this case and empower my incomplete knowledge. Thanks.
Using a BackgroundWorker is the easiest way to go. It handles the threading issues, catching exceptions and runs the work completion callback on the UI Thread.
If you are using C# 4.5, then await/asych is also a good approach.
Related
Sorry, this more than likely has been asked at some point but I'm not even sure what I should be searching on...
I have a winform application with multiple forms. Up until this point having a one form open at a time has been fine. But now, I have a new form that I want to add on but have the ability to keep that form open while I work in other forms. I'm not even sure what this is called but I have seen it done before in other applications.
I did find this: Run two winform windows simultaneously
But this new window is a winpipe queue viewer that runs a thread. When I try initializing using the
Application.Run(new QueueViewer());
I get the error:Starting a second message loop on a single thread is not a valid operation. Use the Form.ShowDialog instead.
The problem with that is it locks the program from doing anything else until I close that form.
Thanks for your help!
Add a form to your project (let's call it Form2). Somewhere within your code (maybe in a button click event) use the following code:
Form2 f = new Form2();
f.Show();
The Show method allows you to interact with the originating form, whereas ShowDialog prevents interaction from the original form.
I'm currently doing a security assessment of an extremely large C# application. I have wrote a tool to help me do the assessment that also runs in C#. The entire application uses ShowDialog aka modal forms. I'm trying to come up with a way where I can still use my tool (click on it for example) while modal dialog boxes are popped up. I figure, this may require another thread or something else. If anyone has any easy tips on a way to make it so that my form doesn't get blocked by ShowDialog, that would be great.
The entire purpose in using a modal dialog is for it to block it's parent until it is dismissed.
I am a newbie to excel programing, I now have a problem with my excel add-ins code. My add-ins call out a Mainform. Whenever I call my method from this form's button to do some tasks, such as searching huge data, the Mainform is frozen, it's inevitable. But when the method is running, assume it then will call a childform, this child form is also pending, I cannot do anything with it.
My purpose is to call a child form to add in a progress bar and an Abort button to cancel the running method.
How can I solve this?
Thanks in advance for your help.
vuhi
I believe you need to multi-thread to allow that; multi-threading using just VBA cannot be done.
See the answer to this question for more details.
I use .Net Framework 4.0 and C#. I want to dynamically instantiate a form in my code while the main form remains responsive. Is creating a new thread and call Application.Run(newForm) the only way of doing it? It just looks like a bit of a mess for such a simple thing. I thought it should be so common that the framework should have some kind of built-in functionality for this.
You don't need another thread to create a new form, and don't call Application.Run a second time. As long as you don't do anything that blocks the UI (and you never should), both forms will run just fine.
MyForm form = new MyForm();
form.Show();
If you call ShowDialog instead of Show from your first form, your first form will be blocked.
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?