Jason Pollard wrote:
>>2. You can implement your own Component, but you have to add it to a Panel
>>to
>>be useful. Unlike the Canvas, Panel has no paint(), so there's no way to
>>describe how your Component is rendered.
>>
>>
>
>I guess I meant to say that Components have no paint() method which can be
>overridden and called in the Panel paint() loop. You'd have to create your own
>low-level gauges and use them on Canvases.
>
>
Right - this is what I'm figuring out.
the Component paint(Graphics g) method is package scoped, so any class
that extends Component and is outside com.nttdocomo.ui.* cannot
override paint(Graphics g), which really sucks.
I was just chatting on a java list and it seems there is no simple way
round this. There's no reflection on doja right, or custom
class-loaders? Things that might conceivably get us round this.
It seems like Docomo is keen to not have anyone else develop components
to go in the appli guis. I wonder what their reasons are? I can guess
them saying, no if people can easily change components, then appli UI
usage might be inconsistent, but then why doesn't that apply to canvases
... well maybe canvases means all rules are off, but if you are in our
Panel UI then we want texboxes to always work the same way no matter
what ...
I mean they don't even provide a gauge class, when you get them in MIDP
and thus on JPhone and AU.
It seems unnecessarily obstructive to block me from creating a Gauge to
use in conjunction with their existing components.
I guess I sort of understand it, but it's very frustrating from a
development point of view.
CHEERS> SAM
Received on Wed Sep 17 12:36:26 2003