Color settings in a List

[Pooja Rao]

Hi All,
I have a class which extends a List.When I select any element in the List, I want the Text or Background color of that selected element to be changed to some color, other that black(which normally happens). I am using DefaultColorPhone Emulator of J2MEWTK.
Is it possible to set Colors in List as in canvas.Is there any other way out.
Thanks,
Pooja Rao

[Valentin Crettaz]

Well, I think that's totally dependent on the underlying device... If you try to look at some sources, you would see that. At first, I thought that you could just subclass javax.microedition.lcdui.List and modify some stuff... But when you climb up the class hierarchy, you land on javax.microedition.lcdui.Display which initializes all the device-dependent constants and variables from a class called javax.microedition.lcdui.DeviceCaps (only accessible within that package). What the latter contains is just one native method called init() which asks the underlying OS for some of its capabilities to initialize some constants (screen width, height, color depth, double buffering supported,...).
So I think changing the highlight color "could" be done, but it would be risky since you would have to in some way modify Sun's classes by subclassing them, and hoping that the underlying platform supports what you are asking it to do... it might be worth trying, though. I'd do it...

[Shubhrajit Chatterjee]

Originally posted by Valentin Crettaz:
So I think changing the highlight color "could" be done, but it would be risky since you would have to in some way modify Sun's classes by subclassing them, and hoping that the underlying platform supports what you are asking it to do... it might be worth trying, though. I'd do it...

Is it possible ? ...
This excerpt is from CLDC1.0 spec ... but lcdui package is not a CLDC class, but MIDP

3.4.2.2 Protecting system classes
A central requirement for CLDC is the ability to support dynamic downloading of
Java applications to the virtual machine. An obvious security hole in the Java virtual
machine would be exposed if the downloaded applications could override the
system classes provided in packages java.*, javax.microedition.*, or other
profile- or system-specific packages. A CLDC implementation shall ensure that the
programmer cannot override the classes in these protected system packages in any
way. At the implementation level this can be guaranteed in different ways,
depending on whether or not the implementation supports preloading/prelinking of
system classes (see Section 5.4, �Classfile format and class loading.�) One solution is
to require system classes always to be searched first when performing a classfile
lookup. For security reasons, it is also required that the application programmer is
not allowed to manipulate the classfile lookup order in any way. Classfile lookup
order is discussed in more detail in Section 5.4.3, �Classfile lookup order.�

[Valentin Crettaz]

What that says, is that you cannot provide your own implementation of a javax.microedition.lcdui.List a have it loaded before the true real one.
What I said is that you are not supposed to replace classes in java.* and javax.* but you could subclass some of them, as you'd do when you develop a new component that extends javax.swing.JComponent. You just want a kind of javax.microedition.lcdui.List with which you can use different colors... I'd say it is possible since List is not final but I have never tried, though...
[ February 27, 2002: Message edited by: Valentin Crettaz ]

[Eric Giguere]

The classes in the high-level UI API are not meant to be subclassable by outside developers. In other words, there's no way to write your own custom controls that work on forms. You can write custom controls that work on a canvas, but then you have to do everything yourself.