This project has moved and is read-only. For the latest updates, please go here.

Structural decision / separation of code (attributes) for the Property Grid

Nov 15, 2012 at 3:55 PM


I'm not totally sure about my point but I think it would be nice to do a separation between UI and non UI portion of the code for the PropertyGrid.

I mean that it would be nice to separate the newly added Attribute definitions (ExpandableObjectAttribute, ItemsSourceAttribute and PropertyOrderAttribute) from the same UI project (dll).

By doing so, anybody good take advantages for any "document" (DAL or business object) of the attribute without having to link to graphical component (dll).

I'm I too much theoretically picky ???


Nov 16, 2012 at 4:25 AM

Yes I understand.

Another approach is specify directly on the PropertyGrid the same information that it is retrieved from theses attributes. (Ex. adding an "IsExpandable" and "Order" attributes on the PropertyDefinition class). This would allow you to configure all this stuff without having to modify your business object to contain "ui specific" information. This is the direction I was expecting to go with in future versions.

Would it be a solution for your needs ? Any opinions ?

Nov 16, 2012 at 2:24 PM

Hello emartin,

Thanks for your quick feedback.

In fact for my needs, I already did what I suggest (with little problem about the: "[assembly: AllowPartiallyTrustedCallers]"). I separated all classes in the "Attributes" folder into another project (dll).

About your alternative... I strongly prefer to keep things closer (class and propperties with their attributes). I prefer to not have to maintain another file. It appears to me to be lots more easier to maintain "attributes" and less error prone. Yes, we can see it as non related data (UI related attributes) but we can also uses those attributes in model for any other purposes. I will stick with the separation of dll I have done myself (with the downside it has about upgrading).

In fact, I suggested that for 2 reasons. I think it would translate to better code but also to be able to upgrade my code with furtur version more easily (I'm kind of a lazy programmer :-)).

Thanks for sharing your very great code. I really enjoy using it.


Nov 16, 2012 at 6:48 PM

Thanks for your feedback. I hope you can understand how valuable it is for us.

This issue has been created to response to your need:

Nov 16, 2012 at 7:00 PM

My  understanding of the .net framework mechanics is that even if you refer to a "UI" dll from a project and that the executed code in this dll is "UI" less, it will not load any of the UI dlls at runtime. It shouldn't stop you to use it with your "business objects" project.

Nov 16, 2012 at 9:31 PM

I'm not sure to understand.

I do not want to reference a DLL done for UI from a business object. The dll where the business object is defined could be used in many scenario where no UI are requested. If it is linked to a UI dll, then the dll has to follow the business object dll which is undesirable. It is not a major problem. Its only a question of dependency. It is highly recommanded to never depends on UI related object or dll from a business model.

It is not very important. It is far from being major. I'm picky !!!

Jan 21, 2013 at 4:11 PM

tongbong left a comment in the issue giving his preference to have a rich "PropertyDefinition" class in order to control the "UI specific" attributes. So maybay both solutions would be needed to answer all need.s