I'm programming in C# using Visual Studio Express 2005 and my application has a regular WinForms form, which I will refer to as "main form". From this form I create another non-modal form, which I will refer to as "secondary form". I usually have a lot of different application running on my computer and sometimes I want to easily bring the main form to the front from the secondary form. So, in my secondary form I have a button labeled "Show Main Form" and when I click it, it calls mainForm.BringToFront(). If there is some kind of error, then the main form will show a modal error MessageBox, which has the main form as its parent. When this happens, I am unable to click the button on the secondary form. In fact, I can't do anything with the secondary form (it's like it's completely disabled) unless I click Ok on the MessageBox, but to do that I need to first locate the main form, which is difficult because I have so many applications running. Can someone please help me, how can the secondary form still be running as usual when the error MessageBox is showing?
Not sure how to describe this or If I'm 100% correct here.
You seem to create the popup box in the same thread as your "main form" and "secondary form" are created in. Since you have specified the popup box's parent as your "main form" it's only expected that the popup box blocks everything for that thread. Therefore your "main form" and "secondary form" is blocked. You still need to look up the "main form", in your jungle of application, to gain access to your popup box.
Without viewing your code it's not that easy to suggest a fitting solution.
MessageBox is a Modal form - you know that because you called it that when you wrote the title.
And a modal form prevents anything else going on in the thread until the form has been dismissed, usually by pressing the OK or Cancel buttons.
Because Form1 and SecondaryForm are both running on the same thread (the UI thread, as they have to be) the use of a Modal form in either of them will automatically prevent the other from doing anything.
You can't "get round" that, you will have to write your own MessageBox form which is not modal, and display your messages in that.
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
As others have said, when a modal window is shown, a new message pump is launched and the previous one is temporarily disabled, so you can't interact with any other open window in your program for as long as the modal window is open.
However, you may drastically improve on the situation with a buried mainform by only using the MessageBox.Show() overloads that have an explicit owner as their first parameter (example[^]), where this would be the suggested value. Doing so the calling Form becomes the owner of the modal dialog (it isn't by default!) resulting in a more solidary behavior of caller and callee.
imho, the main issue here is your overall strategy for error handling: in general, I think errors should be handled modally, stopping execution. imho, you should never "swallow" errors (handle errors without throwing) by just using a try/catch to "skip" over them.
However. for specific situations, like file and file-stream business, you may want to notify the user without stopping program execution, and not throw an error modally.
If I wanted to achieve what you describe, I would:
1. in the second form put a public Action method (delegate) that can be defined the main form:
publicpartialclass SecondaryForm : Form
public Action<string, string, DateTime> SendErrorMessage;
// create an errorprivatevoid button1_Click(object sender, EventArgs e)
thrownew ArgumentException("some error");
catch (Exception ex)
SendErrorMessage?.Invoke(ex.Message, ex.Source, DateTime.Now);
I have a large app that has been working for a while. I'm adding a new service class to it that is loaded as a MEF plugin. The service class loads some plugins that are NOT MEF plugins. I'm using relfection for those assemblies.
I'm getting this runtime exception on startup:
Cannot cast the underlying exported value of type
I can step through all of my code and everything runs, but after my class is contructed I get the error. If I comment out the part of my class that loads my assemblies, everything works fine. My assemblies don't error at all, and I can't see how externally loaded assemblies could cause some MEF problem.
I don't know MEF that well. I've Googled this a few different ways with no luck. Anyone know what this means?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
This isn't a good question. Just using an Access database in your app isn't going to "change the resolution" of anything.
We have no idea how your code is written, what the exact code at the point of failure looks like, or anything else about your code so it's impossible to tell you anything useful.
You're going to have to describe exactly what happens. Does the size of the entire form change? Is it just a control on the form, like the DataGridView? You're also going to have to use the debugger narrow down the exact method in which this "change" happens. Is it when the data is retrieved from the database? Is it when the DGV is bound to the new data? When?
publicpartialclass Form1 : Form
privatevoid Form1_Load(object sender, EventArgs e)
// TODO: This line of code loads data into the 'stokDataSet.kolon' table. You can move, or remove it, as needed.this.kolonTableAdapter.Fill(this.stokDataSet.kolon);
I also see .accdb and .dataset.xsd file are added to project. Yes entire form size changes once I start the app. No error returns from debugger. please let me know if more to clarify.
OK, so you're using the designers to do database work. That's not a good idea, despite what Microsoft says. The designers hide a lot of the code and workings, basically teaching you nothing about how to do this stuff.
What I can say is none of that code is going to change the size of either controls or forms, so the problem is somewhere else. What properties did you change on the Form and the DGV. The properties that have been changed from default will be shown in bold text in the Properties window when you click on the Form or the DGV in the designer.
Dave is exactly right: "show up Access" in a DataGridView will not change the resolution of a form: nothing can change the resolution of a form independently of the system on which it is running!
What you probably mean is that something changes size; maybe your form gets bigger or smaller, we don't know. But we have no idea what you did to do that: we can't see your screen, access your HDD, or read your mind; we only get exactly what you type to work with.