Re: desable a menustrip item - C# Discussion Boards

mabrahao21-Dec-10 6:07

mabrahao

21-Dec-10 6:07

ok, thank you very much!!! it was a very good answer

phil.o21-Dec-10 4:52

21-Dec-10 4:52

You can setup a method in your Form1 that would enable/disable your MenuItem. I.e. :

public Form1 : Form
{
   ...

   public void SetMenuItemState(bool enabled)
   {
      myMenuItem.Enabled = enabled;
   }

   ...
}

Then, in your Form2, you just have to call this method using the MdiParent property :

public Form2 : Form
{
   ...

   public void AnyMethod()
   {
      ((Form1)this.MdiParent).SetMenuItemState(true); // enables the menu item
   }

   ...
}

mabrahao21-Dec-10 4:57

mabrahao

21-Dec-10 4:57

thank you vary much... works great!!!

phil.o21-Dec-10 5:02

21-Dec-10 5:02

You're welcome. Don't forget to vote if you found the answer useful.

Smile | :)

fjdiewornncalwe21-Dec-10 5:10

21-Dec-10 5:10

I have a problem with this as Form2 is far to tightly coupled to Form1. This is a good solution for a beginner to use as it is simple, but when a project scales up, I would suggest against this tight coupling method.

I wasn't, now I am, then I won't be anymore.

Re: desable a menustrip item [modified]

OriginalGriff21-Dec-10 5:26

OriginalGriff

21-Dec-10 5:26

Agreed.

Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.

phil.o21-Dec-10 6:07

21-Dec-10 6:07

Sure, but with what was given, I can't think of another fast solution than that one.

If you want to give a more elegant/universal solution and explain it, feel free to do it Smile | :)

I won't.

Edit : and, in fact, you did in your previous post Smile | :)

Your solution is obviously valid, and much smarter than mine if the base requirement is an evolutive application.

modified on Tuesday, December 21, 2010 2:48 PM

fjdiewornncalwe21-Dec-10 9:59

21-Dec-10 9:59

I apologize if my previous reply came across as harsh to your answer. As this site is about experienced developers teaching and helping less experienced developers, I was reading between the lines of the question and tried to provide an answer along the lines as I would if one of my juniors approached me with this question on an enterprise level application. As any experienced dev knows, there are many ways to solve day to day problems in code like this. Answers aren't even about which is better or worse.
Every decision in development is about gain and loss. For example, in your solution, your loss is in scalability and sustainability, but your massive gain is in the time and simplicity of implementation in the given scenario. My solution has massive gains in sustainability and scalability, but takes much longer to develop upfront.

I wasn't, now I am, then I won't be anymore.

phil.o21-Dec-10 21:28

21-Dec-10 21:28

No problem Marcus Smile | :)

No it's up to the OP to choose the one that best suits its needs.

musefan21-Dec-10 6:31

musefan

21-Dec-10 6:31

I do not see how this solution is any different from your static class. Sure, your not communicating directly with Form1 with your static class but you are still referencing properties used by Form1.

Plus if you call a function in form1 from form2 you get instant result (without need for focus) - you could also create an event in Form2 that form1 responds to.

I don't claim to have a better solution, just wanted to see if you could justify why the static class is a better option?

return 5;

fjdiewornncalwe21-Dec-10 9:51

21-Dec-10 9:51

Hey musefan,

The difference is the coupling between classes. The static configuration class has an application level scope, so the two UI form classes are complete decoupled with no knowledge of each other and that is the ideal way to develop forms like this. Granted that in the question here, we are dealing with a really simple scenario which is definitely satisfied by form1 setting a value in form2 directly. If and when the project grows, will Form1 have to know about Form2 and Form3 and Form4, but not Form5? Is the setting being changed in each form, or only 1, or 2? With a static configuration class Form1 only has to know about updating one ui based property in it and any class that needs knowledge of that value can simply read it when they need it. It makes for a much cleaner, stable, sustainable, and quicker executing code base.

I wasn't, now I am, then I won't be anymore.

musefan22-Dec-10 2:29

musefan

22-Dec-10 2:29

But if Form1 has a function for settings whatever that any other form can call then no it does not need to know about Forms 2, 3 and 4 etc.

Also, with your approach of a static class. What if there are multiple instances of Form1? These may need different enabled states for controls and cannot therefore rely on a static class

BTW - I didn't vote your post

return 5;

fjdiewornncalwe22-Dec-10 3:35

22-Dec-10 3:35

But then Forms 2, 3 and 4 have to know about Form 1. What if somewhere in the future, another form gets created that can open Forms 2, 3 and 4. Now Forms 2, 3 and 4 need to have their code updated in order to deal the the new form, or Form 1 and the new form would have to be updated to inherit a common interface. The configuration settings class would need to be static in a standard winforms environment, but in the mdi environment, the config class could easily be instanced and sent around to the form constructors as a reference so that it is instance specific, but still allowing the forms to be decoupled. My point is that I have serious issues with having ui forms coupled tightly to others. The ui objects should be independent of all others and sharing of information should be done with "domain" level classes. It comes from years of "fixing" enterprise systems that were written with that tight coupling. I have a very good understanding of the pitfalls associated with this.

Anyhows.... I'm rambling because I'm bored and I have to be at work to hold the fort this week... Happy holidays to you.

I wasn't, now I am, then I won't be anymore.

musefan22-Dec-10 4:06

musefan

22-Dec-10 4:06

But then if there is multiple forms that can open forms 2, 3 and 4 then they are likely to have a different UI, which means different properties in your static class and therefore you still have to update code in Forms 2, 3 and 4 to account for this.

I do agree with you about the disadvantages of linking forms in your scenario of Forms 2, 3 and 4 can be opened by multiple forms and they need to disable controls in there parent. But regardless of the methods mentioned here, they all require Forms 2, 3, and 4 to be updated when any new Parent Forms/Controls are created

The way I see it is that if Form 2 needs to disable any controls in Form 1 then the 2 forms are already quite related (even if not directly by code). Therefore I see the best logic in being that anything in Form2 that determines that state of controls in Form1 should be presented as a property/method. Then Form1 can query the values at any time and update its own control state (perhaps an update event or if it is a Dialog then on close/result)

So...

Form2 has a property InvalidData
Form2 has an event Update
Form1 listens for Update event and then if InvalidData then disable control

...but then when Form3 pops up, you have to update code in Form1 to check state of new Forms properties. I just cannot think why a child form would need to disable controls in a parent unless that form was specifically created for that parent form alone

Oops, now I'm rambling. Happy holidays

return 5;