[Tigmeister]

Hi,

I've a few questions to ask, and I dont expect anyone to have ALL the answers, and to be honest, a nudge in the right direction would be great (although I may have to ask for further clarification if something is not entirely clear). Any help would be much appreciated guys.

We're trying to run a standard J2ME app on Blackberry devices. So far we've managed to get it displaying the application correctly, and the remaining issues include the following:

1) Keyboard mappings are correct for the most part. However the 'e' and 'x' buttons (which are also the 2 and 8 num pad keys) dont display text, they simply move up and down. This is because of the following VerticalBreakOut code:

//#if polish.vendor == RIM
    	//# if(hasHorizontalBreakOut){
    	//#     if(number == -1 && gameKeyCode == Canvas.UP){
    	//#			informBreakListener(MBreakOutListener.TOP);
    	//#			return;
    	//#		}
    	//#		else if(number == -1 && gameKeyCode == Canvas.DOWN){
    	//#			informBreakListener(MBreakOutListener.BOTTOM);
    	//#			return;
    	//#		}
    	//#	}
    	//# keyPressEvent(keyCode, gameKeyCode, number);
    	//# return;    	
    	//#else

2) The scroll wheel UP and DOWN movement seems to be linked to these 'e' and 'x' characters. Is it the case that you can't have one without the other? (this would seem impracticle)

3) I'm not clear on how to get the trackwheel click assigned to a soft key as well as the back button bellow the track wheel (i'm not sure what this is called).

4) It also seems there is not complete resource which holds all the keycodes for the whole set of blackberry buttons, is this the case?

Thanks in advance.

Regards,

tig*

[simon.hain]

4. you can find the keycodes within the interface Characters.

1. overwrite public boolean keyChar(char key, int status, int time) and implement your behaviour for your assigned keys, return super.keyChar(key, status, time) for the rest.

trackwheel events are handled by implementing TrackwheelListener.
you get roll (2.) and click (3.)-events there, handle them as you want and call super for the rest.
the button below the trackwheel is usually Caracters.ESCAPE

[Tigmeister]

In Response:

4) Thanks for the character key codes.

1) In regards to overwritting the keyChar() I'm unsure of where to do this. We have several applications using the J2ME library (including Canvas etc) Now these applications are all dependent on custom objects/components in a shared project using the J2ME libraries as well.

I'm assuming I should implement this in the parent component object, which is shared throughout all the projects. Looking at the return type, when i try and return super.keyChar(key, status, time); I am told that the method keyChar(char, int, int) is undefined for the type object - so i implement the KeyListener class, however, I still have this same problem.

Needless to say, I'm a bit perplexed...

2) and 3) Although each of our applications is dependent on the common code. Does the TrackwheelListener need to be implemented in each individual application.

As I'm sure you can tell, I'm at a novice level, so if my questions seem a bit silly, its because I'm attempting to familiarise myself with the overall structure of our system, and where and how to implement the required solutions.

Regards,

tig*

p.s. if you require further explanation of how things are tied together on my side, just ask.

[Tigmeister]

O.k.

I've given this some more thought to 1)

If i remove the preprocessing code then the buttons wont be mapped to UP and DOWN. I will then need to implement the TrackwheelListener functionality, and when I've done that, then the UP and down would be mapped to the trackwheel.

Regards,

Tig*

[simon.hain]

canvas and Managers are two concepts, one from j2me, one from RIM.
if you take a look at javax.microedition.lcdui.Canvas in the RIM API you can see that the trackwheel events are mapped to canvas events (up/down or left/right together with ALT). It seems there is no way to find out if it was the scroll wheel or a key mapped to 'down' that was used.

If you want to use that you have to move on to the RIM classes. net.rim.device.api.ui.Screen has access to keychar, trackwheelroll etc.

hope that clarified the issue a bit, feel free to ask more

[Tigmeister]

Thanks for that, it helped alot.

