Community

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.

"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];
}

"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.