[MonoDevelop] Design Time Properties for Custom Controls

Matjaž Mihelič ml at arsis.net
Sat Jul 18 15:32:46 EDT 2009

On Sat, 2009-07-18 at 13:27 -0400, Andy York wrote:
> There has been a question that is very close to this one that was asked
> just a day or two ago, but I'm not sure if it is the same question or
> not. Please forgive me if I am asking the same question again.
> Using standard data types (string, bool, int, etc) for design time
> properties in custom controls in Monodevelop is easy, but I'm not sure
> how to use non-standard data types. For instance if I had an enum that
> looked like this:
>     enum ImageSize
>     {
>         XLarge,
>         Large,
>         Medium,
>         Small,
>         XSmall,
>         None
>     }

I would be interested in that to, but as I look into sources, stetic
never touches lib directly. Always over cecil, which is the biggest
design flaw any form editor could have.

In this case none of property editors which aren't hardcoded are not
possible. No custom widget (beside the sucky ones combined in stetic,
and yes they do suck) can look like it should look during design time.
Nothing you code can be activated during design time.

For now, I'm simply avoiding any usage of stetic as much as possible,
simply because it sucks as much as form editor could suck and because of
the fact I can work/rely more on hardcoded form. Make a custom widget
derived from DrawingArea, drop it into form. And it practically
disappears with height 0. And so on. Custom widgets and stetic is a big
NO GO. Now imagine having form populated with invisible widgets? I
rather write it hard way.

Correct me if I'm wrong. You'll make me the happiest man alive if I am.

> and we want the design time property to be set like this (or something
> like this):
>         private ImageSize _MyImageSize;
>         // this is where we want the design time property to be set
>         public ImageSize MyImageSize
>         {
>             set{_MyImageSize=value;}
>             get{return _MyImageSize;}
>         }
> How would we go about doing this, I know the answer is an easy one but I
> just can seem to find it even though I have searched quite a bit. I'm
> thinking that the same methods that would work for enums would work for
> classes but I'm not sure of that either.

Solving enums would be easy (just hardcode generic Property Editor for
it, solving everything else is hard). Solve that and you achieved the
same as putting bandage on torn off limb. Form designer without ability
to impose new form designers? Well, reason enough to stay away from it
for me.

Stetic should NOT be part of monodevelop or at least its AppDomain. It
should connect with remoting to it and designed to work in its own
window or connected with GtkSocket/GtkPlug to monodevelop window inside
monodevelop widget.

It should always go down and restart on recompile with all project libs
loaded the hard way. Simply as that.

I tried to do some work on that part long ago, but car crash and time I
lost because of it had forced me into different needs and I simply
haven't got time to focus back (which I still feel a bit guilty about,
because I haven't kept my promises). But if you plan on working to fix
that. I can help. Although if I'd be in your place, I'd probably rather
design my own form editor, which doesn't start with flaws than try to
fix something which is utterly broken.

Don't get me wrong. I LOVE monodevelop. Almost fanatically. I just hate
stetic which is the one part of monodevelop I'd be glad if I could get
rid of from my monodevelop like I can get rid of debugger.


> Again I apologyze if this has already been asked.
> Spoody Goon
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list

More information about the Monodevelop-list mailing list