Window doesn't stay hidden
-
I have the situation where Form A is hidden when Form C is displayed and then when Form C is closed, Form A is displayed again. Almost all of the time it works as expected. Occasionally, though, both forms are seen displayed at the same time. For the most part, no one can tell me the steps they went through when it happens. It has been witnessed mostly in debug mode. The one time it happened in release mode was also the one time we knew the steps that led it to happen - a test procedure was being run. However, when the test procedure was repeated at a later date the 2 windows were correctly mutually exclusive. Any ideas? Description of the code: When ClassB is instantiated, it sets the member variable m_FormCOpen = false. Later, upon user selection, FormA will call method1 in ClassB. method1 instantiates FormC, subscribes to the closed event for FormC, sets m_FormCOpen = true, displays FormC, does some database updating, and returns. The method in FormA checks the property for m_FormCOpen and if it is true, hides FormA. The method in ClassB that is executed when FormC closes, triggers an event to which FormA has subscribed, and FormA is displayed.
public class FormA
{
public FormA (ClassB)
{
m_ClassB = ClassB;
}private void ClassA_Load ()
{
subscribe to ClassB ClosedFormC – routine to call: ClassB_ClosedFormC.
}private void UserSelection_Click()
{
m_ClassB.method1();
If FormCIsOpen
{
Hide();
}
}ClassB_ClosedFormC()
{
Show();
}
} // end of ClassApublic class ClassB
{
public void ClassB()
{
m_FormCOpen = false;
}public void method1()
{
FormC m_FormC = new FormC();
subscribe to FormC.Closed – method to call FormC_Closed
m_FormCOpen = true;
m_FormC.Show();
do some stuff
}private void FormC_Closed
{
trigger ClosedFormC
m_FormCOpen = false;
}bool FormCIsOpen
{
get
{
return m_FormCOpen;
}
}
}// end ClassB -
I have the situation where Form A is hidden when Form C is displayed and then when Form C is closed, Form A is displayed again. Almost all of the time it works as expected. Occasionally, though, both forms are seen displayed at the same time. For the most part, no one can tell me the steps they went through when it happens. It has been witnessed mostly in debug mode. The one time it happened in release mode was also the one time we knew the steps that led it to happen - a test procedure was being run. However, when the test procedure was repeated at a later date the 2 windows were correctly mutually exclusive. Any ideas? Description of the code: When ClassB is instantiated, it sets the member variable m_FormCOpen = false. Later, upon user selection, FormA will call method1 in ClassB. method1 instantiates FormC, subscribes to the closed event for FormC, sets m_FormCOpen = true, displays FormC, does some database updating, and returns. The method in FormA checks the property for m_FormCOpen and if it is true, hides FormA. The method in ClassB that is executed when FormC closes, triggers an event to which FormA has subscribed, and FormA is displayed.
public class FormA
{
public FormA (ClassB)
{
m_ClassB = ClassB;
}private void ClassA_Load ()
{
subscribe to ClassB ClosedFormC – routine to call: ClassB_ClosedFormC.
}private void UserSelection_Click()
{
m_ClassB.method1();
If FormCIsOpen
{
Hide();
}
}ClassB_ClosedFormC()
{
Show();
}
} // end of ClassApublic class ClassB
{
public void ClassB()
{
m_FormCOpen = false;
}public void method1()
{
FormC m_FormC = new FormC();
subscribe to FormC.Closed – method to call FormC_Closed
m_FormCOpen = true;
m_FormC.Show();
do some stuff
}private void FormC_Closed
{
trigger ClosedFormC
m_FormCOpen = false;
}bool FormCIsOpen
{
get
{
return m_FormCOpen;
}
}
}// end ClassBHi, I am not surprised it behaves strangely: the "code" shown is a complete mess; it is not valid C# code, and it is convoluted. Why have variables m_FormC, m_FormCOpen and FormCIsOpen all side-by-side ? It would be much better to have just one m_FormC somewhere, and one method to determine whether this m_FormC is open or not, rather than having several bools that try to keep track... :)
Luc Pattyn [My Articles] [Forum Guidelines]
-
Hi, I am not surprised it behaves strangely: the "code" shown is a complete mess; it is not valid C# code, and it is convoluted. Why have variables m_FormC, m_FormCOpen and FormCIsOpen all side-by-side ? It would be much better to have just one m_FormC somewhere, and one method to determine whether this m_FormC is open or not, rather than having several bools that try to keep track... :)
Luc Pattyn [My Articles] [Forum Guidelines]
I realize it is not valid C# code - I said it was a "Description" of the code. I did not put it in red as the code tag would do, and I mentioned that it works most of the time. If this were truly the 'code', it would not be compiling far less working most of the time. The true code has been executed by 11 people, 6 hours a day, for 2 years. In that time the error situation I am describing has occurred about 4 times. The code itself sits on another computer and is too voluminous to reproduce here. This is not a syntax problem. If someone is on the level where they could answer this question, I think they are at the level they can fill in the blanks in the outline and perfect C# is not needed. I don't know what you mean by side-by-side and what that has to do with how code executes. The 3 items you mention serve different purposes. m_FormC is the class itself. m_FormCOpen is the boolean that tracks whether the form is dipslayed or not. Remember, the class can be instantiated but the form not necessarily displayed at a given time. FormCIsOpen is the property which allows other classes access to the member variable m_FormCOpen. Thus, you see, there are not several bools that try to keep track - there is only one. There are reasons why one class displays the form and another needs to know if it is displayed or not. The question is, that being the case, is there a safer way to accomplish it. Or, is there a known Windows/.NET problem where forms in hiding suddenly come out of hiding. You haven't given a meaningful alternative or any explanation for why the methodology here would fail. My impression is you were too quick to respond. Slow down. If you don't want to take the time to understand something that isn't immediately obvious to you, it would be better to not respond at all than to do so in a nonconstructive manner. Saying the code is a complete mess is not constructive. Confusing a class with a bool with a property is not constructive. But, if you were truly trying to be helpful, then thanks for taking the time. ;)
-
I realize it is not valid C# code - I said it was a "Description" of the code. I did not put it in red as the code tag would do, and I mentioned that it works most of the time. If this were truly the 'code', it would not be compiling far less working most of the time. The true code has been executed by 11 people, 6 hours a day, for 2 years. In that time the error situation I am describing has occurred about 4 times. The code itself sits on another computer and is too voluminous to reproduce here. This is not a syntax problem. If someone is on the level where they could answer this question, I think they are at the level they can fill in the blanks in the outline and perfect C# is not needed. I don't know what you mean by side-by-side and what that has to do with how code executes. The 3 items you mention serve different purposes. m_FormC is the class itself. m_FormCOpen is the boolean that tracks whether the form is dipslayed or not. Remember, the class can be instantiated but the form not necessarily displayed at a given time. FormCIsOpen is the property which allows other classes access to the member variable m_FormCOpen. Thus, you see, there are not several bools that try to keep track - there is only one. There are reasons why one class displays the form and another needs to know if it is displayed or not. The question is, that being the case, is there a safer way to accomplish it. Or, is there a known Windows/.NET problem where forms in hiding suddenly come out of hiding. You haven't given a meaningful alternative or any explanation for why the methodology here would fail. My impression is you were too quick to respond. Slow down. If you don't want to take the time to understand something that isn't immediately obvious to you, it would be better to not respond at all than to do so in a nonconstructive manner. Saying the code is a complete mess is not constructive. Confusing a class with a bool with a property is not constructive. But, if you were truly trying to be helpful, then thanks for taking the time. ;)
A form knows whether it is visible or not, there is no need to try to keep that in a boolean. Less code = less bugs Better readability = better code :)
Luc Pattyn [My Articles] [Forum Guidelines]
-
I have the situation where Form A is hidden when Form C is displayed and then when Form C is closed, Form A is displayed again. Almost all of the time it works as expected. Occasionally, though, both forms are seen displayed at the same time. For the most part, no one can tell me the steps they went through when it happens. It has been witnessed mostly in debug mode. The one time it happened in release mode was also the one time we knew the steps that led it to happen - a test procedure was being run. However, when the test procedure was repeated at a later date the 2 windows were correctly mutually exclusive. Any ideas? Description of the code: When ClassB is instantiated, it sets the member variable m_FormCOpen = false. Later, upon user selection, FormA will call method1 in ClassB. method1 instantiates FormC, subscribes to the closed event for FormC, sets m_FormCOpen = true, displays FormC, does some database updating, and returns. The method in FormA checks the property for m_FormCOpen and if it is true, hides FormA. The method in ClassB that is executed when FormC closes, triggers an event to which FormA has subscribed, and FormA is displayed.
public class FormA
{
public FormA (ClassB)
{
m_ClassB = ClassB;
}private void ClassA_Load ()
{
subscribe to ClassB ClosedFormC – routine to call: ClassB_ClosedFormC.
}private void UserSelection_Click()
{
m_ClassB.method1();
If FormCIsOpen
{
Hide();
}
}ClassB_ClosedFormC()
{
Show();
}
} // end of ClassApublic class ClassB
{
public void ClassB()
{
m_FormCOpen = false;
}public void method1()
{
FormC m_FormC = new FormC();
subscribe to FormC.Closed – method to call FormC_Closed
m_FormCOpen = true;
m_FormC.Show();
do some stuff
}private void FormC_Closed
{
trigger ClosedFormC
m_FormCOpen = false;
}bool FormCIsOpen
{
get
{
return m_FormCOpen;
}
}
}// end ClassBWell... I realize that this is not the real code, but rather a pseudo code of it... However, it looks like this code is not thread-safe. This means that there might be a chance that sometimes, under certain circumstances,
m_FormCOpenis misleading your program because of thread-safety issues. If you don't know what "thread-safe" means, I'de suggest reading on the following topics: - Thread Safety - Threads Synchronization - Locking Mechanisms. :) Good luck, Shy. -
I have the situation where Form A is hidden when Form C is displayed and then when Form C is closed, Form A is displayed again. Almost all of the time it works as expected. Occasionally, though, both forms are seen displayed at the same time. For the most part, no one can tell me the steps they went through when it happens. It has been witnessed mostly in debug mode. The one time it happened in release mode was also the one time we knew the steps that led it to happen - a test procedure was being run. However, when the test procedure was repeated at a later date the 2 windows were correctly mutually exclusive. Any ideas? Description of the code: When ClassB is instantiated, it sets the member variable m_FormCOpen = false. Later, upon user selection, FormA will call method1 in ClassB. method1 instantiates FormC, subscribes to the closed event for FormC, sets m_FormCOpen = true, displays FormC, does some database updating, and returns. The method in FormA checks the property for m_FormCOpen and if it is true, hides FormA. The method in ClassB that is executed when FormC closes, triggers an event to which FormA has subscribed, and FormA is displayed.
public class FormA
{
public FormA (ClassB)
{
m_ClassB = ClassB;
}private void ClassA_Load ()
{
subscribe to ClassB ClosedFormC – routine to call: ClassB_ClosedFormC.
}private void UserSelection_Click()
{
m_ClassB.method1();
If FormCIsOpen
{
Hide();
}
}ClassB_ClosedFormC()
{
Show();
}
} // end of ClassApublic class ClassB
{
public void ClassB()
{
m_FormCOpen = false;
}public void method1()
{
FormC m_FormC = new FormC();
subscribe to FormC.Closed – method to call FormC_Closed
m_FormCOpen = true;
m_FormC.Show();
do some stuff
}private void FormC_Closed
{
trigger ClosedFormC
m_FormCOpen = false;
}bool FormCIsOpen
{
get
{
return m_FormCOpen;
}
}
}// end ClassBHere's a theory: If someone clicks twice in FormA fast enough for the second click to be queued before the form is hidden, it would open two instances of FormC. When closing one of the instances, FormA would be shown. You can prevent multiple instances of FormC to be opened:
private void UserSelection_Click() {
if (!m_ClassB.FormCIsOpen) {
m_ClassB.method1();
if (m_ClassB.FormCIsOpen) {
Hide();
}
}
}--- single minded; short sighted; long gone;
-
Here's a theory: If someone clicks twice in FormA fast enough for the second click to be queued before the form is hidden, it would open two instances of FormC. When closing one of the instances, FormA would be shown. You can prevent multiple instances of FormC to be opened:
private void UserSelection_Click() {
if (!m_ClassB.FormCIsOpen) {
m_ClassB.method1();
if (m_ClassB.FormCIsOpen) {
Hide();
}
}
}--- single minded; short sighted; long gone;
This is a very good theory - especially from the excerpt I put out. I had greatly simplified UserSelection_Click. The selection comes from a VS 2003 data grid - the code is determining a double click based on MouseUp, etc. Things stop, i.e., the clock doesn't start for a second double click, until method1 has completed, so I don't think this is exactly the problem. Maybe something similar to what you are describing is happening earlier in the pipe, though. I just haven't been able to find it yet. And, your code suggestion is good to put in as a fail-safe. If nothing else, if the problem pops up again with this code in, then it will narrow down the possibilities some more. Thanks.
-
A form knows whether it is visible or not, there is no need to try to keep that in a boolean. Less code = less bugs Better readability = better code :)
Luc Pattyn [My Articles] [Forum Guidelines]
For this design, there is. Note that 'the boolean' is in ClassB - not FormC. FormC does know when it closes, but method1 has already finished its execution by this time. FormC alerts others to its closing via an event. ClassB sets the boolean based on this event. ClassA can now access the information via a property provided by ClassB. ClassB has visibility to FormC. FormA does not. Thus, FormA cannot ask FormC are you open or closed.
-
Here's a theory: If someone clicks twice in FormA fast enough for the second click to be queued before the form is hidden, it would open two instances of FormC. When closing one of the instances, FormA would be shown. You can prevent multiple instances of FormC to be opened:
private void UserSelection_Click() {
if (!m_ClassB.FormCIsOpen) {
m_ClassB.method1();
if (m_ClassB.FormCIsOpen) {
Hide();
}
}
}--- single minded; short sighted; long gone;
Fix turned out to be: Application.DoEvents(); Hide();