Tech Off Thread

7 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

.NET control designer help

Back to Forum: Tech Off
  • User profile image

    I need some help with a .NET form designer.  I have a control (View) that I've written, and it has a object hanging off it (ViewOptions).  ViewOptions is essentially a bunch of simple properties (ints, strings, enums) with the occasional changed event.  For the control itself, I haven't changed the designer, but the ViewOptions shows up as a property, so I added a form to ease changes to it.

    I can make changes in the ViewOptions form, close that form, and reopen it, and my changes are still there.  However, should I close the designer, all my changes go away... so how do I persist my changes to the ViewOptions object (via the form) into the user's code?

    Are there any examples out on the web that I could check out?


  • User profile image

    A little update... in my Viewer class, the ViewOptions property is named Options.  I changed the decloration to:

    [Editor(typeof(ViewOptionsEditor), typeof(UITypeEditor))]
    public ViewOptions Options {...}

    This has given me code in the Windows Form Designer generated code area related to Options properties which I don't have default values set for yet... which is a step in the right direction.  However, any changes that I make in the ViewOptionsEditor (the form I mentioned above) are not getting persisted.  Any advice on that?  Smiley

    Thanks again!

  • User profile image

    Argh.  This is driving me crazy.  I'm going to concentrate on one property on my ViewOptions object: InitialMode.  Since this is an enum, I implemented ResetInitialMode and ShouldSerializeInitialMode.  (I know the documentation says you can use the DefaultValue Attribute, but that doesn't seem to work.)  On the Viewer control, there's the Options property as I mentioned-- I've attached DesignerSerializationVisibilty and Editor attributes to it, as I mentioned above.  I also implemented a pair of ResetOptions and ShouldSerializeOptions methods, which at this point just reset and check the one property for changes.

    The UI editor itself is working.  The property editor is working.  And when the code generator gets called, it works.

    I cannot get the danged code generator to get called!

    This is what I can fathom in terms of series of events:

    1) I load a form into the designer which has my View.  I select the control and get the properties page.  I find the "Options" property and double-click the ellipsis to trigger my ViewOptionsEditor.

    2) In the ViewOptionsEditor, I create a new Options object (from the values previously set) and pass that into my ViewOptionsUIEditor, and bring up the form.  I make a few changes in the GUI and hit OK, which brings me back into the DovumentViewEditor.  I save the changes onto the original Options object.

    3) My View.ShouldSerializeOptions method gets called, and I return true.

    4) At this point, I think that the main form code-- the one holding my View control-- should be marked as "changed" in the editor, but it's not.  If it were (and I can make it so my changing some other property, either on the form or my View control), then when I save the form, ViewOptions's serialization object gets called, and the form's Windows Form Designer code area gets updated.

    So why isn't the IDE recognizing that the Options object is getting changed in the designer?


  • User profile image

    OK, I've been coming up with a few more test scenarios.

    In one, I have a simple string property on Foo, let's say, Foo.Number.  When I go to the designer property page to edit it, I create a modal form with a text box and enter a new value.  This works-- I can enter the new value, and the parent form page gets marked as changed, so I can hit Ctrl-S, and the changed value gets persisted out to the Windows Form Designer generated code.

    In another, I have another simple string property on Foo, named DropNumber.  I chose this name because when I edit the value in the designer, I have a dropdown with a textbox in it.  This also works.

    In a third, I have an object, FooOptionsDrop, which has an drop-down (textbox) editor that only manipulates one property on FooOptionsDrop (not on the actual Foo control).  That does NOT work.

    So, I'm drawing the conclusion that the problem lies with editting an object; no matter what kind of editor I use, the parent form fails to recognize that I've made a change.  If the property in question is directly a part of the control, the changes are recognized.

    Again, please, tell me why!  What do I need to do so that the parent form recognizes changes to a control's property object?  It looks like changes to the DynamicProperties on a form are recognized, but I can't find anything that talks about how it works (nor does it show up in Reflector).


  • User profile image
    Frank Hileman

    TypeDescriptor.GetProperties(component)["PropertyName"].SetValue(component, value);

    That will:
    a) create and close DesignerTransaction so you can participate in undo/redo

    b) call OnComponentChanging/OnComponentChanged for you so the designers are informed

  • User profile image

    Thanks!  A Microsoft guy on another site recommended that I call OnComponentChanging / OnComponentChanged directly, and that ended up taking care of the problem.

    What will participating in a DesignerTransaction get me?  I'm wondering if I should change my code to follow your suggestions.

    Thanks again!!

  • User profile image
    Frank Hileman

    Without the DesignerTransaction your change will not go into the undo/redo stack. This is very important for the end user, to make sense of what is happening on the screen.

    OnComponentChanging/Changed does not by itself create a DesignerTransaction. You either have to create one yourself or use the SetValue method which wraps one around the change for you.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.