I am developing a JavaFX 2.2 application where background threads may trigger an error dialog to show until its close button is pressed.
If other background threads trigger message dialogs that are not as urgent as the error, these dialogs must not be placed on top of the error dialog.
In other words, I want an error dialog that blocks everything else, and that is never hidden by other popups, or by the main window.
I have tried setting modality to APPLICATION_MODAL for the error dialog, and WINDOW_MODAL for the other, lesser dialogs, but lesser dialogs still appear above the error dialog if they are triggered while the error dialog is showing.
I am not in a position where I can use Java 8, so DialogsFx and ControlFx and other libraries are out of the question.
In Swing, I used to use layers a log, like POPUP_LAYER, ALERT_LAYER, ERROR_LAYER, but I can't find anything similar in JavaFx.
Regards,
Fredrik
If your using an additional stage to show your dialogs you can use its method
stage.showAndWait();
which blocks any event till you close the stage again.
Hope that helps.
Related
In my Application, there is a modeless dialog box which has one static control and some customized controls - Edit box, buttons. Actually we are enhancing the functionality of this dialog and added 2 more static controls. The dialog box has CLIP_SIBLINGS and CLIP_CHILDREN styles.
The Problem I am facing is in WinXP, when some other window gets overlapped on this dialog, every other control is getting painted properly except the newly added static controls. But there is no particular difference between the existing static controls and the ones I added.
This is solved with explicitly calling Invalidate method of the static control in dialog's OnPaint() method, but still I didn't get why the existing controls are painted fine.
I tried removing CLIP_CHILDREN style, then it worked fine but there is a lot of flickering.
Please help me understand the same, I have gone through so many threads relating to the same but I didn't find the answer.
I noticed a problem that seems to only occur on Android 4.3. I'm using a AlertDialog and I dismiss and show it in the onCreate function when an orientation change occurs by storing the dialog state in onSaveInstanceState().
On other versions of android (4.0.x, 4.1.x, 4.2.x, 2.3.x), this works perfectly fine. I can rotate the device multiple times and the dialog will never disappear but on Android 4.3, if I rotate the screen enough, the dialog will disappear but instantly reappear if I rotate the screen again. I noticed that everytime the dialog disappears I'd see a GL_INVALID_OPERATION error in Logcat.
I'm wondering if this is a known bug or if there are any work arounds.
After heavy testing, it appears that this is a timing glitch. I'm not too sure of what's going on in the background but I can guess from the behavior that some GL object are not ready when attempting to display the dialog cause the dialogs not to be drawn.
I found a workaround by just declaring a handler in the class and doing a post event to the handler to show the dialog. It seems to give the activity enough time to intialize everything and the problem no longer occurs.
When I'm testing my app on a mouse-driven device, I'm seeing a couple of odd highlight issues that I would like to try and resolve.
The first occurs when I call up the app bar, hover the mouse over a button (at which point the button goes grey) and then press Escape to dismiss the app bar. If I then call up the app bar again, the button has stayed grey, even if the mouse isn't over it, and remains in that state until I move the mouse over it and then away again.
I can't immediately see a property of the button that I can reset to clear that state when the app bar gets dismissed.
The other oddity I'm seeing is that sometimes the first item in the list on the page will get a box drawn around it:
This seems to happen when the app bar is being dismissed. I'm guessing that this is because the item is in a particular state that causes the box to appear but I'm not sure what state or how to clear it. The box does not appear during normal use of my app.
Thanks for any clarification or solutions you can provide.
I found a simple way to workaround this issue. In the code for Clicked/Tapped set Visibility of the button:
CreateNewDatabase.Visibility = Visibility.Collapsed;
CreateNewDatabase.Visibility = Visibility.Visible;
It will reset button state to Normal.
Hope this helps!
So, the issue is that the VisualState for the Button is being set to PointedOver, and then not being unset (because your mouse isn't leaving the bounds of the control and therefore triggering a PointerExited event). What this means is that you'll have to manually set the VisualState of the Button if you want it to change in this manner. You could do it on AppBar's Closed event. Basically, do a recursive check of all Children of the Content property of the AppBar using the VisualTreeHelper. Check to see if the Child is a Button. If it is, set its VisualState using VisualStateManager.GoToState().
I've also figured out what was causing the black box around the button - it is to indicate that the button has Focus.
The rather strange thing is that I'm not really sure why that specific button is getting focus or how a user is supposed to give focus to a button without it just randomly happening so, until I figure that out, I've decided to comment out the Focus state support from the Visual Manager XAML used in the default GridView item style.
Hi I am facing the problem on ICS like dialog is dismissed when we click outside dialog window, due to which I am getting problem like I don't get any confirmation from user.
Please help.
Check this method from the Android Developers site for dialog.
Try using the
dialog.setCanceledOnTouchOutside (boolean cancel)
Pass a boolean value to enable/disable dialog behaviour when touched outside of the dialog window.
Also go through these links:
How do I fire an event when click occurs outside a dialog
How to cancel an Dialog themed like Activity when touched outside the window?
I hope this answers your question.
You may use
dialog.setCancelable(true/false);
OR
dialog.setCanceledOnTouchOutside(true/false);
For the latest vesrions of Android;
It will disable outSideTouching event.
dialog.setCancelable(false)
Dialog CAN NOT cancel when touch out side OR press BACK key
dialog.setCanceledOnTouchOutside(false)
Dialog CAN NOT cancel when touched outside BUT ABLE to canceled when press BACK key
I have an interesting (but frustraring) problem. I have an application which uses the full screen (this is meant to simulate a third-party fullscreen POS application).
My application displays a sequence of modeless dialog boxes on top of the full screen application. It shows one, hides it, then shows the next, hides it etc. After the 3rd show, the Windows taskbar appears about 1 second later. I can't figure out why.
I've stripped my code right back to see if its something I'm doing in my OnNcActivate handler (which I use to draw my skinned window) but I don't think it is as the problem appears to be timing related. I've tried running Spy++ as well as dumping messages in m WindowProc myself and I still can't see anything odd that would give me any clues.
There are some messages with ID 0x36e in my logs but I can't find out what they are supposed to be. I've checked various message ID lists and can't find them. They shouldn't be any message IDs of my own since WM_USER doesn't start until 0x400.
I know I could get around this problem by auto-hiding the taskbar but I can't ask our customers to configure their taskbars to auto-hide to get round my problem.
Any ideas why the taskbar would appear in relation to my modeless dialog boxes?
EDIT: I completely stripped out my self-drawn GUI code and I still have the same problem. I could be wrong but it would seem that when I call ShowWindow( SW_HIDE) first, Windows tries to activate "another Window" (as it says in MSDN). I think in this case its activating the taskbar rather than the POS application. If on the other hand I open my second window before calling ShowWindow( SW_HIDE ) on the second, then it seems to behave itself.
Cheers
Sparky
Following a long discussion I come to the conclusion that DestroyWindow was not the problem. I found in the end that displaying a dialog.. clicking on the POS, then clicking back on the dialog that sometimes the taskbar would appear. I have spent an entire week trying to find reasons for all of this but to no avail. I thought that assigning the POS window as the owner would solve the problem - it didn't. In the end the solution for my problem was to determine if the taskbar is obscured completely before showing my dialog. If it is, I hide the taskbar for the duration which my dialog is displayed (set its placement to SW_HIDE) and then set it to SW_SHOW when I close my dialog. The task bar doesn't pop up and annoy people anymore. Not a fantastic solution for other peoples' applications perhaps, but perfect for our customers.