A property or indexer may not be passed as an out or ref parameter
 

why cant i pass property as ref parameter?

Re: A property or indexer may not be passed as an out or ref parameter
 

Narue if you see this thread please help, you usually know all the logical reasons behind programming concepts.

Re: A property or indexer may not be passed as an out or ref parameter
 

Because ref uses the address of the variable. Imagine a property like this:

    private bool connected;

    private string _field1;

    private string _field2;

    public string Field

    {

      get

      {

        if (connected)

          return _field1;

        else

          return _field2;

      }

      set

      {

        if (connected)

          _field1 = value;

        else

          _field2 = value;

      }

    }

Which underlying string field should "out" reference?

That should explain it all. This example is a little absurd as far as behavior but it is not uncommon for similar properties to be implemented.

Re: A property or indexer may not be passed as an out or ref parameter
 

It looks like you're asking for trouble...?

Re: A property or indexer may not be passed as an out or ref parameter
 

no, i really respect her programming skills..
thanks for your answer by the way, i will examine it when i get my work done.

Re: A property or indexer may not be passed as an out or ref parameter
 

I thought of an even better example :)

    public string FormText

    {

      get { return default(string); }

      set { }

    }

How do you propose the compiler would know what to do here

Re: A property or indexer may not be passed as an out or ref parameter
 

but Scott then tell me how you pass a function by reference(function pointer or delegate)?

Properties are almost the same thing with class methods except for snytax differences.

That is why i mentioned Narue's name in this thread, this is just something for her.

Re: A property or indexer may not be passed as an out or ref parameter
 

In this case passing a function reference is more accurate for a property than the out parameter. A property is basically the same thing as a method except how you call it. A property can throw exceptions and have logic just like a method. Think of properties in the way they were implemented in java:

// Java getter & setter

private String foo;

public String getFoo() {

  return this.foo;

}

public void setFoo(String foo) {

  this.foo = foo;

}

// access the private variable foo like this:

bar = obj.getFoo();

versus c#

// C# public property

private String _foo;

public String Foo {

  get {  return _foo; }

  set {  _foo = value; }

}

// access the private variable _foo like this:

bar = obj.Foo;

* Code borrowed from http://cephas.net/blog/2004/02/16/c-...getx-and-setx/
Its just a pain to call getters and setters like Java implemented them (according to most developers out there, and myself) so the CLR handles it differently.

A field cannot throw exceptions and is just in memory storage of a type. You can throw an exception while trying to set a field:

(null as string).ToString()

but not the field itself.

Take a look at a delegate:

public delegate void OnOpenTableEventHandler(object sender, OpenTableEventArgs e);

That is just defining a signature for a method and by using delegates you can call code outside of your assembly that you have no knowledge of at design time. A delegate is basically an 'interface' for a method -- it must implement these parameters (instead of a true interface enforcing any number of member definitions).

So think of Properties as methods and delegates as interfaces .. those two concept remain independant of field and writing with

out

.

out says -- write <datatype> in to memory at 0x00000
function reference -- execute method in memory at 0x00000

I don't know how else to explain it... I hope it is a little more clear