|
hi guys, i'm looking for all over the internet i a just cant find it, i am almost giving up... So, how can i desable a menustrip item from another form. ex: i have a form1(mdi) and i open inside it a form2, and from this form2, i wanna desable a form1 menustrip item. thanks
sorry for the bad english.
|
|
|
|
|
Rather than trying to do this directly, you may which to look into using an application level state engine to which both forms can subscribe. Then whenever a form receives focus it can update its UI state to the configuration contained in the state engine.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
|
Sorry. I should have been clearer.
You can create a static class (public static class ClassName) where you store the values. If you place this class in your UI project, you can use it to store properties relating to the visibility of controls. (ie. public static bool thisControlIsVisible{ get; set; }). In your forms, you can use the appropriate event handler for gaining focus to coordinate the visibility or enabled states of controls on a given form.
Example. In Form1, an action taken by the user requires that menustrip item in Form2 be disabled. Form1 will set a variable in the static state class indicating this. When Form2 receives focus, it will automatically check these values and update itself appropriately.
Some people may suggest that you use the App.Config file for this purpose, but I would strongly suggest you not do that because the changes you effect to the app.config at runtime will be maintained and used the next time the application is run again.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
ok, thank you very much!!! it was a very good answer
|
|
|
|
|
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);
}
...
}
|
|
|
|
|
thank you vary much... works great!!!
|
|
|
|
|
You're welcome. Don't forget to vote if you found the answer useful.
|
|
|
|
|
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.
|
|
|
|
|
Agreed.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
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 I won't.
Edit : and, in fact, you did in your previous post 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
|
|
|
|
|
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.
|
|
|
|
|
No problem Marcus No it's up to the OP to choose the one that best suits its needs.
|
|
|
|
|
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;
|
|
|
|
|
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.
|
|
|
|
|
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;
|
|
|
|
|
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.
|
|
|
|
|
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;
|
|
|
|
|
|
Hello,
i've downloaded the STUN-Client from codeproject.com and want now to let two clients connect each other.
At first, i create a UdpClient and make a STUN-Query with that. After it, i send the mapped addresses to a server, which deploys them to the two clients. Now they want to connect each other and i make a UdpClient.Connect(mappedIP). This _should_ work, but the problem is, i only get messages from the STUN-Server. I send the data via "UdpClient.Client.SendTo(...)" to my client, but nothing works. I just get crptic messages from the STUN-Server. I've closed the UdpClient. Disconnected and so on, but nothing helps.
Has anybody a solution for me?
|
|
|
|
|
softwarejaeger wrote: i've downloaded the STUN-Client from codeproject.com
I assume this is from an article somewhere? If so, the appropriate place to ask this question is on the article forum. It's extremely unlikely that the author will just happen to stumble across your question and answer it. It's even less likely that somebody else will take the time to download this software, and debug it for you to see what's going wrong.
|
|
|
|
|
hey guys..i want to show 4 or 5 rows in a single cell..for example i have a firm name and it has 5 phone numbers at last.. the thing i want to do is when i list the firm names i want that kind of firm name will be written in a cell and in next cell its phone number will be listed..how i can do that
something like that..
vemedya.com
|
|
|
|
|
erdinc27 wrote: i want to show 4 or 5 rows in a single cell
Add 5 rows, and owner-draw your rows. Don't paint the borders on the "inner" rows, and you're set.
I are Troll 
|
|
|
|
|
hey friend..thanks for the reply..i tried but i couldnt find an owner-draw in properties or where i should set it ?
vemedya.com
|
|
|
|
|
It's not a property, it's a technique. It's described here[^] 
I are Troll 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
