I want to make a MenuItem that I can 'click' programmatically. I
started by coding this:
class ClickableMenuItem : MenuItem {
public void DoClick( EventArgs e ) {
OnClick( e );
}
ClickableMenuItem( MenuItem mi ) {
// What do I do here?!?
// this = mi; <--- does not work
}
}
As you can see, I have no idea of how to tell ClickableMenuItem to take
all of its fields and events from MenuItem upon construction.
How would you do this?
14  1908 
In inheritance, the sub-class *is intrinsically composed of* the base
class, so you can't pass another one into the ctor for it to absorb.
You could theoretically pass one in as a template to copy, but I don't
think this is what you are trying to achieve.
However, you also shouldn't need to do any of this...
Assuming you make ctors available on ClickableMenuItem to mimic the
ctors of MenuItem, then it should be enough to simple create and add
ClickableMenuItem instances to your menus, instead of MenuItem
instances. The downside is that this might confuse the IDE a bit,
maybe.
Marc
Charles Jenkins a écrit :
I want to make a MenuItem that I can 'click' programmatically. I started
by coding this:
class ClickableMenuItem : MenuItem {
public void DoClick( EventArgs e ) {
OnClick( e );
}
ClickableMenuItem( MenuItem mi ) {
// What do I do here?!?
// this = mi; <--- does not work
}
}
As you can see, I have no idea of how to tell ClickableMenuItem to take
all of its fields and events from MenuItem upon construction.
How would you do this?
Hi,
Have you checked the method MenuItem.PerformClick in MSDN ?...
As for your solution, I think you are a bit confused because you want
both inheritance and composition : you will have to choose. If you
inherit from MenuItem, then why not create a ClickableMenuItem instance
whenever you need one, instead of creating a MenuItem instance that will
only be used to initialize a new ClickableMenuItem instance ?...
OK, I guess that is because you used the designer to create your menu,
and you could only create MenuItem instances this way... Then there
would be three workarounds :
* isolate your ClickableMenuItem in a library and add it to the
designer controls. Use inheritance. The constructor would have no
parameters, and you could use it exactly like a MenuItem.
* create your ClickableMenuItem elements "by hand" in your form
constructor, after the call to InitializeComponents(). Use inheritance.
You would not want any parameter in your constructor either.
* let the designer create your MenuItem. Then create your
ClickableMenuItem elements "by hand" in your form constructor, after the
call to InitializeComponents(). Use composition (which in this case
seems to be a rather long and fastidious if you do it properly...).
Hope this helps.
Mathieu
On 2006-08-21 10:16:34 -0400, "Marc Gravell" <ma**********@gmail.comsaid:
Assuming you make ctors available on ClickableMenuItem to mimic the
ctors of MenuItem, then it should be enough to simple create and add
ClickableMenuItem instances to your menus, instead of MenuItem
instances. The downside is that this might confuse the IDE a bit,
maybe.
Marc
Your advice is perfect, but I have had severe problems lately in that
any custom conrol I create works just fine for a while, but sooner or
later, they always confuse the IDE. The VS 2005 Designer gets in a
state where it will no longer display the custom control (or any form
which contains it).
Therefore, I am trying to find a solution that allow me to use only
standard controls on my form, with no visual inheritance, and then add
the behaviors I actually need at runtime. I was hoping to be able to do
something like this:
// Convert the control the designer understands to the one I actually need
ClickableMenuItem usefulMenuItem = new ClickableMenuItem(
sadlyLimitedMenuItem );
usefulMenuItem.DoClick();
But, you are absolutely right: If the Visual Studio 2005 designer
didn't suck, using inherited controls in the IDE would be the correct
solution
Aside from Mathieu's great point on "PerformClick" ...
It seems that what you are trying to do is a decorator pattern (perhaps a
look at the pattern will clear thing sup a bit?)
Cheers,
Greg
"Charles Jenkins" <no************@not.here.comwrote in message
news:2006082110040716807-notmyaddress@notherecom...
>I want to make a MenuItem that I can 'click' programmatically. I started by
coding this:
class ClickableMenuItem : MenuItem {
public void DoClick( EventArgs e ) {
OnClick( e );
}
ClickableMenuItem( MenuItem mi ) {
// What do I do here?!?
// this = mi; <--- does not work
}
}
As you can see, I have no idea of how to tell ClickableMenuItem to take
all of its fields and events from MenuItem upon construction.
How would you do this?
On 2006-08-21 10:38:52 -0400, Mathieu Cartoixa
<mathieu.cartoixa@_NO_hotmail_SPAM_.comsaid:
Thanks for trying to help me!
Have you checked the method MenuItem.PerformClick in MSDN ?...
I am using the .NET Compact Framework, which seems to be designed for
frustration, becaue the method you NEED is never available. For
instance, MenuItem.PerformClick() does not exist in the Compact
Framework.
As for your solution, I think you are a bit confused because you want
both inheritance and composition : you will have to choose. If you
inherit from MenuItem, then why not create a ClickableMenuItem instance
whenever you need one, instead of creating a MenuItem instance that
will only be used to initialize a new ClickableMenuItem instance ?...
OK, I guess that is because you used the designer to create your menu,
and you could only create MenuItem instances this way... Then there
would be three workarounds :
Great guesses! You are really sharp!
Because the VS 2005 designer is not reliable for custom controls, I am
trying to put plain old controls (with no visual inheritance) onto my
forms, then add the behaviors I need at runtime. I need
ClickableMenuItem to inherit from MenuItem so that it can call
OnClick(); but I need each new ClickableMenuItem to get its state from
the MenuItem that is actually available. I want to be able to do
something like this:
// Use what we have to create what we actually need
ClickableMenuItem cmi = new ClickableMenuItem( menuItem );
cmi.DoClick();
* isolate your ClickableMenuItem in a library and add it to the
designer controls. Use inheritance. The constructor would have no
parameters, and you could use it exactly like a MenuItem.
I think this would require the kind of inheritance that would lead me
to have problems with the designer. In order to add ClickableMenuItems
using the designer, I would have to create a ClickableContextMenu,
right?
* create your ClickableMenuItem elements "by hand" in your form
constructor, after the call to InitializeComponents(). Use inheritance.
You would not want any parameter in your constructor either.
* let the designer create your MenuItem. Then create your
ClickableMenuItem elements "by hand" in your form constructor, after
the call to InitializeComponents(). Use composition (which in this case
seems to be a rather long and fastidious if you do it properly...).
These workarounds still require me to make the ClickableMenuItem to get
its state (fields and event handlers) from the MenuItem I want to
impersonate. That leads me back to this question. Given that I cannot
say "this = that," how do I copy all the MenuItem's fields and events
from the MenuItem I have into the ClickableMenuItem that I want?
Oddly enough, I really *did* attempt to combine inheritance and
composition, just like you guessed, in the hope that an inherited
control could gain access to the protected methods of the member
control's instance---
class ClickableMenuItem : MenuItem {
private MenuItem m_mi;
public ClickableMenuItem( MenuItem mi ) {
m_mi = mi;
}
public void DoClick( EventArgs e ) {
m_mi.OnClick( e );
}
}
Of course, that does not work. I can call OnClick() in my own instance
(where it would do no good) but not in m_mi (which has the handlers I
want to fire). That approach would have been wrong and very wasteful,
but if it had worked, I could have lived with it.
Have a great day, and thanks!
On 2006-08-21 12:13:55 -0400, "Greg Young"
<dr*******************@hotmail.comsaid:
Aside from Mathieu's great point on "PerformClick" ...
It seems that what you are trying to do is a decorator pattern (perhaps
a look at the pattern will clear thing sup a bit?)
I have a book on C# Design Patterns, so I will do just as you say and
read up on the Decorator pattern.
Thanks!
Charles Jenkins wrote:
On 2006-08-21 10:16:34 -0400, "Marc Gravell" <ma**********@gmail.comsaid:
>Assuming you make ctors available on ClickableMenuItem to mimic the
ctors of MenuItem, then it should be enough to simple create and add
ClickableMenuItem instances to your menus, instead of MenuItem
instances. The downside is that this might confuse the IDE a bit,
maybe.
Marc
Your advice is perfect, but I have had severe problems lately in that
any custom conrol I create works just fine for a while, but sooner or
later, they always confuse the IDE. The VS 2005 Designer gets in a state
where it will no longer display the custom control (or any form which
contains it).
Are your custom controls and the containing controls in the same
project? The VS2003 designer had problems with that, so the VS2005
designer might have them, too. It typically happened when I had a user
control and one that contains it open inside the designer at the same time.
The solution was to factor the user controls into another library.
Also, whenever you encounter such an behavior, don't save anything,
close all open windows then and close VS. Then delete the bin and obj
folder. Reopen VS and recompile the solution. Should work fine again.
Its not a perfect solution, but I can live with this workaround since
VS2002 :-(
HTH,
Andy
Your advice is perfect, but I have had severe problems lately in that
any custom conrol I create works just fine for a while, but sooner or
later, they always confuse the IDE. The VS 2005 Designer gets in a
state where it will no longer display the custom control (or any form
which contains it).
I'm still using VS2003, but when I experience problems like this I find
that they are usually related to compilation of dependant assemblies.
Are your custom controls in a DLL that is then used by the project
experiencing the difficulties?
Come to think of it, I've even seen this behaviour when the custom
controls are defined in the same project. My solution: close all
designer windows without saving anything, close the solution, recompile
all solutions from the "bottom up": library DLLs, then control DLLs,
then data layer, then business layer, then UI. That seems to sort it
out.
Of course, VS 2005 may have different problems....
On 2006-08-21 12:51:12 -0400, "Bruce Wood" <br*******@canada.comsaid:
I'm still using VS2003, but when I experience problems like this I find
that they are usually related to compilation of dependant assemblies.
Are your custom controls in a DLL that is then used by the project
experiencing the difficulties?
Come to think of it, I've even seen this behaviour when the custom
controls are defined in the same project. My solution: close all
designer windows without saving anything, close the solution, recompile
all solutions from the "bottom up": library DLLs, then control DLLs,
then data layer, then business layer, then UI. That seems to sort it
out.
Of course, VS 2005 may have different problems....
I have tried the shutdown/delete bin and obj/restart routine, and it
does not help; but your advice to manually rebuild each assembly in
turn is interesting. The next time I cannot avoid doing a custom
control, if the problem recurs, I will try that procedure.
Thank you, Bruce and Andreas!
On 2006-08-21 12:49:18 -0400, Andreas Mueller <me@privacy.netsaid:
Are your custom controls and the containing controls in the same
project? The VS2003 designer had problems with that, so the VS2005
designer might have them, too. It typically happened when I had a user
control and one that contains it open inside the designer at the same
time.
The solution was to factor the user controls into another library.
Also, whenever you encounter such an behavior, don't save anything,
close all open windows then and close VS. Then delete the bin and obj
folder. Reopen VS and recompile the solution. Should work fine again.
Its not a perfect solution, but I can live with this workaround since
VS2002 :-(
They are in a separate project within the same solution. I made a
mistake when I said the designer would not display the control or forms
that contain it. Typically, the control will display just fine in the
designer when I look at it and it will comple and run without a
problem. It is when I put the control on a form that the form becomes
unusable in the designer.
Thanks!
Charles Jenkins a écrit :
On 2006-08-21 10:38:52 -0400, Mathieu Cartoixa
<mathieu.cartoixa@_NO_hotmail_SPAM_.comsaid:
> Have you checked the method MenuItem.PerformClick in MSDN ?...
I am using the .NET Compact Framework, which seems to be designed for
frustration, becaue the method you NEED is never available. For
instance, MenuItem.PerformClick() does not exist in the Compact Framework.
I must admit I never used the Compact Framework. PerformClick seems to
be available for buttons, but not for menu items in this world :-(
<snip>
Because the VS 2005 designer is not reliable for custom controls, I am
trying to put plain old controls (with no visual inheritance) onto my
forms, then add the behaviors I need at runtime. I need
ClickableMenuItem to inherit from MenuItem so that it can call
OnClick(); but I need each new ClickableMenuItem to get its state from
the MenuItem that is actually available. I want to be able to do
something like this:
// Use what we have to create what we actually need
ClickableMenuItem cmi = new ClickableMenuItem( menuItem );
cmi.DoClick();
Well, except with Delphi, I have always been disappointed with
designers. The code they ususally produce is such a mess that they end
up being unable to deal with it after a while...
> * isolate your ClickableMenuItem in a library and add it to the
designer controls. Use inheritance. The constructor would have no
parameters, and you could use it exactly like a MenuItem.
I think this would require the kind of inheritance that would lead me to
have problems with the designer. In order to add ClickableMenuItems
using the designer, I would have to create a ClickableContextMenu, right?
I do not think so, as with inheritance a ClickableMenuItem would be a
MenuItem. That reminds me of a hack I have used with VS2003 that should
work with VS2005 : add a MenuItem to your menu vie the designer, save
your files, close the designer, and replace MenuItem with
ClickableMenuItem directly in the source code for your instance (ther
should be only two occurrences : one in the variable declaration, one in
the method InitializeComponents). Reopen the designer : you are done !
>
> * create your ClickableMenuItem elements "by hand" in your form
constructor, after the call to InitializeComponents(). Use
inheritance. You would not want any parameter in your constructor either.
* let the designer create your MenuItem. Then create your
ClickableMenuItem elements "by hand" in your form constructor, after
the call to InitializeComponents(). Use composition (which in this
case seems to be a rather long and fastidious if you do it properly...).
These workarounds still require me to make the ClickableMenuItem to get
its state (fields and event handlers) from the MenuItem I want to
impersonate. That leads me back to this question. Given that I cannot
say "this = that," how do I copy all the MenuItem's fields and events
from the MenuItem I have into the ClickableMenuItem that I want?
The first method uses inheritance : you are just not using the designer
for your specific components.
>
Oddly enough, I really *did* attempt to combine inheritance and
composition, just like you guessed, in the hope that an inherited
control could gain access to the protected methods of the member
control's instance---
class ClickableMenuItem : MenuItem {
private MenuItem m_mi;
public ClickableMenuItem( MenuItem mi ) {
m_mi = mi;
}
public void DoClick( EventArgs e ) {
m_mi.OnClick( e );
}
}
I have been there before : no matter what you are trying to achieve,
inheritance cannot live with composition (wit the same class involved,
of course ;-). It is always wrong.
But here is your real point : how to simulate the click ? Be careful
that OnClick just triggers the handlers registered to the Click event,
it does not perform any MenuItem specific action associated with the
click... The best solution if you want to call OnClick anyway is to use
inheritance and just :
public void PerformClick() {
this.OnClick(new EventArgs());
}
What if OnClick is not enough ?... I would try to use a reflector to
look deep into the MenuItem class (you can find one there : http://www.aisto.com/roeder/dotnet/), and look for a private method that
would look like a PerformClick. Then I would call it using reflection,
which is a secret way to bypass the laws of method accessibility
(beuaark)...
Last thougt : I think that if you really had separated UI code from the
rest, you would not have felt this need to call a method that does not
exist... Let me explain that : what I think you did is something that is
very usual thanks to designers, I mean add a handler to your MenuItem,
and perform your actual actions in there
public void MyForm_myMenuItem_Click(object sender, EventArgs e) {
// related actions...
}
So now you will want to programmatically click the myMenuItem to
perform the actions... Try instead to separate the code related to your
actions in another layer (most likely in another class)
public void RelatedActions()
{
// some code here
}
and just replace the preceding with :
public void MyForm_myMenuItem_Click(object sender, EventArgs e) {
RelatedActions();
}
Now, can you not try to call RelatedActions directly instead of trying
to click the menu ?
>
Of course, that does not work. I can call OnClick() in my own instance
(where it would do no good) but not in m_mi (which has the handlers I
want to fire). That approach would have been wrong and very wasteful,
but if it had worked, I could have lived with it.
Have a great day, and thanks!
Patterns are fun, but watch out for the observer. That one can be dangerous.
:)
I find that I can "re-align" my designer if I re-inherit from a standard
windows component, rebuild, view in designer, close windows, then switch
back the inheritance and rebuild.
Failing that, I reset the toolbox, remove the reference, build (watch it
whinge about the missing reference) then re-add the assembly into the
toolbox and then it works.
Failing ALL of that, I create the real thing with windows control, detach
the windows control at runtime and use reflection to copy all the designer
settings and inner controls across to my inherited version.
You can't be bothered with that you could start up a brand new .sln and
possibly even .csproj and copy the files back into the new projects and
solutions (but the speed of that depends on how much stuff you have).
Just to double check, you are aware that all designer components must have
default parameterless, constructors, right?
God the designer can suck sometimes..... but it can work (e.g. it's not
completely broken), you just have to be persistent with it.
I concur that the .NET Compact Framework sucks in comparison, but apparently
older devs tell me it's better than what they previously had (so WTF was
that like????).
My favourite is the great exceptions you get:
System.Exception
An exception occured
NO STACKTRACE. Arggghhhh!
Anyway, good luck.
Simon
"Charles Jenkins" <no************@not.here.comwrote in message
news:2006082112423043658-notmyaddress@notherecom...
On 2006-08-21 12:13:55 -0400, "Greg Young"
<dr*******************@hotmail.comsaid:
Aside from Mathieu's great point on "PerformClick" ...
It seems that what you are trying to do is a decorator pattern (perhaps
a look at the pattern will clear thing sup a bit?)
I have a book on C# Design Patterns, so I will do just as you say and
read up on the Decorator pattern.
Thanks!
Hee hee! Thanks for the advice. Maybe I oughtta seriously think about
changing careers
On 2006-08-22 16:31:11 -0400, "Simon Tamman"
<i_**********************************@NOSPAMhotmai l.comsaid:
Patterns are fun, but watch out for the observer. That one can be dangerous.
:)
I find that I can "re-align" my designer if I re-inherit from a standard
windows component, rebuild, view in designer, close windows, then switch
back the inheritance and rebuild.
Failing that, I reset the toolbox, remove the reference, build (watch it
whinge about the missing reference) then re-add the assembly into the
toolbox and then it works.
Failing ALL of that, I create the real thing with windows control, detach
the windows control at runtime and use reflection to copy all the designer
settings and inner controls across to my inherited version.
You can't be bothered with that you could start up a brand new .sln and
possibly even .csproj and copy the files back into the new projects and
solutions (but the speed of that depends on how much stuff you have).
Just to double check, you are aware that all designer components must have
default parameterless, constructors, right?
God the designer can suck sometimes..... but it can work (e.g. it's not
completely broken), you just have to be persistent with it.
I concur that the .NET Compact Framework sucks in comparison, but apparently
older devs tell me it's better than what they previously had (so WTF was
that like????).
My favourite is the great exceptions you get:
System.Exception
An exception occured
NO STACKTRACE. Arggghhhh!
Anyway, good luck.
Simon
"Charles Jenkins" <no************@not.here.comwrote in message
news:2006082112423043658-notmyaddress@notherecom...
>On 2006-08-21 12:13:55 -0400, "Greg Young"
<dr*******************@hotmail.comsaid:
>>Aside from Mathieu's great point on "PerformClick" ...
It seems that what you are trying to do is a decorator pattern (perhaps
a look at the pattern will clear thing sup a bit?)
I have a book on C# Design Patterns, so I will do just as you say and
read up on the Decorator pattern.
Thanks!
You put a lot of time and thought into that, Matheiu, and I really
appreciate it. Thanks for helping me.
I will have to print out your reply and go over it very carefully.
Intuitively, I think your clues about better separating my actions from
user interface stuff are great points that may really help me as I
solve this problem and others in the future! :-D
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jonathan Fine |
last post by:
Giudo has suggested adding optional static typing to Python.
(I hope suggested is the correct word.)
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
An example of the syntax he proposes...
|
by: Bernd Fuhrmann |
last post by:
Hi!
I just tried to write a little program, but GCC (Mingw 3.3.1) refused to
compile it. So I'd like to know if there's something wrong with my code
or if it is a bug in GCC.
---snip---...
|
by: Chua Wen Ching |
last post by:
Hi there.
I had couple of Java codes with me that i not sure how
would i code this in C#.
I always use jcreator without ide. So a bit confuse over
c#.
Okay!
|
by: Chua Wen Ching |
last post by:
Hi there.
I had 3 questions to ask.
1)
Public Event ButtonClicked(MessageBoxNumber As Integer,
OKButton As Boolean, CancelButton As Boolean, ExitButton
As Boolean)
|
by: joshblair |
last post by:
Hello,
Has anyone ever seen or created such a code generator?
I'm looking for a sample of a code generator that will generate code
(preferably one that uses C# and the XMLTextWriter) to create...
|
by: thatos |
last post by:
The following program was supposed to read a number of years from a file called "friday.in" then print out how many of the thirteenth were on each day from monday to sunday on to a file called...
|
by: =?Utf-8?B?cm9kY2hhcg==?= |
last post by:
hey all,
please reference: http://pastebin.com/mef78b3d
As shown in the reference I am dynamically building my controls in my class.
I'd like to be able to attach javascript calls as...
|
by: Al Dykes |
last post by:
Can some post a Python code fragment that will to make a PC with Skpye
installed to make a Skype call, given a valid phone # string.
I'm not asking for code that handles the audio once the...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| | |