So what I'm looking to do now is implement TrackwheelListener (with the required trackwheelClick, trackwheelUnclick and trackwheelRoll methods. I'm going to implement that in the Main class. Will it be an issues that my main class extends MIDlet and not UiApplication?

Regards,

Tig*

[Tigmeister]

So i've had a go at implementing the trackwheelClick().

What I'm attempting to get it to do is:

1) get the array of commands associated with this panel (as we have a set of panels which can be used, each with at most two commands submit/select and back)

2) Check that the command type is Command.OK - so its either submit/select or other OK action.

3) As its a command action, call CommandAction of Mediator class with the command and the displayable, and then return true, as its work3ed successfully.

4) otherwise return false.

I've tested this, and failed (no action associated with click when running app), and I've come to a bit of a dead end. Any tips would be great, just to help me see if its an error with my logic, or some other type of error.

here's the code

/**
	 * Overwriting the trackwheelClick() so that when the track wheel is 
	 * clicked, then we can set the command action to carry out. Use SPanelMediator
	 * to access the different command actions.
	 */
    public boolean trackwheelClick( int status, int time )
    {
    	SPanelMediator mediator = new SPanelMediator(this, frame);
    	Displayable disp = Display.getDisplay(this).getCurrent();

    	// all the commands associated to this panel.
    	Command[] command = frame.getCurrentPanel().getCommands();
    	
    	for (int i=0; i<command.length; i ++){
    		Command com = command[i];
    		
    		// command type is OK, so we should continue with an o.k. command.
    		if (com.getCommandType() == Command.OK)
    		{
    			mediator.commandAction(com, disp);
    			return true;
    		}
    	}
    	
    	return false;
    }

Regards,

Andrew

[Tigmeister]

When I test this, the close menu option appears in the top right hand of the screen. And it doesnt process the commandAction.

Do I need to remove the default close menu item, for my commandAction to be registered?

[simon.hain]

trackwheelClick
...
Returns:
True if the event was consumed; otherwise, false.

if you return false the event is not consumed and the default behaviour is executed (your code should have been executed too, though).

did you put some check (sys.out) into your code to see if it was reached properly? maybe a breakpoint to follow the steps?

[Tigmeister]

O.k,

I've got some system.out statements printing in in the output window of the Remotre debugger, so at least I know I've gotten somewhere. Unfortunately, any breakpionts I add do not prompt anymore detailed debugging, so it looks like i'm going to have to do it with a whole bunch of print lines.

Now, I am a bit perplexed... In the SMain.java main class of this app, I've implemented the TrackwheelListener, and i've overwritten the trackwheelClick(), but when I run the app, and press the trackwheelClick() nothing gets printed out in my sys.out checks.

Any Idea about this?

Regards,

Tig*

[Tigmeister]

p.s. I've added the following "Application.getApplication().addTrackwheelListene r(this);" from another forum thread to my startApp() as there is no SMain() constructor

protected void startApp() throws MIDletStateChangeException {
    	Application.getApplication().addTrackwheelListener(this);
    	System.out.println("SMAIN startApp()");
		if (frame == null || Display.getDisplay(this).getCurrent() == null) {
			init() ;
		}else {
			frame.getCurrentPanel().doFullRepaint = true;
			frame.getCurrentPanel().repaint() ;
		}
	}

The system out works fine...

Possibly this doesnt work as my application is implementing MIDlet and not UIApplication? (just a thought)

[Tigmeister]

O.k.

I found that we have this Object MFrame, which extends Canvas, which our applications are built on. Now When we build for a blackberry, we use MFrame_BlackBerry class, and this is where I have implemented the TrackwheelListener interface. Each of the trackwheellistener methods are implemented, and each of them has system.our.println() statements which are printing to the debugger, so that we can see what exactly is happening.

Now, I've checked, and ensured that the application uses the MFrame_BlackBerry (i've tested this with sys.out statements). Unfortunately, the application is not printing out when there is a trackwheel event. This leads me to think that either the listener is not registered (which I have attempted to register) or that it may not be capable of this functionality. Does anyone actually know if it is possible to get the trackwheel to fire events correctly when creating u're applications as MIDlet?

