🚀 go-pugleaf

"Frederick C. Wilt" <fcwilt@mindspring.com> a �crit dans le message de news: 
45116e80$1@newsgroups.borland.com...

| >> [C# Error] WinForm.cs(260): Property, indexer, or event
| >> 'SomePropertyName' is not supported by the language; try directly 
calling
| >> accessor method...
|
| Sure enough if I call get_SomePropertyName() with the appropriate 
parameters
| everything is just fine.
|
| I just think its rather odd that a new language like C# would not handle
| properties of all sorts given that properties are not a new concept.

I think you will find that this is not a limitation of C#, but of the 
language that the third-party assembly was written in. Take the time to 
create your own small DLL in C# and try to use it from C#, you will find no 
such problems.

Have another look at the documentation that you cited before :

| Note that when calling property read methods that require input parameters

At this point, I believe there should be a comma in the text, not after 
"C#".

| using C#, "get_" must be appended to the property name.

The correct English word is prepended, not appended; I think this text is 
written by a someone who has a poor command of English and that you need to 
interpret it rather than read it :-)

| This is an idiosyncrasy of the C# language

This is just not true, full stop, period.

| and is not a naming convention inconsistency within this API.

Following on from mly last comment, this is also blatantly untrue.

If you have to call get_SomePropertyName(), then this is a function call, 
not a property, the parentheses at the end indicate that this cannot be a 
property.

My guess is that the language that this assembly was written in does not 
support the concept of properties, insisting instead on the use of getter 
and setter methods.

Is there any indication of the original language of the assembly ? I may be 
totally wrong, but I thought that Delphi for .NET properties had to have 
accessors named like this, but this shouldn't affect what is seen from 
outside of an assembly.

Here is the IL for part of a class written in C# in an assembly that is used 
from other assemblies

.class public abstract auto ansi beforefieldinit MyType
      extends object
{
      .property string Name
      {
            .get instance string Carter.Framework.MyType::get_Name()
      }

...


.method public hidebysig specialname instance string get_Name() cil managed
{
      .maxstack 1
      .locals init (
            [0] string text1)
      L_0000: nop
      L_0001: ldarg.0
      L_0002: ldfld [mscorlib]System.Reflection.PropertyInfo 
Carter.Framework.Property::info
      L_0007: callvirt instance string 
[mscorlib]System.Reflection.MemberInfo::get_Name()
      L_000c: stloc.0
      L_000d: br.s L_000f
      L_000f: ldloc.0
      L_0010: ret
}

So you can see that the IL knows about properties and links the property to 
a getter method.

Here is the Delphi code for that.

public property Name: string read get_Name;

function Property.get_Name: string;
begin
      Result := self.info.Name
end;

...and here is the C# code

public string Name
{
      get
      {
            return this.info.Name;
      }
}

...which you can see doesn't have the concept of a separated method.

But, much more telling is the MC++ code

public: __property System::String __gc* get_Name()
{
      return this->info->Name;
}

My conclusion is that your DLL is written in Managed C++

Joanna

-- 
Joanna Carter [TeamB]
Consultant Software Engineer