How to cancel this event

[Rob Peterson]

Hi there,

Does anyone know how to actually "abort" the event (component change)
described in the following link. Apparently it's doable as mentined in the
"Remarks" section but how. Alternatively, it would be better to prevent this
event from being raised in the first place if anyone knows the procedure.
Note that my users will be modifying a form's properties on a
"System.ComponentModel.Design.DesignSurface" and I simply want to disable
their ability to drag and resize a ontrol using the mouse, keyboard, etc.
Thanks.

http://msdn2.microsoft.com/en-us/lib...ng(VS.80).aspx

[igd]

Just override the event handler in your class and do not call base(...)
in the overidden event handler:

protected override void OnComponentChanged(
Object component,
MemberDescriptor member,
Object oldValue,
Object newValue
)
{
// now this handler is called instead of the handler of the base
class when
// the ComponentChanged-event occurs
}

Rob Peterson schrieb:

Hi there,

Does anyone know how to actually "abort" the event (component change)
described in the following link. Apparently it's doable as mentined in the
"Remarks" section but how. Alternatively, it would be better to prevent this
event from being raised in the first place if anyone knows the procedure.
Note that my users will be modifying a form's properties on a
"System.ComponentModel.Design.DesignSurface" and I simply want to disable
their ability to drag and resize a ontrol using the mouse, keyboard, etc.
Thanks.

http://msdn2.microsoft.com/en-us/lib...ng(VS.80).aspx

[Rob Peterson]

Just override the event handler in your class and do not call base(...)

in the overidden event handler:

protected override void OnComponentChanged(
Object component,
MemberDescriptor member,
Object oldValue,
Object newValue
)
{
// now this handler is called instead of the handler of the base
class when
// the ComponentChanged-event occurs
}

Thanks for the response. I wish it were that easy however (or maybe it is
but I'm still mucking around with this stuff). What I've done is download a
component posted by a MSFT blogger which I'm now trying to unravel out so I
can customize it (see here if you're interested
http://blogs.msdn.com/mharsh/archive...4/395304.aspx). His component
allows you to display an arbitrary form in design mode (at runtime) so users
can change it just like programmers do in the VS forms designer (it's really
a mini component that wraps the latter). What basically happens is that you
pass his component an arbitrary form and it does the following:

1) Creates a new (blank) "Form" which encapsulates a "DesignSurface" member
(initializing it accordingly)
2) Copies the form you passed onto the newly created "DesignSurface" (in 1
above)
3) Invokes "DesignSurface.GetService()" to retrieve an
"IComponentChangeService" interface
4) Sets the "ComponentChanging" event on the above interface to capture any
user changes

You can now call "ShowDialog()" on the form created in 1) above and it
displays the form you passed on a design surface just like in the VS form's
designer. You can therefore move and resize all your form's controls just
like in VS. I want to prevent this however. Item 4) above is invoked
whenever the user makes any changes so I can't simply provide an override
(or don't see how at this point but I'm not sure if it's the correct
approach here even if it is doable). Doing nothing in the handler has no
effect BTW as the user's changes are still processed. I'd really just like
to prevent the user from moving/resizing the controls in the first place but
still can't find a way to do it. I think I might have to make the control's
size and locations properties read-only but I've played with this and can't
figure out how to do it. Any additional insight would be welcome though I
realize it may be a lot to swallow if you're not already familir with this
stuff. Thanks.

[Stoitcho Goutsev \(100\)]

This event is supressed during loading/unloadin the control since obviously
the whole internal state of the event is changed, thus it doesn't give much
information.

In order to cancel a property from changing you need to throw an exception
form the IComponentChangeService.ComponentChangingevent handler
--
HTH
Stoitcho Goutsev (100)

"Rob Peterson" <no_spam@_nospam.comwrote in message
news:Op**************@TK2MSFTNGP03.phx.gbl...

Hi there,

Does anyone know how to actually "abort" the event (component change)
described in the following link. Apparently it's doable as mentined in the
"Remarks" section but how. Alternatively, it would be better to prevent
this event from being raised in the first place if anyone knows the
procedure. Note that my users will be modifying a form's properties on a
"System.ComponentModel.Design.DesignSurface" and I simply want to disable
their ability to drag and resize a ontrol using the mouse, keyboard, etc.
Thanks.

