🚀 go-pugleaf

Hi again,

OK heard from the author and he states that the library was written using 
VS2003/2005 and is a combination of C# code and VB.NET code.

So I am confused again.

Regards, Frederick C. Wilt

"Joanna Carter [TeamB]" <joanna@not.for.spam> wrote in message 
news:45118640$1@newsgroups.borland.com...
> "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
>
>