In C#, how do I code 'this = that'?

[Charles Jenkins]

I want to make a MenuItem that I can 'click' programmaticall y. I
started by coding this:

class ClickableMenuIt em : MenuItem {

public void DoClick( EventArgs e ) {
OnClick( e );
}

ClickableMenuIt em( MenuItem mi ) {
// What do I do here?!?
// this = mi; <--- does not work
}
}

As you can see, I have no idea of how to tell ClickableMenuIt em to take
all of its fields and events from MenuItem upon construction.

How would you do this?

[Marc Gravell]

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 ClickableMenuIt em to mimic the
ctors of MenuItem, then it should be enough to simple create and add
ClickableMenuIt em instances to your menus, instead of MenuItem
instances. The downside is that this might confuse the IDE a bit,
maybe.

Marc

[Mathieu Cartoixa]

Charles Jenkins a écrit :

I want to make a MenuItem that I can 'click' programmaticall y. I started
by coding this:

class ClickableMenuIt em : MenuItem {

public void DoClick( EventArgs e ) {
OnClick( e );
}

ClickableMenuIt em( MenuItem mi ) {
// What do I do here?!?
// this = mi; <--- does not work
}
}

As you can see, I have no idea of how to tell ClickableMenuIt em to take
all of its fields and events from MenuItem upon construction.

How would you do this?

Hi,

Have you checked the method MenuItem.Perfor mClick 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 ClickableMenuIt em instance
whenever you need one, instead of creating a MenuItem instance that will
only be used to initialize a new ClickableMenuIt em 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 ClickableMenuIt em 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 ClickableMenuIt em elements "by hand" in your form
constructor, after the call to InitializeCompo nents(). Use inheritance.
You would not want any parameter in your constructor either.
* let the designer create your MenuItem. Then create your
ClickableMenuIt em elements "by hand" in your form constructor, after the
call to InitializeCompo nents(). Use composition (which in this case
seems to be a rather long and fastidious if you do it properly...).

Hope this helps.

Mathieu

[Charles Jenkins]

On 2006-08-21 10:16:34 -0400, "Marc Gravell" <ma**********@g mail.comsaid:

Assuming you make ctors available on ClickableMenuIt em to mimic the
ctors of MenuItem, then it should be enough to simple create and add
ClickableMenuIt em 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
ClickableMenuIt em usefulMenuItem = new ClickableMenuIt em(
sadlyLimitedMen uItem );
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

[Greg Young]

Aside from Mathieu's great point on "PerformCli ck" ...

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.comwr ote in message
news:2006082110 040716807-notmyaddress@no therecom...

>I want to make a MenuItem that I can 'click' programmaticall y. I started by
coding this:

class ClickableMenuIt em : MenuItem {

public void DoClick( EventArgs e ) {
OnClick( e );
}

ClickableMenuIt em( MenuItem mi ) {
// What do I do here?!?
// this = mi; <--- does not work
}
}

As you can see, I have no idea of how to tell ClickableMenuIt em to take
all of its fields and events from MenuItem upon construction.

How would you do this?

[Charles Jenkins]

On 2006-08-21 10:38:52 -0400, Mathieu Cartoixa
<mathieu.cartoi xa@_NO_hotmail_ SPAM_.comsaid:

Thanks for trying to help me!

Have you checked the method MenuItem.Perfor mClick 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.Perfor mClick() 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 ClickableMenuIt em instance
whenever you need one, instead of creating a MenuItem instance that
will only be used to initialize a new ClickableMenuIt em 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
ClickableMenuIt em to inherit from MenuItem so that it can call
OnClick(); but I need each new ClickableMenuIt em 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
ClickableMenuIt em cmi = new ClickableMenuIt em( menuItem );
cmi.DoClick();

* isolate your ClickableMenuIt em 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 ClickableMenuIt ems
using the designer, I would have to create a ClickableContex tMenu,
right?

* create your ClickableMenuIt em elements "by hand" in your form
constructor, after the call to InitializeCompo nents(). Use inheritance.
You would not want any parameter in your constructor either.
* let the designer create your MenuItem. Then create your
ClickableMenuIt em elements "by hand" in your form constructor, after
the call to InitializeCompo nents(). 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 ClickableMenuIt em 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 ClickableMenuIt em 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 ClickableMenuIt em : MenuItem {

private MenuItem m_mi;

public ClickableMenuIt em( 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!

[Charles Jenkins]

On 2006-08-21 12:13:55 -0400, "Greg Young"
<dr************ *******@hotmail .comsaid:

Aside from Mathieu's great point on "PerformCli ck" ...

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!

[Andreas Mueller]

Charles Jenkins wrote:

On 2006-08-21 10:16:34 -0400, "Marc Gravell" <ma**********@g mail.comsaid:

>Assuming you make ctors available on ClickableMenuIt em to mimic the
ctors of MenuItem, then it should be enough to simple create and add
ClickableMenuI tem 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

[Bruce Wood]

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....

[Charles Jenkins]

On 2006-08-21 12:51:12 -0400, "Bruce Wood" <br*******@cana da.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!