http://msdn2.microsoft.com/en-us/lib...ng(VS.80).aspx

[Rob Peterson]

This event is supressed during loading/unloadin the control since

obviously the whole internal state of the event is changed, thus it
doesn't give much information.

In order to cancel a property from changing you need to throw an exception
form the IComponentChangeService.ComponentChangingevent handler

Thanks very much! That actually works but the documentation makes no mention
of it which worries me (is it officially supported). While I will rely on it
if necesarry (I need to find out if it is supported first), it's still a
little unwieldy. That is, the user is still able to move the control but
throwing the exception causes the system to "pop" it back into place (not
the cleanest approach by MSFT). I'd really like to know how to prevent users
from moving it in the first place noting that the sizing grips still appear
around the control when the user clicks it. This misleads them into thinking
they can re-size it (the exception actually prevents it) so there must be a
way of disabling all this without spending a month investigating things. At
least I now have a fallback method just in case however. Thanks again for
your help (greatly appreciated).

[Stoitcho Goutsev \(100\)]

Actually throwing exception is documented in MSDN as the way of preventing
component from changing.
http://msdn2.microsoft.com/en-us/lib...tchanging.aspx

As far as it goes for freazing the control so it cannot be moved or hiding
the resizing handlers I believe this is possible to be achieved by the
Behavior Service. I haven't done it myself, but as a starting point I'll
suggest read through the following MSDN article:
http://msdn2.microsoft.com/en-us/library/ms171820.aspx

Here also links to information regarding classes participating in the
designtime behavior feature:
BehaviorService class
http://msdn2.microsoft.com/en-us/lib...orservice.aspx
Behavior class
http://msdn2.microsoft.com/en-us/lib....behavior.aspx
Glyph class
http://msdn2.microsoft.com/en-us/lib...ior.glyph.aspx
Adorner class
http://msdn2.microsoft.com/en-us/lib...r.adorner.aspx
--
HTH
Stoitcho Goutsev (100)


"Rob Peterson" <no_spam@_nospam.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...

>This event is supressed during loading/unloadin the control since
obviously the whole internal state of the event is changed, thus it
doesn't give much information.

In order to cancel a property from changing you need to throw an
exception form the IComponentChangeService.ComponentChangingevent handler

Thanks very much! That actually works but the documentation makes no
mention of it which worries me (is it officially supported). While I will
rely on it if necesarry (I need to find out if it is supported first),
it's still a little unwieldy. That is, the user is still able to move the
control but throwing the exception causes the system to "pop" it back into
place (not the cleanest approach by MSFT). I'd really like to know how to
prevent users from moving it in the first place noting that the sizing
grips still appear around the control when the user clicks it. This
misleads them into thinking they can re-size it (the exception actually
prevents it) so there must be a way of disabling all this without spending
a month investigating things. At least I now have a fallback method just
in case however. Thanks again for your help (greatly appreciated).

[Rob Peterson]

Actually throwing exception is documented in MSDN as the way of preventing

component from changing.
http://msdn2.microsoft.com/en-us/lib...tchanging.aspx

Thanks very much. The link I was looking at was for the event since that's
what I'm hooking. Unlike the method in the above link, it makes no mention
of the exception. See here:

http://msdn2.microsoft.com/en-us/lib...ng(VS.80).aspx

As far as it goes for freazing the control so it cannot be moved or hiding
the resizing handlers I believe this is possible to be achieved by the
Behavior Service. I haven't done it myself, but as a starting point I'll
suggest read through the following MSDN article:
http://msdn2.microsoft.com/en-us/library/ms171820.aspx

Here also links to information regarding classes participating in the
designtime behavior feature:
BehaviorService class
http://msdn2.microsoft.com/en-us/lib...orservice.aspx
Behavior class
http://msdn2.microsoft.com/en-us/lib....behavior.aspx
Glyph class
http://msdn2.microsoft.com/en-us/lib...ior.glyph.aspx
Adorner class
http://msdn2.microsoft.com/en-us/lib...r.adorner.aspx

I'll take a look at this. I'm very new to this area but I know that .NET 2.0
introduced the "DesignSurface" class which is what I'm working with (not a
custom designer per se). I'm still working on a conceptual understanding of
the issues however so it will take some time to get my head wrapped things.
Thanks again though.