On each of my form I have put an 'Exit' button. When user clicks it, another
form is displayed (I don't want to use 'MessageBox') asking user whether he
really wants to quit. If user clicks yes the form closes. If user clicks no,
form is redisplayed.
However, out of 4 forms only one form refuses to redisplay. The code is exactly same on all forms.
I have included 2 Express 2008 projects showing one form each in the zip file
apps-ssk.zip
Can somebody have a look at it and advise me how to overcome this problem?
Firstly, why do you not want to use a MessageBox? Secondly, why do you need to redisplay the forms at all? Why not just not close the form until the user confirms that they want it closed?
If I have an issue with the fact that my car won't start and I sell the car then the fact that it won't start is no longer an issue for me. Anyway, I'll leave it at that and wish you good luck with your problem.
Sometimes problems like this are a sign of a poor design. As developers it is in our nature to find the root cause. It is verynmuch possible that your use of forms is the problem. So 1) since I'm not one to download others haystacks looking for the broken needle, perhaps you could post the relevant code. And 2) what is the aversion to messageboxes? This exactly the kind of thing they are suited to.
I don't get it. The download has two different versions of the app. One is named app1success which I assume has the behaviour you wanted so whats the problem ?
C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter
There's just no reason to use garbage like InputBox. - jmcilhinney
The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber
You seem to be of the opinion that we are trying to hinder you in some way. That is certainly not the case. For one thing, you have a very low post count. As such, there's no way for us to know what sort of experience you have. You may be very competent and what you are trying to do might be quite legitimate under the circumstances, but we have no way of knowing that. I've lost count of the number of times that I have simply answered the question as asked by the poster and it has turned out that they were actually asking the wrong question and they should actually have been taking a different approach in the first place. Had I questioned their motives in the first place on those occasions I would have saved myself and the OP some time. I thought that that might well have been the case here because your request does sound very out of the ordinary. If you know well what you're doing and why then I would think that it would have taken you a couple of minutes to answer my questions and satisfy me that I wasn't trying to solve a problem that didn't actually need solving. I've been on both sides of a forum question too and, when someone who I want to help me asks me for information, I tend to provide it or explain why it doesn't need to be provided rather than just refuse.
Its curious, why are you starting your app from Sub Main ? I've been looking at it and there are a lot of things that appear quite wrong about the approach used. Its no surprise that it gives trouble. For example, using the Form's Tag property as a dialog return while clever isn't really the best approach especially when you use Strings as the dialog return. At the very least, you should be using some kind of enumeration. You shouldn't don't hide the dialog form, you should dispose of it.
C++ programmers will dismiss you as a cretinous simpleton for your inability to keep track of pointers chained 6 levels deep and Java programmers will pillory you for buying into the evils of Microsoft. Meanwhile C# programmers will get paid just a little bit more than you for writing exactly the same code and VB6 programmers will continue to whitter on about "footprints". - FunkyDexter
There's just no reason to use garbage like InputBox. - jmcilhinney
The threads I start are Niya and Olaf free zones. No arguing about the benefits of VB6 over .NET here please. Happiness must reign. - yereverluvinuncleber
There is always a chance that you will never solve this particular problem. Everybody who has worked with this language (and probably every other significant language) has found certain situations where something incorrect happened for reasons that could not be explained. I have several situations where I found incorrect behavior, and as I was studying it, it simply vanished. In those cases, I was never able to determine what was going wrong, which can be kind of frustrating. Fortunately, such incidents are quite rare. It is possible that this is one of those situations. However, it is more likely that this is NOT the case.
My understanding is that the next version of VS will have a document comparison mechanism built in, which would be nice for this, but document comparison tools are available elsewhere. One thing you might do is to narrow the projects down to the simplest piece possible. You may have already done that, because the problem appears to be caused by just one form, and you state that you have created a new, identical, form which is working fine. Rather than trying to see all the differences yourself, run a document comparison tool to positively identify that the documents that make up the form (which are pretty doggone simple, when you get right down to it), are truly identical, yet behave differently, and that would be really interesting. More likely, you will find that there actually is a difference, and it may be immediately obvious why the behavior is different, or perhaps there will be a difference that doesn't look relevant. Either way, the exercise could be informative.
Basically, if you are frustrated at not seeing the difference, that's a good thing. It means that there is something worth learning here...probably, and a comparison of the files would be a good place to start.
... my first post, betrayed by the Enter button :-) (I do not find the Edit option)
Originally Posted by SanganakSakha
I created a new form and added all controls and then copy pasted the code from old form. It works now.
The problem is not in the code, but in a property setted in the designer.
Originally Posted by SanganakSakha
My only disappointment is that I will never know the cause of the error.
The solutions you provided allowed me to find the problem (with only the code would not be possible to find the cause).
The application (App2Fail) has this behavior, because the CancelButton property of frm01 has value =btnExit (while in App1Success is not set).
This setting determines the following sequence of events:
- BtnExit_Click: executing code in the procedure (so frmErrMsg.ShowDialog); whatever the value of frmErrMsg.Tag, at the exit from BtnExit_Click procedure, is generated the closing event of the form, so ...
- Frm01_FormClosing: if in this method, the value of e.Cancel is not setted to True, frm01 will be closed and with it the application too.
To get the desired behavior, set CancelButton to '(none)' (or similar value - the language of my Visual Basic is not English).
Instead of using the Tag property, you can use the value returned by ShowDialog (Public Function ShowDialog As DialogResult).
Reply With Quote
Originally Posted by SanganakSakha
