[ungeildodger]

Hi,

I develop a Client which is not for Blackberrys only. So it is writen as normal Midlet and I try to port it on a RIM device (at the moment it is a 8700). Actions which are normaly triggered by the softkeys, have to be triggered now by a menu connected to the trackwheel.

Thus, I wrote a own TrackwheelListener that creates a net.rim.device.api.ui.component.Menu.
and I added the Listener to my Application via:

Application.getApplication().addTrackwheelListener (new
MyTrackwheelListener());

The Menu works fine, but after it is closed there is still the standart menu, which is normaly there when I press the Trackwheel in a standart Midlet (it contains only the close item).

It seems to be a TrackwheelListener a level under my Application, because in my applicationlistenerslist is no other TrackwheelListener...

How can I eliminate it?

thx

[L Jorissen]

Hello ungeildodger,

I'm new to BB developing, but I'll give it a shot
Does your class extend Screen or a subclass of it? If so, then it already implements TrackwheelListener. (see the HelloWorld example) It seems to me that you trigger both your custom TrackwheelListener and the standard TrackwheelListener. So, a matter of proper overriding will keep the standard one from appearing to my opinion.

Let us know if it helped you.

Best regards, L J.

[ungeildodger]

I found the problem. The onClick method gives a boolean back. When it is false, it seems to use an internal fallback to a standart TrackwheelListener. If it is true ends right after my handling...

[serveace6]

ungeildodger ,

I'm trying to do the same thing for my midlet. Are you just creating a class that implements the standard TrackWheenListener and then populating a Menu with MenuItems in it? I'm trying to get the position of the selected menu item when the use clicks the trackwheel, but have not any luck. Have you ran into any of these isssues? Thre is not point in extended a Screen class right?