|
dnh wrote:
Did you debug/F11 every line?
Fair question.
Of course. this.Close is NOT called at all. That's why I changed my if block ( before I just had return after the message box ). In fact, if I click Cancel in the second dialog, and then put breakpoints in the parent dialog, neither click handler is called ( OK or Cancel buttons ), but the dialog closes. DialogResult is set to Cancel, so I 'fixed' it for now ( had to send to the client ) by using a bool and stopping the close behaviour if Cancel has not been clicked. Stepping through the OK code in the main dialog, same thing. The message box code runs, then next code I can step to is the code in the main form that created the dialog, unless I create an OnClosing handler in there as well. I have no idea why they are closing, but it's not from my code.
dnh wrote:
Although setting the DialogResult property will cause your dialog box to close automatically, you can still handle the control's Click event, and the dialog box will close once the event handler's code is finished. While handling the Click event, you may want to halt the closure of the dialog box."
Yes, I killed all my automatic closing of dialog boxes as a first step. I've quintuple checked, and they are all set to 'none'.
dnh wrote:
Are you sure that you aren't missing something obvious? (like code to stop closing in your second dialog? - see link)
I didn't see any code in that link that seemed to help, perhaps I missed something, but my buttons are definately not set to automatically close the dialog, and certainly the problem with the second dialog is not calling either button event handler at all. If all else fails, I may have to keep the ugly bool solution and impliment something similar in the main dialog. Yuck - that's got to be a hack. I'd far rather learn what weird configuration issue is causing this. The second dialog has a similar message box setup, and it works fine there, but I can't see anything different in how the dialogs are set up.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
I have no idea why they are closing, but it's not from my code.
Me too. Sounds bit crazy. I am sure that you'll be like d'oh when you or somebody figure it out and I'll be like d'oh when you post solution here.
Have fun, I am gone, to get some sleep.
David
|
|
|
|
|
Christian, if I answer your question, do I get to steal your MS MVP status? 
On a serious note, have you tried commenting out all code in your handler? I can often isolate problems by commenting out all code, then bits, then finding the actual problem. Sounds like a weird one though, good luck.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Conversation With a Muslim
Judah Himango
|
|
|
|
|
Judah Himango wrote:
Christian, if I answer your question, do I get to steal your MS MVP status?
Hey, if you answer enough, you may get your own MVP status 
Judah Himango wrote:
have you tried commenting out all code in your handler?
It looks like this :
if (this is true
{
MessageBox.Show("blah blah");
}
else
{
// none of this code is called, I've stepped through to see this is the case.
}
I changed it to this to ensure the other code is never called, and I've stepped through to see for myself.
Judah Himango wrote:
Sounds like a weird one though, good luck.
Thanks - it makes no sense to me at all. I understand how to assign a button to close a dialog, and I've simply not done so. All I can think is that I did set that up early on, and some remnant of that fact is lurking beyond my reach ( in that the properties tell me it's not set ).
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Judah Himango wrote:
On a serious note, have you tried commenting out all code in your handler? I can often isolate problems by commenting out all code, then bits, then finding the actual problem.
That's usual method of mine.
David
|
|
|
|
|
Have you manually checked the designer-generated code? I had a case last week in vb.net where the handler got wired up wrong. I couldn't figure it out because when I used the VS editor interface, it took me to the routine I was expecting, but in the designer code, it was also wired up to another handler. As soon as I fixed that, the code I was expecting was getting called.
|
|
|
|
|
Good call - I'll give it a look tonight. I was going to just delete all the buttons and create new ones, and see if that helps.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Please see documentation for Button.DialogResult property in MSDN. It is mentioned that:
If the value of this property is set to anything other than DialogResult.None, and if the parent form was displayed through the ShowDialog method, clicking the button closes the parent form without your having to hook up any events. The form's DialogResult property is then set to the DialogResult of the button when the button is clicked.
Therefore, it is clear that for the button labeled “OK” in your dialog box, while the Text property could be set to “OK” string, but if the “DialogResult” property of this button is also set to “OK”, then clicking this button will automatically close the parent dialog box without your having to hook up any events.
So, the solution to your problem is that you must NOT set the DialogResult property of the OK button (say btnOK) to “OK”, while the Text property of this button might still continue to be “OK” to keep it visible as such to the user. You may set the DialogResult property of this button to “None”. Now, in the click handler of the said OK button, you can do your processing as desired. But please remember to close the form yourself in the code as per your scheme.
I may also mention that as per the documentation, the AcceptButton/CancelButton properties are irrelevant for this purpose because they are useful to allow "Enter" or "Escape" keys instead of the mouse-clicks on OK and Cancel buttons respectively. What is of relevance here is that DialogResult property which can have a possible of 8 values (i.e., Abort, Cancel, Ignore, No, None, OK, Retry, Yes).
I have tested this in my test application by setting and removing the DialogResult property of the OK in this manner, and it ran alright. Hope it solves your problem as well.
|
|
|
|
|
Hmmm - thanks for all this, it obviously explains one problem ( the double close behaviour ), although I'm surprised to hear that the buttons could be set this way, as I set them to none explicitly. This could be an indicator that the resx file is in a mess.
And if the resx file is screwed, that would explain the other behaviour as well.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hello there
How can i add a new Refrence in a project in runtime??
Plz help me
Thanx
|
|
|
|
|
I am not sure that i understand what you mean.
But i assume you would like to dynamically load an assembly?
see the Assembly.Load documentation for this.
/cadi
24 hours is not enough
|
|
|
|
|
|
//I want to draw an X-Y coordinate system on a WinForm (400, 400). The only code I entered after cteating the Form is beween the comments. It doesn't lookk centered. Why? --thanks
static void Main()
{
Application.Run(new Form1());
}
PROBLEM IS HERE->//////////////////////////////////////////////////////////
private void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e)
{
Graphics g = e.Graphics;
Pen myPen = new Pen(Color.Black, 1);
Rectangle rect = new Rectangle();
g.DrawLine(myPen, this.Width/2, 0, this.Width/2, this.Height);
g.DrawLine(myPen, 0, this.Height/2, this.Width, this.Height/2);
}
//////////////////////////////////////////////////////////////
|
|
|
|
|
Replace
g.DrawLine(myPen, 0, this.Height/2, this.Width, this.Height/2);
with
g.DrawLine(myPen, 0, this.ClientSize.Height/2, this.Width, this.ClientSize.Height/2);
this.Height probably includes the height of the menubar and titlebar also, that's why it didn't look centered.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
|
this.Heigth is the height of the window including any NC (Non Client) stuff (title bar, borders, scrollbars etc.)
Use the Control.ClientRect to get access to the actual size of the content area of a window.
<code>g.DrawLine(myPen, this.ClientRectangle.Width/2, 0, this.ClientRectangle.Width/2, this.ClientRectangle.Height);
g.DrawLine(myPen, 0, this.ClientRectangle.Height/2, this.ClientRectangle.Width, this.ClientRectangle.Height/2);
/cadi
24 hours is not enough
|
|
|
|
|
hello,
we use to log a lot of data a compact flash datalogger. I want to read out the cf-cards by copying all files to a new directory an delete the cf-card, so it can be reused.
My problem is now, how do i recognize in a c#-program, that there is a new cf-card. I think i need the information, what new drive name (e:, f:, g:...) the new inserted card has and then i have to copy the information to the disk.
Any hints may be usefull (also with other programming languages, if there is an other one more appropriate).
Thanks in advance,
Heiko.
|
|
|
|
|
your probably going to have to import a native library to do this, best thing to do is to search google and hope some one has already incapsulate this functionality
just like cd burning the .NET framework does not directly support this, you might be able to find the COM DLL on your own, but you would probably be hard pressed
sorry i can't help you more but your best bet is google for "cf-cards" and "C#"
|
|
|
|
|
hi everybody
anybody knows how can i save drop down box items in a text file?
thank you
|
|
|
|
|
Try something like this:
using (System.IO.StreamWriter sw = new System.IO.StreamWriter("test.txt",false))
{
foreach(object o in this.comboBox1.Items)
{
sw.WriteLine(o.ToString());
}
sw.Close();
}
/cadi
24 hours is not enough
|
|
|
|
|
The sw.Close call is redundant, the "using" statement automatically closes the StreamWriter when control reaches the end of the block.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
Yup, I know this is true for the StreamWriter (and should be for any class implementing the IDisposable interface).
I just can't get rid of the habit to be on the safe side.
And sometimes i have something like this:
using (x)
{
using(x.y)
{
x.Close();
}
}
by calling the x.Close i simply free the resource as soon as i do no longer need it, not as soon as the finally of the using statement is reached.
And finally you never know if the IDisposable.Dispose actually does implement all the stuff you expect it to contain.
OK, your are right... it is redundant  (but i still have my points!)
/cadi
24 hours is not enough
|
|
|
|
|
Hmm. Just for the sake of argument,
using (x)
{
using(x.y)
{
x.Close();
}
}
After all, that's the sole purpose of the using statement
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
hihi... you win... 
/cadi
24 hours is not enough
|
|
|
|
|
hi
can anybody help me to see if a certain item exists in a drop down box?
thank you
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
