Java Development

[jeffrey_ese]

I am in the test stage of my application which I developed with LWUIT. On the emulators, it's all good. It functions well on all BB devices except the Storm. All goes well except in some moments when I access the menu and the app freezes with the error message I traced from the event logs that says

process myapp(288) queue too large(31); user input event(s) dropped.

I have been to hell and back, even talked to some angels about it, no one seems to understand what the BB is talking about.

My last act is to ask in this forum. Any grey/ white wizards in the art of BB development who can assist me. I will deeply appreciate

[simon_hain]

welcome to the support forums.

unfortunately i have no clue about lwuit, evaluated it some years ago and decided not to use it.

the error message suggests that the event queue is overflowing. maybe you have blocking code on the event thread, like i/o?

[jeffrey_ese]

The annoying thing is, the same code works just fine on all java phones and non-touch BB Phones. What is special about the touch implementation I wonder

[maadani]

Hi @jeffrey_ese

In most cases, touch events are usually activating the navigationClick and/or navigationMovement methods.

Try putting a break point on these locations and see if your code handles the input parameter correctly.

As simon_hain said, this error happens when an I/O operation takes too long so search for operation that might hold the main event for a while (network connections, heavy animations/calculations, etc').

Hope that helps,

E.

[jeffrey_ese]

Thanks for your reply. I am looking into it. What really amazes me though, is how this same code functions flawlessly on a low-end nokia and samsung phone, and all the issues I have received and customizations I have had to make to were to make it compatible with a high-end blackberry. It really beats logic

[jeffrey_ese]

I can't even trace this thing... It works perfectly on the simulator, but not at all on the device. I am having to do ancient 1977 debugging.... i.e assume a problem, write a fix, compile, upload online and download to test.

Each test cycle is about 30mins.

Sometimes for each install to test, I have to wait for the device to reboot like windows 95 pc with a fragmented disk and low RAM. Before I install and find out, the fix attends to the wrong issue....

patience... patience

[peter_strange]

"It works perfectly on the simulator"

It works perfectly on a touch screen Simulator?  The same one it fails on?

Have you tried debugging on device?

[jeffrey_ese]

Yes it does. Works too well in fact on all simulators, When I debug on the device, it just hangs... no clue or debug info to know what caused the hang. It was when I checked the event logs that I saw the error on which we are discussing

[jeffrey_ese]

Some please talk to me... right now, BlackBerry is officially driving me crazy..... How in the world, would a platform just stop receiving user inputs and not even tell you where the problem started. Hang your phone and require a battery removal to reset. And developers are supposed to churn out apps for such a platform in volumes... this is impossible. I mean, every other phone platform gave a better tools

[maadani]

Let's try to take a step back and get some more info on the problem.

Does the error happen on a specific use case / screen?

What should happen when the user click on the screen (foreground & background)?

Can you give some details about your application? What is its flow? Which resources does it use?

Have you tried using the profiler? It's a great tool and it can tell you which of the functions takes the longest to complete which can hint on a problem (if the function is in the main thread).

Hope that helps,

E.