View mode: basic / threaded / horizontal-split · Log in · Help
March 31, 2005
AA as lvalue
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.
March 31, 2005
Re: AA as lvalue
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
March 31, 2005
Re: AA as lvalue
"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];
}
March 31, 2005
Re: AA as lvalue
> public Color buttonBorder() {
>  ColorTable ct = namedColorTable;// needs ()? I haven'te tried it

oops- that should be Color[NamedColors] ct = namedColorTable;
March 31, 2005
Re: AA as lvalue
"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.
March 31, 2005
Re: AA as lvalue
>> 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).
March 31, 2005
Re: AA as lvalue
"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.
Top | Discussion index | About this forum | D home