471,319 Members | 1,344 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

GetProperties and Property Order


I have a simple question, but one to which I haven't (after a whole
bunch of Googling) been able to find an answer:

Are there any guarantees to the order of PropertyInfo
objects returned by a call to Type.GetProperties() ?
To explain:

I am writing utility package that is reliant on being able to process
the Properties of a type in the order they were declared (ie in
source-order).

In all my testing (across both v1.1 and v2.0 of the .NET Framework), the
list returned by a call to Type.GetProperties() *does* contain the
properties in source-order, but I haven't been able to confirm whether
this will always be the case.

Thanks in advance for your help,
Bevan.
Feb 10 '06 #1
13 7436
Thats a cool/crazy question!

I don't have an answer for you but I want to point out that if a
situation existed where the order of statements (properties or
whatever) mattered, then I don't think its OO programming anymore.
Check out Pascal or Fortran!

(Suffice to say I am still going to stay posted to this thread because
I want to know the answer too!)

Feb 10 '06 #2
Bevan Arps <be********@rbnz.govt.nz> wrote:
I have a simple question, but one to which I haven't (after a whole
bunch of Googling) been able to find an answer:

Are there any guarantees to the order of PropertyInfo
objects returned by a call to Type.GetProperties() ?
No. In particular, I believe that in 1.1 all members returned by
Type.GetXXX *were* returned in the same order each time. In 2.0, I
believe that at least some of these calls have been deliberately
changed to return the members in a random order, possibly even
different between different calls in the same process!
To explain:

I am writing utility package that is reliant on being able to process
the Properties of a type in the order they were declared (ie in
source-order).

In all my testing (across both v1.1 and v2.0 of the .NET Framework), the
list returned by a call to Type.GetProperties() *does* contain the
properties in source-order, but I haven't been able to confirm whether
this will always be the case.


Don't rely on it.

(With partial classes, by the way, there *is* no "source-order" - the
source files can be processed in different orders.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Feb 10 '06 #3
Hi,

"Bevan Arps" <be********@rbnz.govt.nz> wrote in message
news:uC**************@TK2MSFTNGP09.phx.gbl...

I have a simple question, but one to which I haven't (after a whole bunch
of Googling) been able to find an answer:

Are there any guarantees to the order of PropertyInfo
objects returned by a call to Type.GetProperties() ?
Not that I know if, and frankly I doubt it would be, first of all it's not
relevant in an OO design , also it may be dependand of both the compiler and
of the framework itself.

To explain:

I am writing utility package that is reliant on being able to process the
Properties of a type in the order they were declared (ie in source-order).
Why is this important?
In all my testing (across both v1.1 and v2.0 of the .NET Framework), the
list returned by a call to Type.GetProperties() *does* contain the
properties in source-order, but I haven't been able to confirm whether
this will always be the case.


Most probably cause the compiler create the type as it reads it, and the
asme thing happens with the framework' reflection feature. but I won't bet
on it.

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
Feb 10 '06 #4
Hi, thanks for the feedback.

I asked:
Are there any guarantees to the order of PropertyInfo
objects returned by a call to Type.GetProperties() ?
And you replied:
Not that I know if, and frankly I doubt it would be, first of all it's not
relevant in an OO design , also it may be dependent on both the compiler and
on the framework itself.
In 99% of OO designs, I'd agree with you entirely - but there's this one
case I'm working on ...
Why is this important?


In a recent project, we found that a significant amount of time was
expended in creating data entry forms for slowly changing elements of
our object domain model.

Now, these elements weren't static, so maintenance forms were needed -
yet the rate of change was slow enough that it was frustrating to spend
so much time creating an editor form for each one.

My utility package is intended to be a kind of universal editor, that
can provide a UI over any instance.

So far, I've got a set of Attributes that allow the properties of the
object to be decorated with the intent of the GUI, something like this:

