why cant i pass property as ref parameter?

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

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.

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

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

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

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

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.

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-public-properties-vs-java-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

This question has already been answered. Start a new discussion instead.