Is there any reason why the following code shouldn't compile?

public class ColorTable {

  public Color buttonBorder() {
    return namedColorTable[NamedColors.BUTTONBORDER];  // error here:
this.namedColorTable() is not an lvalue
  }

  private enum NamedColors {
    BUTTONBORDER,
    BUTTONHIGHLIGHT
    // ... etc ...
  }

  private void initNormalColors() {
    namedColorTable_[NamedColors.BUTTONBORDER] = SystemColors.highlight;
    // ... etc ...
  }

  private Color[NamedColors] namedColorTable() {
    if (namedColorTable_ is null)
      initNormalColors();
    return namedColorTable_;
  }

  private Color[NamedColors] namedColorTable_;

}

If I change the buttonBorder() property to directly use namedColorTable_ instead of calling through the namedColorTable() property (and do initNormalColors() in the constructor) it compiles. The reason why I haven't done it that way is because I want namedColorTable() to handle Windows visual styles, perhaps like this:

    private Color[NamedColors] namedColorTable() {
        if (namedColorTable_ is null) {
            if (VisualStyleInfo.enabled) {
                if (VisualStyleInfo.colorScheme == "NormalColor")
                    initNormalColors();
                else if (VisualStyleInfo.colorScheme == "HomeStead")
                    initOliveColors();
                else if (VisualStyleInfo.colorScheme == "Metallic")
                    initSilverColors();
            }
            else
                initSystemColors();
        }
        return namedColorTable_;
    }

And namedColorTable_ would get reset to null when the user changes their preferences, meaning the color schemes get reinitialised when namedColorTable() is next called. Granted, people don't change their desktop colors that often, but they do on occasion, and an application should probably sync up with those changes if they happen while it's running. Any ideas?

John.

On Thu, 31 Mar 2005 11:54:27 +0100, John C <johnch_atms@hotmail.com> wrote:
> Is there any reason why the following code shouldn't compile?

I can't think of any.

Regan

"John C" <johnch_atms@hotmail.com> wrote in message news:d2gktk$mbk$1@digitaldaemon.com...
> Is there any reason why the following code shouldn't compile?
>
> public class ColorTable {
>
>  public Color buttonBorder() {
>    return namedColorTable[NamedColors.BUTTONBORDER];  // error here:
> this.namedColorTable() is not an lvalue
>  }

It might be easiest to change things around a little and use namedColorTable_ instead of the property namedColorTable and an lvalue ColorTable. Maybe this is a compiler bug with properties - I don't know. Sometimes I can't tell when the compiler needs () and when it doesn't. What I'm thinking:

 public Color buttonBorder() {
  ColorTable ct = namedColorTable;// needs ()? I haven'te tried it
   return ct[NamedColors.BUTTONBORDER]; // will insert if not present so it
needs an lvalue
}
or
 public Color buttonBorder() {
   validateColorTable();
   return namedColorTable_[NamedColors.BUTTONBORDER];
}

> public Color buttonBorder() {
>  ColorTable ct = namedColorTable;// needs ()? I haven'te tried it

oops- that should be Color[NamedColors] ct = namedColorTable;

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d2grh8$t9f$1@digitaldaemon.com...
>> public Color buttonBorder() {
>>  ColorTable ct = namedColorTable;// needs ()? I haven'te tried it

So far as I can tell, most cases where you needed to add () to access a property have been eliminated.

>
> oops- that should be Color[NamedColors] ct = namedColorTable;
>

Thanks, Ben. That did the trick.

>> oops- that should be Color[NamedColors] ct = namedColorTable;
>
> Thanks, Ben. That did the trick.

note you could also switch to using a dynamic array instead of an associative array and then namedColorTable could be used as an lvalue (plus it would be faster and simpler).

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d2h29r$14ss$1@digitaldaemon.com...
>>> oops- that should be Color[NamedColors] ct = namedColorTable;
>>
>> Thanks, Ben. That did the trick.
>
> note you could also switch to using a dynamic array instead of an associative array and then namedColorTable could be used as an lvalue (plus it would be faster and simpler).

Exactly the conclusion I came to - I redesigned the class using a dynamic array, since the key values for the AA were basically indexes anyway.