Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Posts: 1,123
Registered: ‎02-10-2009
My Device: 8130 / 8350 / 9530 / 9550 / 9850 / PlayBook
My Carrier: Verizon

Re: Reflowing a layout manager and detecting size changes

To set the clipping when you override paint call pushContext()/pushRegion() and it will clip everything inside the region. The only thing is that you may need to adjust the offsets to start at 0,0 or whatever coordinates you need.

Posts: 2,268
Registered: ‎07-08-2009
My Device: various
My Carrier: various

Re: Reflowing a layout manager and detecting size changes

A simple solution would be to paint most of your own "fields", then call super.paint(), then paint the title thus overriding whatever those RIM fields painted there.

please click 'Accept Solution' on posts that provide the solution to the question you've posted. Don't say "Thanks", press 'Like' button instead!
New Developer
Posts: 16
Registered: ‎01-05-2009
My Device: Not Specified

Re: Reflowing a layout manager and detecting size changes

[ Edited ]

Thanks. I can't really paint the title on top of the components since in LWUIT this can be "anything", e.g. a user can just add a component in a separate container to the NORTH area of the screen. Layout managers can be completely decoupled as well.

Normally within LWUIT I can do that sort of thing since it supports z-ordering, layers and glasspane overlay. However, because RIM code runs on a separate thread we have a separation between the process of drawing LWUIT components and drawing RIM components. This leads to other side effects such as breaking z-ordering for native components which is something I'm personally willing to live with for this particular use case...


The reason LWUIT must run on a separate thread is rather complex but we need the EDT to allow some cool LWUIT features such as true modal dialogs/invokeAndBlock (foxtrot) and code that has almost no synchronization yet remains very portable.


The porting layer for RIM doesn't synchronize and instead calls invokeLater to perform operations on the RIM thread. Synchronization is just impossible to "get right" in a portable way, it will work for one use case and fail for another especially when device oddities are concerned.


The problem is that when LWUIT wants to trigger changes to a native field and have it painted, LWUIT is on the LWUIT thread... It seems to me impractical to use invokeAndWait during paint code.


I have several thoughts on how this might be changed including using RIM's paint on the LWUIT thread with a synchronized statement but I'm concerned this might not work as I expect for things such as video display which is the main reason for starting the whole native component  integration work.


I'll try to get something working so I can commit it and get some feedback, that usually seems to help since feedback is informed by actual issues people are experiencing.