[movalys_matt]

Do you know if it is possible to block multiple-click?

IE : when you click once on a button, if you click another time during the treatment of the action called by the first click, the action won't execute another time as you click but will wait for the first action to finish.

What I would like to do would be to block the click during the execution of the click-caused action.

Dunno if it's clear.

Thanks

Matt

[Mark Rejhon]

On most platforms in most programming whenever I only want to run an event once and ignore other events of the same kind, I generally use a static variable to set a flag. (or a global variable or a class member variable, if statics are not available or if I need to use the same variable to block all events while one of them is running). I mainly do C/C++, but it's extremely similiar in format in Java too. May need minor tweaks. The important thing here is static so you remember the last state of the variable between execution of events. But this could easily be a class member, as the class members are persistent (like static) between event calls. Or in the worst case scenario, a global variable can be used instead.

WhateverEventxxx40; xxx41;
xxx123;
   static boolean bEventRunning = FALSE; // Only initialized on first execution

   if xxx40;bEventRunningxxx41;
   xxx123;
      // The event is already running, exit immediately
      return;
   xxx125;
   bEventRunning = TRUE;

   // Do your deed --
   // Put your event code here.

   bEventRunning = FALSE;
xxx125;

[movalys_matt]

Thanx a lot for your answer but...but...but...
it does not work

and why does this thing not work?

I'll try to explain what i found with this little sequence of what happens :

First click --> start of event code -->second click ---> click event put on top of events stack ----->end of event code ---->start of SECOND event code

what i would like to do is to prevent the BB form receiveing external events (click, key or whatever) when code that is linked to an event is beeing runned

[Mark Rejhon]

Ahhh, the click events are being buffered up.

What you want to do is use a timer-value variable. Ignore all click events that occur within 0.5 seconds of the end of the first. You can tweak this down to something like 0.25 seconds, make sure it's at least about 3 or 4 times the minimum interval. This is probably not the only way, but the easiest way (especially if there's no way to clear the event queue).

There's probably a better way, but this would be a simple fix.

WhateverEventxxx40;xxx41;
xxx123;
   static integer lasttick;

   // Replace above line with something appropriate to your platform
   // GetSystemTickCount is a generic name for system milliseconds timer
   // You can use any system timer that has enough precision 
   // You could even change use a timer event driven semaphore instead

   if xxx40;xxx40;lasttick - GetSystemTickCountxxx40;xxx41;xxx41; < 300xxx41;
   xxx123;
      // Less than 300 milliseconds passed since ending of last event.
      return;
   xxx125;

   // **********
   // Do your deed; put your code here
   // **********

   // Finally, record the time of the ending of event
   lasttick = GetSystemTickCountxxx40;xxx41;;
xxx125;

Or, alternatively, if you have an idle loop, you could even clear an ignore flag (say, "ignoreevents" boolean variable) that is set during a call to an event. So that only the first event in a series of queued events, is executed, and future calls to same event are ignored until the event queue is empty (i.e. idle loop runs only after an event queue is empty, and the idle loop clears the ignoreevents flag). This method would be more efficient, but I don't know if there's an idle loop capability in a J2ME application.

Terminology may be slightly different for the J2ME platform, as I am not yet familiar with the limitations of mobile programming.

[movalys_matt]

yes, i had thought about it but my problem is that with that solution, I have to guess (and I insist on this point) what time it will take my BB to execute the code that's inside my listener.

Moreover, it will be impossible to double click.

And we have to remember that the execution time depends on :
-blackberry speed (not so regular)
-if and while and for and ... loops...
-amount of data(it won't take the same time if I have to insert 1 record or 100 records in my database)
-quality of the GPRS network, of the server i'm trying to reach, and so on if my trackwheelclick calls a wireless synchonization function
-so many more parameters...

So, yes, that solution could help, and for that, I thank you, but I think that if you compare the time of development needed to make it work to a simple advice to the end user (something like : "Hey you, *****(replace with wathever you like :P), don't use brute force clicking on our application" )

But indeed, a real solution like idle loop if it works efficiently or something like clearing the event queue would rock

[Mark Rejhon]

Very true to all. Your post brings up excellent points about speed. But I had thought of it, and made a workaround:

yes, i had thought about it but my problem is that with that solution, I have to guess (and I insist on this point) what time it will take my BB to execute the code that's inside my listener.

It doesn't matter -- because in my example I record the timer at the end of your listener. What matters is the time between the end (exiting) of event and the beginning (entering) of the next event.

This should theoretically eliminate 90-95% of the variability you are trying to say; unless I am missing something? But then again, maybe you had an excellent reason why this wouldn't work such as code that is concurrently executed outside your listener (multithreading) that keeps running even when your code exits;

[kirson]

I had the same thought, Mark. I would suspect it will eliminate OVER 95% of the variability.

[Mark Rejhon]

It's definitely not the ideal way to go about things, but I've used similiar techniques to good success when there were no other ways to do it. One of the things that I've done is writing button anti-bounce code, which uses a timer as well.

[eradis]

Should be looking at a multi-threaded solution.

[Mark Rejhon]

eradis, that's another good solution. Basically the button click triggers the code in another thread, and the button click event exits immediately while the other thread continues to process. The other thread sets a flag at the beginning and clears the flag at the end of the processing. The original button click event can check this flag and ignore subsequent clicks if the other thread is still processing.

Another method of this multithreaded way if there's a continuous loop in the other thread monitoring a flag, is that the button click event sets the flag, and the other thread only clears the flag when all the processing is done and that new button clicks are okay.

Some people need to avoid multithreaded programming for certain reasons though, or when it's too difficult (i.e. potentially makes software unstable). In these cases, it's better to err on the side of stability.

[movalys_matt]

I think i m going to try to use the time parameter from trackwheelclick method

it should work...
i'll keep you informed

[movalys_matt]

doooooooooooooooooooooooooooooone

okay boys and girls, here is my solution

int endExec = 0;
long resetDate = 0;
boolean firstExecution = true;

public boolean trackwheelClick(int status, int time) {
if(firstExecution){
resetDate = System.currentTimeMillis() - time;
firstExecution = false;
}
if(time>endExec){
...
//execute an action here
...
endExec= (int)(System.currentTimeMillis() - resetDate);
}
return true;
}

it seems to be working
BUT (because there is always stg to be improved)
it would be more beautiful(with butterflies and little flowers) if I could get the resetDate directly form the device itself.