Messages by Bo

It's quite simple, purshare a Kuix licence.

And thanks for supporting us.

Actualy all Focusable derived widgets has focusable and enable attribute. But enable has an highest priority on focusable. To be short, a disabled widget is not focusable.

In first reflexion this behavior is the best way to manage those two attributes.

But wouldn't it be better if a disabled widget could be focusable ?

The first bug is fixed on SVN.

Or you can fix it by replacing in ScrollBar.java @ line 75 :

barLayoutData = new StaticLayoutData(null, 0, 0);

by

barLayoutData = new StaticLayoutData(null, -1, -1);

Else, we will investigate the focusLoop problem ... sorry for this problem and thanks for your report.

The doc is fixed, sorry for thie mistake.

MenuPopups doesn't extends PopupBox, then you can have a different style configuration for each kind of widget.

Or simply do something like this (if you define the grayed color at a high level) :

menupopup {

grayed-color:none;

}

Hmm ... the problem come from that the textare use the FlowLayout to render each word as a separate widget. And then the FlowLayout assume that a break widget has a null size.

Does your custom widget extends Textare ? Else you can split the text en break return into several sub textarea en add a gap spacing between each one.

First you screenfirstmenu code is quite strange. It may be preferable to have a flat strucutre.

Else, you can handle tabitem selection change by doing something like this :

<tabfolder>

<tabitem onSelect="mySelect(A)" onUnSelect="myUnselect(A)">

...

</tabitem>

<tabitem onSelect="mySelect(B)" onUnSelect="myUnselect(B)">

...

</tabitem>

...

</tabfolder>

For menu adaptation, you can do several things :

• Use the Kuix.loadMenuContent(Menu menu, String xmlFilePath, DataProvider dataProvider) method by replacing the menu variable by something like screen.getFirstMenu() and use an XML defined menu.
• Use MenuPopup as a list with a renderer and bind it to a dataprovider property

<screenfirstmenu>

Menu

<menupopup>

<_renterer><![CDATA[

<menuitem>

<_onAction>${itemAction}</_onAction>

${itemName}

</menuitem>]]>

</_renrerer>

<_items>@{items}</_items>

</menupopup>

</screenfirstmenu>

The "menu adaptation will be done in the onMessage of the frame that intercept the mySelect ans myUnSelect actions.

I'm not sure tu understand what you meen by "I would like to traverse each image...".

Heu ... don't you omit your code ?

Yes, this is a knowed problem. But the problem occure only if you define a grayed color for menupopups. Why defining this style attribute and after add a line into Desktop to ignore it ?

Fixed, sorry for this problem.

- See changelog

- With this new version of Kuix, the commercial multi licence ha been removed to be replaced by a Corporate licence with an unlimited number of application.

Finaly the next Release of Kuix will be named 1.1.0 because of non retro compatibility with the 1.0.1 on some features like PopupBox, etc ...

If you use your own MIDlet with your own KuixInitializer, you need to write something like this :

KuixInitializer initializer = new MyKuixInitializer();
KuixCanvas canvas = new KuixCanvas(initializer, true);
KuixConverter converter = new KuixConverter();
Kuix.initialize(null, canvas, converter);

Then you can see here that the creation of the Converter is created inline, then the only thing that you need is to instantiate your own converter and pass it to the Kuix.initialize(...) method.

This feature is based on the native J2ME Canvas.sizeChanged(int w, int h) event. But it seems that on few j2ME implementations, this event is not invoked when the display switch from portrait to landscape (I think a bout som Windows Mobile implementation for example)