473,372 Members | 848 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,372 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 7667
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Adriano Coser | last post by:
Hello. I'm facing the exact problem described here:...
0
by: Adriano Coser | last post by:
Hello. I have an ExpandableObjectConverter subclass that I associate to the 'Converter' of a custom property descriptor. After I changed my .net code to the new syntax (VC 2005), the...
6
by: Dennis | last post by:
I am trying to get the properties of a DataTable or DataView using the following code where obj is an object set to either a DataTable or DataView: If TypeOf obj Is DataSet Then myDataList =...
0
by: Nebelung | last post by:
Hi! I've written a custom ExpandableObjectConverter in which I have overridden GetPropertiesSupported and GetProperties (and some more). By setting breakpoints in all methods I have found out...
0
by: Nebelung | last post by:
Hi! I've written a custom ExpandableObjectConverter in which I have overridden GetPropertiesSupported and GetProperties (and some more). The class to which this TypeConverter is applied has all...
0
by: Nebelung | last post by:
In a custom ExpandableObjectConverter I have overridden GetPropertiesSupported (always returns true) and GetProperties. The class to which this TypeConverter is applied has only public properties...
9
by: Patrick | last post by:
Hello All, Does anyone know what order GetProperties() returns public properties in? I'm using custom Attributes on the properties of my Business objects (NHibernate) to let me know if they should...
6
by: Larry Smith | last post by:
Hi there, Can anyone provide any insight on why MSFT introduced "TypeConverter.GetProperties()". There are two classes for dealing with metadata in .NET, 'Type" and "TypeDescriptor". Each has a...
3
Fr33dan
by: Fr33dan | last post by:
I'm having trouble getting the Type.GetProperty(string) method to return the property that I need. Whenever I call it all I get is a null value even thought the type that i'm calling does contain the...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...

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.