Java Development

[arkadyz]

I think you are confused somewhat. Overriding paint changes only the screen appearance. Clicks are processed in touchEvent and navigationClick methods (both of which you can override, though touchEvent requires caution). It is up to you to decide what are the conditions for clicks to be associated with the image.

Try to formally define what exactly you want to achieve - such a definition usually contains solution inside . If you can't figure it out, post the definition here and we will help.

[david_schwartz_bb]

Thank.

Here is my req:

The screen should have a ObjectListField that scrolls.

On the top right, below the banner is a bitmap (see black area in pic I posted) that user will click to open another screen.

While the user scrolls the ObjectListField the bitmap should always remain on top right.

Currently I have the 2 vertical managers setup & the screen displays properly. I have 2 items left to do:

1. Keep the bitmap from scrolling. Looking into your suggestion of 'scroll listener'

2. make the bitmap clickable.

[arkadyz]

I see. Now, the bitmap is not exactly "clickable" in the sense that there is no way to propagate a trackball/touchpad click to it. However, you can override the touchEvent so that you can tap it and some action will follow.

This can be achieved with a touchEvent override on the level of your non-scrolling, bitmap-displaying manager. Similar to the following:

protected boolean touchEvent(TouchEvent message) {
  int x = message.getX(1);
  int y = message.getY(1);

  if (/* x and y are within your Bitmap's area */) {
    bool isBitmapClicked = false;
    if (message.getEvent() == TouchEvent.CLICK) {
      isBitmapClicked = true;
    } else if (message.getEvent() == TouchEvent.GESTURE && message.getGesture().getEvent() == TouchGesture.TAP) { // just one example - you should decide which gestures are relevant
      is BitmapClicked = true;
    }
    if (isBitmapClicked) {
      // Your processing goes here... - push a screen, etc., just use invokeLater to schedule it
      return true; // this will consume the event and not propagate it to the focused field
    }
  }
  return super.touchEvent(message);
}

 Good luck!

[david_schwartz_bb]

It works! Pure Gold.Thanks.

Only one issue - this does not stop the click from being processed on the ObjectListField.

if (isBitmapClicked) {
      // Your processing goes here... - push a screen, etc., just use invokeLater to schedule it
      return true; // this will consume the event and not propagate it to the focused field
    }

[arkadyz]

Interesting... Can you override touchEvent in ObjectListField as well (simply returning super.touchEvent), put the breakpoints in both the Manager's and the ObjectListField's and see which one is invoked first?

[peter_strange]

Agree with arkadyz suggestions. 

I think you will have to override all touch events within your area to stop the event being propagated.  I suspect that some 'events' are actions on UNCLICK rather than CLICK for example. 

[arkadyz · Accepted solution]

---

I think you will have to override all touch events within your area to stop the event being propagated.  I suspect that some 'events' are actions on UNCLICK rather than CLICK for example. 

---

Oops... Yes, UNCLICK is a big suspect here indeed. I've known that but forgot after two years of not working on BlackBerry .

Anyway, just like CLICK within your bitmap's area, process UNCLICK and return true to stop futher processing. In fact, many choose to modify the appearance of the clicked are on CLICK and invoke the action on UNCLICK (similar to how Web browsers have "active" state for the links - meaning pressed but not yet released).

Don't consume simple events, though - DOWN and UP in particular should be left alone. If not, more complex events (such as swipe gestures, MOVE and even CLICK) will not be detected by the system. That's why I said that caution is required when overriding touchEvent.

Good luck!

[david_schwartz_bb]

Thanks for all your help. Works great!