Kind of event overriding

I have an object that works with an external treeview
(myObject.TreeView = formTreeView)
On myObject.TreeView = formTreeView assigment an AftreSelect event is
being attached inside the object code.
The problem is that formTreeView may have its AfterSelect event that
will be executed before myObject AtferSelect when I want it to be
executed after.

But how to do it?


MH

Nick
Tue Feb 28 07:00:47 CST 2006


"Marius Horak" <nobody@europe.con> wrote in message
news:%23YD$EIGPGHA.3360@TK2MSFTNGP09.phx.gbl...
>I have an object that works with an external treeview
> (myObject.TreeView = formTreeView)
> On myObject.TreeView = formTreeView assigment an AftreSelect event is
> being attached inside the object code.
> The problem is that formTreeView may have its AfterSelect event that
> will be executed before myObject AtferSelect when I want it to be
> executed after.
>
> But how to do it?

You can't.

The whole point of events as compared to public delegates is that you can't
mess with them from outside the class. If this wasn't the case you would
have a massive security hole.

You'll have to rethink your design - possibly derive your own class from
TreeView and create a new event to fire first.

Stoitcho
Tue Feb 28 08:15:14 CST 2006

Marius,

You can't control the order of event processing. The idea behind this design
pattern is that you don't care and basically don't know how many listeners
you have, thus you don't care about the order of execution.

There are different design patterns such us "Chain of Responsibility" where
you can guarantee the order of execution.


--
HTH
Stoitcho Goutsev (100)

"Marius Horak" <nobody@europe.con> wrote in message
news:%23YD$EIGPGHA.3360@TK2MSFTNGP09.phx.gbl...
>I have an object that works with an external treeview
> (myObject.TreeView = formTreeView)
> On myObject.TreeView = formTreeView assigment an AftreSelect event is
> being attached inside the object code.
> The problem is that formTreeView may have its AfterSelect event that
> will be executed before myObject AtferSelect when I want it to be
> executed after.
>
> But how to do it?
>
>
> MH

Marius
Wed Mar 01 03:54:11 CST 2006

Nick Hounsome wrote:

> You can't.

I must say this is a major overlook on a part of M$.

> The whole point of events as compared to public delegates is that you
> can't mess with them from outside the class. If this wasn't the case
> you would have a massive security hole.

I don't agree with a such approach.
Either I'm in control or I'm being controled by some stupid rules.

> possibly derive your own class from TreeView

The best way to get into a mess.

MH

Nick
Wed Mar 01 07:43:01 CST 2006


"Marius Horak" <nobody@europe.con> wrote in message
news:O4MgYYRPGHA.720@TK2MSFTNGP14.phx.gbl...
> Nick Hounsome wrote:
>
>> You can't.
>
> I must say this is a major overlook on a part of M$.

I don't think that you will find anyone to agree with you.

>
>> The whole point of events as compared to public delegates is that you
>> can't mess with them from outside the class. If this wasn't the case
>> you would have a massive security hole.
>
> I don't agree with a such approach.
> Either I'm in control or I'm being controled by some stupid rules.

You are in control of YOUR classes - why should you have control over
someone else's class that they don't want to give you?

As I said it is POSSIBLE to use a public multicast delegate (either as a
field or a property) instead of an event. In this case the user of your
class could add,remove or rearrange the order of delegate invocation at
will.

>
>> possibly derive your own class from TreeView
>
> The best way to get into a mess.

No - it's quite straightforward: all events in the framework are fired from
virtual methods called "On..." . You just need to override the appropriate
method and raise your own event before calling the base implementation to
raise the original event.

Stoitcho
Wed Mar 01 08:22:57 CST 2006

Marius,

This is not overlook at all. This is the way this design patern is defined
and has to work.


--

Stoitcho Goutsev (100)

