Why are you using the type of the object as the data source? surely you need
a concrete instance of some class rather than it's type - which is a whole
different thing -
Data source properties are usually Object based so that you can use any one
of the various list, collection or bindinglist style objects so the property
will happily accept a type but no sensible binding will take place.

Signature
--
Bob Powell [MVP]
Visual C#, System.Drawing
Ramuseco Limited .NET consulting
http://www.ramuseco.com
Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm
Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm
All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
>I know that this is really trivial but has been bugging me for some time
>and
[quoted text clipped - 26 lines]
>
> By the way, I used the datasource wizard to create the above.
Marc Gravell - 13 Aug 2007 10:59 GMT
To be fair to the OP, that is exactly what the IDE spits out... the
binding code has a special case for Type instances, meaning that it
(broadly) uses the TypeDescriptor.GetProperties(type) overload, rather
than the TypeDescriptor.GetProperties(object) version. This means that
it does, as you would hope, list the properties for the associated
Type, rather than the properties of a Type instance.
Marc
Is this just because you have a form (or other class) or property
whose name is the same (in a different namespace), thus confusing the
compiler?
In which case either the global:: or an alias (using SomeOtherName =
blah.bloop.ClassName) directive should suffice.
Marc
NeilL - 13 Aug 2007 14:56 GMT
Marc,
Thanks for the reply. I don't have any other classes or forms with the same
name in any namespace. This happens to be a class that is in a source file
with another class and not is a separate .cs file but that should not be the
problem.
Is there someplace in the IDE where I can specify the global:: so that I
don't have to hand edit the designer generated code each time it gets
regenerated?
Thanks

Signature
Neil
> Is this just because you have a form (or other class) or property
> whose name is the same (in a different namespace), thus confusing the
[quoted text clipped - 4 lines]
>
> Marc
Marc Gravell - 13 Aug 2007 15:12 GMT
Not that I know of.
However - on a related note, allow me to warn you that the IDE
sometimes gets very flakey about class bindings. If it decides it
doesn't like you, it will throw them all away. As such, I tend to only
work in the designer until it is "close enough", then I cut/paste the
code into a private method (and call it at some point in the
Form/Control startup).
Any more tweaks I do directly in the snipped code. You don't get to
see the columns in the designer, but it tends to last longer.
Your mileage may vary ;-p
Marc
Marc Gravell - 13 Aug 2007 15:13 GMT
Just as an aside - do you have a fragment (just a few classes etc)
that reproduce this?
Marc
NeilL - 13 Aug 2007 15:42 GMT
Thanks for the advice on not using the IDE after it gets close. I've been
using the Infragistics grid controls and have found that it does decide to
discard all my stuff for no known reason so I was moving to your cut/paste
approach.
I also tried editing the datasource file that had configuration info to see
if I could fix it up there ... no luck with that either.
As for a sample, I don't have anything that I can do easily but let me see
what I can do.
I've had exactly the same problem with components that I have in another
project where, if I drop them on a form the code generated has the same type
issue that I never figured out.

Signature
Neil
> Just as an aside - do you have a fragment (just a few classes etc)
> that reproduce this?
>
> Marc