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/library/system.componentmodel.design.icomponentchangeservice.componentchanging(VS.80).aspx

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/library/system.componentmodel.design.icomponentchangeservice.componentchanging(VS.80).aspx

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

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.com> wrote in message
news:(E-Mail Removed)...
> 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/library/system.componentmodel.design.icomponentchangeservice.componentchanging(VS.80).aspx
>
>

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

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.com> wrote in message
news:%(E-Mail Removed)...
>> 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).
>

> 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/library/system.componentmodel.design.icomponentchangeservice.componentchanging(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.