Regards,

Tig*

[Tigmeister]

Well, I've figured out how to register the trackwheellistener.

Basically, in the Canvas style object which your app is built on (In my case, as i'm extending MIDlet for my application, I use MFrame_BlackBerry, which extends Canvas) you need to implement the TrackwheelListener interface. Once you have implemented the methods for this class, you will need to add the listener to the static instance of Application as follows.

Application.getApplication().addTrackwheelListener(this);

This is all fairly straight forward, and can be found on several forums. Now the final part which is necessary, when you are using a MIDlet is set the current display to your object extending Canvas.

The sample code from another forum is:

 /////////midlet class /////////////

import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;

public class TestMIdletTest extends MIDlet
{
Display _display;

protected void startApp()
{
_display = Display.getDisplay(this);
_display.setCurrent(new TestMidletCanvas(this));
}

protected void pauseApp()
{
}

protected void destroyApp(boolean unConditinal)
{
notifyDestroyed();
}
}

/////////// canvas class //////////

import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
import net.rim.device.api.system.*;
import net.rim.device.api.ui.component.*;
import net.rim.device.api.ui.*;

class TestMidletCanvas extends Canvas implements TrackwheelListener
{
MIDlet _midlet;
int _result;
public TestMidletCanvas(MIDlet midlet)
{
_midlet = midlet;
Application.getApplication().addTrackwheelListene r(this);
}

public void paint(javax.microedition.lcdui.Graphics g)
{

}

public boolean trackwheelClick(int status,int time)
{
System.out.println("click"); // Apply break point here............................................. ..
net.rim.device.api.ui.Screen scr= UiApplication.getUiApplication().getActiveScreen( );
if(UiApplication.getUiApplication().getActiveScre en() instanceof Dialog)
{
UiApplication.getUiApplication().popScreen(UiAppl ication.getUiApplication().getActiveScreen());
}
return true;
}

public boolean trackwheelUnclick(int status,int time)
{
System.out.println("unClick");
return true;
}

public boolean trackwheelRoll(int amount,int status,int time)
{
System.out.println("roll");
_result = Dialog.ask(Dialog.D_YES_NO);// uncomment for tesdting

return true;
}

}

In my situation, it was necessary to approach it like this

Display.getDisplay(this).setCurrent((MFrame_BlackBerry)frame);

But as you've got this far, I'm sure you can figure out how to apply in your instance.

One thing to note, tho, is i'm having repaint() issues, and I suspect it could be the conflicts due to attempting to merge Midlets and UIApplication components. Will let you know if i find a response to this issue.

Regards,

Tig*

[Tigmeister]

Hi,

I just want to quickly touch on a few things.

Firstly, the repaint() issues I was having were not precisely to do with the conflicts due to attempting to merge Midlets and UIApplication components. But what you need to know, is that the paintBackground() Method causes a canvas.clear() on a Blackberry device, so it will be necessarry to redraw all your components.

Secondly, I'd like to touch on/correct something simon.hain said, and If I misunderstood you I'm sorry.

canvas and Managers are two concepts, one from j2me, one from RIM.
if you take a look at javax.microedition.lcdui.Canvas in the RIM API you can see that the trackwheel events are mapped to canvas events (up/down or left/right together with ALT). It seems there is no way to find out if it was the scroll wheel or a key mapped to 'down' that was used.

I figured out how to determine if it is the trackwheel or a key mapped to 'down' that is pressed. Basically, I check the keyCode when the event occurs, and I have determined what the range of keycodes for each of the characters is. If it is one of those character keycodes, then u know it was a key that was pressed.

Anyways, the keyCode for the trackwheel up and down are specifically set to 6 and 1 i think, so it can be determined from there.

I hope that is actually useful to someone.

Tig*

[emmanuelfrancis]

Hi,

I tried above but keyPressed method is not called when 8800 menu is press on canvas.
Please help, if there is anything more to be added in code.