"Marius Horak" <nobody@europe.con> wrote in message
news:O4MgYYRPGHA.720@TK2MSFTNGP14.phx.gbl...
> Nick Hounsome wrote:
>
>> You can't.
>
> I must say this is a major overlook on a part of M$.
>
>> The whole point of events as compared to public delegates is that you
>> can't mess with them from outside the class. If this wasn't the case
>> you would have a massive security hole.
>
> I don't agree with a such approach.
> Either I'm in control or I'm being controled by some stupid rules.
>
>> possibly derive your own class from TreeView
>
> The best way to get into a mess.
>
> MH
>
>

Marius
Thu Mar 02 04:19:20 CST 2006

Nick Hounsome wrote:

> I don't think that you will find anyone to agree with you.

Well, in such case M$ went mad when they made the KeyPress event public.
Can you imagine the mess one can create in an application when a user
types for example FCUK as a company name?

MH

Marius
Thu Mar 02 04:21:13 CST 2006

Stoitcho Goutsev (100) wrote:

> This is not overlook at all. This is the way this design patern is
> defined and has to work.

Yes, yes, The Big Brother knows better what I want.

MH

Nick
Thu Mar 02 05:10:20 CST 2006


"Marius Horak" <nobody@europe.con> wrote in message
news:upUlJMePGHA.2624@TK2MSFTNGP12.phx.gbl...
> Stoitcho Goutsev (100) wrote:
>
>> This is not overlook at all. This is the way this design patern is
>> defined and has to work.
>
> Yes, yes, The Big Brother knows better what I want.

No - the big brother knows better what MOST people using C# want and
security comes high on the list.

BB neither knows nor cares what you as an individual want especially as,
according to your email address, your are nobody :-)

Marius
Thu Mar 02 06:21:30 CST 2006

Nick Hounsome wrote:

> No - the big brother knows better what MOST people using C# want and
> security comes high on the list.

There is no such thing as "security" for developers (just for end
users), this is just a tool limitation.
If a developer wants to do something he/she should be able to do it.
Remember, those stupid computers are here to serve people.

Security? Which system do you prefer when crossing a road?

German, where can cross a road only in selected places and you have to
wait for a green light or face penalty

or

UK, where you can cross a road at any place and time, but watch the
traffic before crossing.


Most of the progress was made by people who took a risk (even when they
had to break a rule or two).

MH

nobody@con.eu -> EU is one big con and due to stupid rules sooner or
later everyone will be "nobody" in EU. EU rules will control your life
(using computers and M$ software)

Nick
Thu Mar 02 07:57:51 CST 2006


"Marius Horak" <nobody@europe.con> wrote in message
news:%23re5WPfPGHA.1124@TK2MSFTNGP10.phx.gbl...
> Nick Hounsome wrote:
>
>> No - the big brother knows better what MOST people using C# want and
>> security comes high on the list.
>
> There is no such thing as "security" for developers (just for end
> users), this is just a tool limitation.

Developers are also users of other developers libraries.

> If a developer wants to do something he/she should be able to do it.
> Remember, those stupid computers are here to serve people.

You can do something stupid. But why do you expect MS ti help you? They are
busy enough doing their own stupid things :-)
>
> Security? Which system do you prefer when crossing a road?
>
> German, where can cross a road only in selected places and you have to
> wait for a green light or face penalty
>
> or
>
> UK, where you can cross a road at any place and time, but watch the
> traffic before crossing.

The analogy is not a good one - in neither case is your security enforced in
the same sense as we are talking about - they penalize breach of rules
rather than make it impossible - A better analogy would be a pedestrian
footbridge with no access to the road at all.

> Most of the progress was made by people who took a risk (even when they
> had to break a rule or two).

We are not talking about rules here - If it was just a rule then you would
have just broken it and not posted a question.

If you want to take risks then write in C++ not C#.

> MH
>
> nobody@con.eu -> EU is one big con and due to stupid rules sooner or
> later everyone will be "nobody" in EU. EU rules will control your life
> (using computers and M$ software)

I can't argue with that :-(

P.S. We are in the wrong group here anyway - it should be the csharp one.

Stoitcho
Thu Mar 02 08:12:43 CST 2006

> If a developer wants to do something he/she should be able to do it.

If you want it you should go ahead and implement it. The framework and the
languages gives you everything to do it.


--

Stoitcho Goutsev (100)