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
Post by: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...
Post by:Shubhrajit Chatterjee
, Ranch Hand
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
126.96.36.199 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.�
Post by: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 ]
Post by:Eric Giguere
, Ranch Hand
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.