I want to show a dialog for a while (for instance 2 seconds) when some event happened like when SMS received and after 2 seconds it hide automatically.
How can I do it in codenameone?
The Dialog class has a show() method that accepts a timeout as one of its arguments. If I remember correctly there is also a way to setTimeout on the dialog instance.
Related
I am trying j2me code in which i am putting to thingd a alert message and setCurrentItem()
function..
display.setCurrent(alert);
display.setCurrentItem(textBox)
the problem is that before we can see the alert msg it disappear and because of display.setCurrent(textBox). what should i do to see the alert message correctly and than move to the item which is placed im display.setCurrentItem??
I don't really do any High Level GUI coding (meaning Form stuff), so I'm no expert.
But looking at the docs, I can see a setTimeout(int time) function on the Alert object.
So my guess is that you should display the TextBox first, and then display the Alert afterwards with a timeout.
alert.setTimeout(5000); // 5 seconds
display.setCurrent(textBox);
display.setCurrent(alert);
That should display the alert for 5 seconds, and then when dismissed, the textBox should appear.
Looking at the Display object, I also notice another function called setCurrent(Alert alert, Displayable nextDisplayable) though, which seems to be even better.
Using that method you should be able to just do
Display.setCurrent(alert, textBox);
The docs says the following about that method: "Requests that this Alert be made current, and that nextDisplayable be made current after the Alert is dismissed. This call returns immediately regardless of the Alert's timeout value or whether it is a modal alert. The nextDisplayable must not be an Alert, and it must not be null."
Bookmark and use this page a lot:
http://docs.oracle.com/javame/config/cldc/ref-impl/midp2.0/jsr118/
My application has one base Dialog that opens from the OTB Application.
Then I have 4 Dialogs that opens from button clicks in the base Dialog.
I am trying to decide if I need to use setBlockOnOpen, but I am not 100% what it does exactly.
setBlockOnOpen(true) is supposed to stop processing after the open() method and wait until the Dialog is closed to continue processing.
setBlockOnOpen(false) allows your code to continue processing after the open() method.
I have written an application in LWUIT targeted for a J2ME phone (Sprint DuraXT). The application is for pickup and delivery van drivers. It receives dispatches from a back-end dispatching system that describe pickups and delivers the driver must make. As the drivers, execute the pickups and deliveries, the driver enters status information that is sent back to the dispatching system.
Now, during the processing of a pickup or delivery, the driver may be presented with error dialogs (incorrect field entry), yes/no confirmation dialogs (confirming some action) and information dialogs (indicating some status the driver should be aware of).
In addition, there is a background thread listening for dispatches coming from the back-end server. In the current implementation, this background thread can also create yes/no confirmation dialogs and information dialogs. These dialogs are more like an alert as they have an associated sound, but they are simply dialogs.
As long as these two dialogs do not occur “simultaneously” every thing works as expected. You can dismiss the dialogs and the app proceeds as expected.
However, when you are on a screen and there is a dialog already showing and a second one from the background thread occurs, you sometime wind up with the wrong screen showing and it is “frozen”. E.g. the soft keys have no effect.
My hypothesis is that there is a race condition between the threads that are dismissing the dialogs. It goes like this. The EDT is blocked showing the dialog that arises as part of the form’s logic. The background thread is also blocked showing a dialog. Now when the dialog showing on the EDT is dismissed, the form is restored, but the EDT may go off and display another form (via show()). When the dialog displayed by the background thread is dismissed, the form which was showing when the dialog was initially displayed is sometimes restored. Now, the display shows a different form than the one the EDT might have shown.
It is pretty clear that this problem is caused by the dialogs resulting from the activities of the background thread. So the basic question is: “How to handle the dialogs arising from the background thread?” I have some thoughts but none yield a particularly clean implementation. I am hoping somebody has had to deal with this same problem and has a suggestion.
I have tried synchronizing the dialog construction and display so that only one dialog can get displayed at a time. This certainly improves the UI, but does not fully resolve the problem. The race begins when the first dialog is dismissed. Here are some other ideas,
If a dialog is shown by a thread other than the EDT, call show on the form at the top of the display stack when the dialog is dismissed. This is a bit of a hack, but may be a workaround.
Run dialogs to be shown by the background thread on the EDT. There are several ways to do this, but the question is will it resolve the problem? Will using an EventDispatcher help? I have experimented using an EventDispatcher to fire an ActionEvent containing a subclass of a Dialog as a source. The subclass contains a show() method which invokes the correct form of the Dialog show method. The class holding the EventDispatcher (global to the application) listens for these events. When the event arrives, the show method is invoked. For information dialogs that simply continue execution from wherever they are dismissed, this should work. For yes/no dialogs, you may have to create something like yes/no callbacks to handle the bifurcation in the logic. And what is not obvious is if this will actually serialize the processing of the dialogs on the EDT thread. This seems complicated.
Any ideas?
I actually hit upon the solution after a bit of experimentation. Because the Dialogs are part of a more compilcated action involving yes/no Dialogs and database queries, I found I had to wrap the whole action in a class which implements the Runnable interface. Then I run the action via Display.getInstance().callSeriallyAndWait(runnable).
So others may benefit from this discussion, here is a example of one of these classes with the action embedded in the run method.
private class CancelOrder implements Runnable {
private KWMap order;
public CancelOrder(KWMap order) {
this.order = order;
}
public void run() {
String orderNum = getString(order, OrderTable.ORDER_NUM);
if (legStatusTable.isOrderStarted(orderNum)
&& !orderTable.isOrderComplete(order)) {
String msg = "You received a cancellation message for Order "
+ orderNum
+ " which has been started but is not finished."
+ "\nDo you want to keep it?";
if (app.yesNoDialog(msg, "Yes", "no")) {
sendCancelResponse(order, "Yes", "");
} else {
deleteOrder(orderNum);
sendCancelResponse(order, "No", "");
}
} else {
// order has neither been started nor completed.
deleteOrder(orderNum);
sendCancelResponse(order, "Yes", "");
app.alertDialog("Dispatcher cancelled Order " + orderNum);
}
}
}
The key thing here is that the action contains logic depending on how a user responds to a yes/no Dialog and there are operations on an underlying database and messaging subsystem as well. Except for the Dialogs, nothing in this action blocks the EDT for more than a few 100s of milliseconds, so the application runs very smoothly. The app coorectly handles dislogs stacking on top of each other which was a problem with the simple apporach of letting these actions run on the background (non EDT) thread.
I've set my button to 'Submit'. The XPage is set to stay on the same page if save is successful. How do I create a messagebox to inform user the save is successful?
There are a number of options you can consider. A msgbox is the least desirable.
You could add an information message on top of the form that either fades after a few seconds or on change. The custom control would show when you set a viewScope variable (e.g. viewScope.saveSuccess ) and have a visibility formula for it. It also would register an event listener to hide when a field is altered. You also could consider redirecting to a different page.
This post already asks a similar question to do with how to call a client side script from server side, could be useful.
client message after SSJS routine how?
Here are two examples that I have used as inspiration to create a custom control for error messages and for info messages such as what you are asking for:
http://openntf.org/XSnippets.nsf/snippet.xsp?id=ssjs-form-validation-that-triggers-errormessage-controls
http://lotusnotus.com/lotusnotus_en.nsf/dx/xpages-tip-a-simple-cc-for-prompting-ssjs-messages-to-ui....htm
The easiest way to call csjs after running ssjs is to add code the event handler's onComplete event. The onStart, onComplete, and onError events run client side js before or after your ssjs, but are only executed during a partial page refresh.
The simplest way is to add this line of code (or the CSJS you prefer) in the postSaveDocument event:
view.postScript('alert("Document saved")');
I am coding up a program for automated testing which randomly clicks an open application window using various User32.dll library calls. My current problem is this, if a click would open a dialog, using Process.WaitForInputIdle() does not wait long enough for that dialog to be detected the next trip around the loop, which means several clicks get cued and if those clicks happen to be on something in the dialog I want to avoid (say an exit button) there is no way of telling that in advance. My question is this. Is there a way of waiting for the process or thread to finish all processing and only be waiting in the message loop again?
I hope that made sense.
Cheers
Ross
EDIT
Failing this, would it be somehow possible to set the process / threads of the target program and my program to both use the same processor and adjust the prioritorys of each so that the target program gets preference?
WaitForInputIdle will unfortunately return as soon as the app is in a message loop with no input messages waiting.
If you own the code to the dialog, you could have the dialog call SetEvent in its WM_INITDIALOG to signal your automation that it is ready for testing. Alternatively, you could look at using SetWinEventHook on the process and wait for the dialog to actually be created before sending input events to it.
The way around this it seems is to use the SendMessage API instead of the mouse_event or SendInput API. The reason for this is that SendMessage blocks until it has been processed. Just make sure you always get the handle of the window immediatly under where you want to click (using WindowFromPoint) and convert the mouse coordinates from screen to client coords using ScreenToClient. Pack the coordinates into the lParam parameter by using ((pt.Y << 16) + pt.X). This will block until processed and so any modal dialogs shown will block this call.