public class Person {

[ TextBox( Label="Full Name", MaxLength=75) ]
public string Name { }

[ ComboBox( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

[ CheckBox( Label="Current Customer") ]
public bool Active { }

...
}

Based on these properties, a utility class builds a GUI dynamically,
including DataBinding each control to the underlying property. I've got
the whole thing up and running, and it works really well.

I guess it's a kind of declarative GUI builder - but not being able to
rely on the order of GetProperties() might be the death knell.

If you have any ideas, I'd love to hear them.

Keep Smiling,
Bevan.

PS: Yes, I've using two different accounts to participate in the same
thread - I wasn't keen on waiting until Monday to see any followups.
Hope this doesn't cause too much confusion.
Feb 11 '06 #5
"Bevan Arps" <no*********************@mailWillBounce.clear.net. nz> a écrit
dans le message de news: ea**************@TK2MSFTNGP11.phx.gbl...

| So far, I've got a set of Attributes that allow the properties of the
| object to be decorated with the intent of the GUI, something like this:
|
| public class Person {
|
| [ TextBox( Label="Full Name", MaxLength=75) ]
| public string Name { }
|
| [ ComboBox( Label="Gender", Items="Male, Female, Unknown") ]
| public string Sex { }
|
| [ CheckBox( Label="Current Customer") ]
| public bool Active { }
|
| ...
| }
|
| Based on these properties, a utility class builds a GUI dynamically,
| including DataBinding each control to the underlying property. I've got
| the whole thing up and running, and it works really well.

This approach to including UI information in a business class is very
limiting, in that it implies that your properties will always be represented
by the stated control types.

Rather than mark (taint) the business class, you could be better off
creating a UI element "Widget Factory" which takes the PropertyInfo for a
given property and hands you back a component to fit.

This then allows you to iterate through the properties, possibly sort
them(?) and replace what types of controls would be created simply by
changing the Widget Factory.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Feb 11 '06 #6

Hi Joanna.

[ Aside: Interesting to run into you on an MS Forum - I recall some
interesting conversations in the Delphi world some years ago. ]

Anyway, back on topic.

You wrote:
Rather than mark (taint) the business class, you could be better off
creating a UI element "Widget Factory" which takes the PropertyInfo for a
given property and hands you back a component to fit.
You're absolutely correct, and in practice the business domain classes
won't be tainted at all - I simplified my example, perhaps too far, in
an attempt to concentrate on my key issue of Property ordering.

The practice I follow is the classic one of separating UI from Business.
In this situation, this is by using a separate PersonEditor helper class
that encapsulates any required interactions. The editor class also
provides a bit of a Facade, translating between the business domain and
a form more suited to editing.

Let me recast the example from my previous message to demonstrate.

public class PersonEditor {

public PersonEditor(Person aPerson) { }

[ TextBox( Label="Full Name", MaxLength=75) ]
public string Name { }

[ ComboBox( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

[ CheckBox( Label="Current Customer") ]
public bool Active { }

public ValidationResult ValidateName(

...
}

Most of the properties on PersonEditor would just be accessors for the
equivalent property on the underlying Person object.

Some, such as Gender, provide some kind of transformation into a form
more suitable for a GUI.

Using Gender as an example, the field on Person is likely to be an
enumeration, where PersonEditor provides a string for easy databinding.

This then allows you to iterate through the properties, possibly sort
them(?) and replace what types of controls would be created simply by
changing the Widget Factory.


We end up back at my original question - the need to sort the properties
only comes up because I can't rely on GetProperties() returning them in
the same order as they're declared in the source.

One of the reasons that I went with "TextBoxAttribute" instead of
"StringField" was because I liked the explicit control it gave -
particularly for this situation:

[ ComboBox( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

Where I could easily write this instead:

[ RadioButtons( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

With the obvious change in the resulting GUI.

You're right, though - this could be overly specific and limiting. I'll
revisit the pros and cons of this.

Thanks for the advice,
Bevan.
Feb 11 '06 #7

Hi Joanna.

[ Aside: Interesting to run into you on an MS Forum - I recall some
interesting conversations in the Delphi world some years ago. ]

Anyway, back on topic.

You wrote:
Rather than mark (taint) the business class, you could be better off
creating a UI element "Widget Factory" which takes the PropertyInfo for a
given property and hands you back a component to fit.
You're absolutely correct, and in practice the business domain classes
won't be tainted at all - I simplified my example, perhaps too far, in
an attempt to concentrate on my key issue of Property ordering.

The practice I follow is the classic one of separating UI from Business.
In this situation, this is by using a separate PersonEditor helper class
that encapsulates any required interactions. The editor class also
provides a bit of a Facade, translating between the business domain and
a form more suited to editing.

Let me recast the example from my previous message to demonstrate.

public class PersonEditor {

public PersonEditor(Person aPerson) { }

[ TextBox( Label="Full Name", MaxLength=75) ]
public string Name { }

[ ComboBox( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

[ CheckBox( Label="Current Customer") ]
public bool Active { }

public ValidationResult ValidateName(

...
}

Most of the properties on PersonEditor would just be accessors for the
equivalent property on the underlying Person object.

Some, such as Gender, provide some kind of transformation into a form
more suitable for a GUI.

Using Gender as an example, the field on Person is likely to be an
enumeration, where PersonEditor provides a string for easy databinding.

This then allows you to iterate through the properties, possibly sort
them(?) and replace what types of controls would be created simply by
changing the Widget Factory.


We end up back at my original question - the need to sort the properties
only comes up because I can't rely on GetProperties() returning them in
the same order as they're declared in the source.

One of the reasons that I went with "TextBoxAttribute" instead of
"StringField" was because I liked the explicit control it gave -
particularly for this situation:

[ ComboBox( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

Where I could easily write this instead:

[ RadioButtons( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

With the obvious change in the resulting GUI.

You're right, though - this could be overly specific and limiting. I'll
revisit the pros and cons of this.

Thanks for the advice,
Bevan.
Feb 11 '06 #8
Jon Skeet [C# MVP] wrote:
(With partial classes, by the way, there *is* no "source-order" - the
source files can be processed in different orders.)


You're right.

In my case, however, all the properties of interest should be in the
*same* source file, so it would be sufficient to recover the order of
those properties alone.

[ See my most recent post in reply to Joanna Carter for the reasons why
this is the case. ]

Thanks,
Bevan.
Feb 11 '06 #9
"Bevan Arps" <no*********************@mailWillBounce.clear.net. nz> a écrit
dans le message de news: 43**************@mailWillBounce.clear.net.nz...

| [ Aside: Interesting to run into you on an MS Forum - I recall some
| interesting conversations in the Delphi world some years ago. ]

Well, now MS has used Borland expertise to design .NET, I really had to
follow to ensure that good OO design also follows to those who use it :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Feb 11 '06 #10
If you are using attributes on your properties, why not create an
"order" property as well?
You could even design it to allow you to ignore some properties if so
desired, or to map foreign keys to other objects.

Feb 11 '06 #11
Steven Nagy wrote:
If you are using attributes on your properties, why not create an
"order" property as well?


Yeah, it's looking like that's the solution.

I was trying to avoid it, as it increases the overhead on a dev using
the UI package. However, it seems there is no other *reliable*
technique, and I'm very hesitant to rely on happenstance.

Thanks for the input,
Bevan.
Feb 12 '06 #12
It occurs to met that there are a number of problems with your solution not
the least of which is the inability to internationalize the product.

It would seem to me that a cleaner solution is to specify the UI for the
class as a chunk of XML that you read at start up:

<UI class="Person>
<Property name="Name" label="Full Name" UI="TextBox" MaxLength="75"/>
.....
</UI>

Another advantage of this is that you do not need to hard code much as you
can use reflection to find controls and the properties on them.

Oh wait a minute! Doesn't this start to look a bit like the new windows
presentation stuff?

"Bevan Arps" <no*********************@mailWillBounce.clear.net. nz> wrote in
message news:43**************@mailWillBounce.clear.net.nz. ..

Hi Joanna.

[ Aside: Interesting to run into you on an MS Forum - I recall some
interesting conversations in the Delphi world some years ago. ]

Anyway, back on topic.

You wrote:
Rather than mark (taint) the business class, you could be better off
creating a UI element "Widget Factory" which takes the PropertyInfo for a
given property and hands you back a component to fit.


You're absolutely correct, and in practice the business domain classes
won't be tainted at all - I simplified my example, perhaps too far, in an
attempt to concentrate on my key issue of Property ordering.

The practice I follow is the classic one of separating UI from Business.
In this situation, this is by using a separate PersonEditor helper class
that encapsulates any required interactions. The editor class also
provides a bit of a Facade, translating between the business domain and a
form more suited to editing.

Let me recast the example from my previous message to demonstrate.

public class PersonEditor {

public PersonEditor(Person aPerson) { }

[ TextBox( Label="Full Name", MaxLength=75) ]
public string Name { }

[ ComboBox( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

[ CheckBox( Label="Current Customer") ]
public bool Active { }

public ValidationResult ValidateName(

...
}

Most of the properties on PersonEditor would just be accessors for the
equivalent property on the underlying Person object.

Some, such as Gender, provide some kind of transformation into a form more
suitable for a GUI.

Using Gender as an example, the field on Person is likely to be an
enumeration, where PersonEditor provides a string for easy databinding.

This then allows you to iterate through the properties, possibly sort
them(?) and replace what types of controls would be created simply by
changing the Widget Factory.


We end up back at my original question - the need to sort the properties
only comes up because I can't rely on GetProperties() returning them in
the same order as they're declared in the source.

One of the reasons that I went with "TextBoxAttribute" instead of
"StringField" was because I liked the explicit control it gave -
particularly for this situation:

[ ComboBox( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

Where I could easily write this instead:

[ RadioButtons( Label="Gender", Items="Male, Female, Unknown") ]
public string Sex { }

With the obvious change in the resulting GUI.

You're right, though - this could be overly specific and limiting. I'll
revisit the pros and cons of this.

Thanks for the advice,
Bevan.

Feb 12 '06 #13
Nick Hounsome wrote:
It occurs to met that there are a number of problems with your solution not
the least of which is the inability to internationalize the product.
You're right - there are a number of problems with the solution.
However, many of these are mitigated by factors that I haven't mentioned
in this thread.

For example, this is intended as a way to quickly put together some
basic data entry screens for maintenance of static or slowly changing
configuration data. It's not intended for the main data entry screens of
the application, nor for screens that have complex or unusual GUI
requirements. The idea is to reduce the amount of time required to
develop the simple screens, to free up time to apply where it is more
warranted.

Another example: the applications I write at work are only ever intended
for limited distribution, mostly internal to my employer.
Internationalization isn't an issue, as English is already the common
language in use. The number of potential users for each application is
often unusually small.
It would seem to me that a cleaner solution is to specify the UI for the
class as a chunk of XML that you read at start up.


A good idea - but then the solution starts feeling much more
heavyweight. Something to consider, nonetheless.

Thanks for the input.

Keep Smiling,
Bevan.
Feb 13 '06 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Adriano Coser | last post: by
6 posts views Thread by Dennis | last post: by
9 posts views Thread by Patrick | last post: by
6 posts views Thread by Larry Smith | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.