Cannot type into text input on jqModal dialog when modal set to true - jqmodal

Having upgraded jqModal from r13 to r22, I find that where my dialogs contain text inputs it is not possible to type into them. Removing modal:true from the settings fixes it, but I don't want my users to be able to dismiss the dialog by clicking on the overlay. Is this behaviour by design, or is it a bug?

This is certainly not by design. I have released a fix (+r23). Please open a github issue if you require further assistance.
Related:
If you're nesting modals, be sure to have a higher z-index value on child modals.
You may override the $.jqm.focusFunc() to provide custom behaviour for events occurring outside the currently active modal.

Related

How to conditionally render an input accessory view?

I am trying to conditionally render an input bar that appears above the keyboard when the user is tying. I do not want to show this input bar unless the user wants to add something. So they tap a button which is supposed to make the component visible and then focus on the input which brings up the keyboard.
This works as expected except when the user first opens the keyboard. Nothing appears. There is an empty view tag as the keyboard comes up but then it disappears and there is nothing. However, once the user starts typing it appears and after that works as expected. I have no idea why it isn’t appearing. If I don’t type anything and dismiss the keyboard you can see it briefly before it goes away as it is supposed to.
I have tried calling the function with async-await and my current syntax. Neither is working and I have been unable to solve this.
Here is a snack that recreates the issue and contains all the relevant code to reproduce the error.
https://snack.expo.io/#dmargulies/inputaccessoryview-problem
Thank you for your help.
First of all InputAccessoryView exists only on IOS.
I changed conditional rendering flow.
Look at: https://snack.expo.io/#djalik/inputaccessoryview-problem
For anyone looking for a cross-platform solution, there is a package:
react-native-keyboard-accessory
Note: I'm not the author, just figured it might help some peeps.

How to force a dialog to front?

I would like to display a modal JDialog OVER all standing dialogs
when it is invoked (say) by a function key.
This way I want to display a status of my application regardless
of the pile of dialogs and pop-up's already 'on the air'.
I tried to have the dialog in question 'owned' by the mainframe
and to (Frame)null without success.
The method 'this.toFront()' just before 'this.setVisible(true)'is also without effect.
What am I doing wrong?
Thanks for reading.
;JOOP!
It appears to be: [code]window.setAlwaysOnTop(true)[/code]
;JOOP!

In IE elements are get hide then after hover on them they get visible

I am working with IE11. After loading my website elements like checkbox, radio button, drop down arrow get automatically hidden then after hover on them they get visible then after click anywhere in page they again get hide. All this element are present and style are applied tested with developer tool but still they was giving problem. Then after check "use software rendering instead of gpu rendering" option from settings->Internet option->Advanced->"use software rendering instead of gpu rendering" everything got ok. Now my website element not getting hide all style applied perfectly. But I doesn't understand why this happen? How this setting fixed issues. Please any idea help!

Tab Order in Visual Studio hates me

Tab Order in Visual Studio does not work for me for some reason.
I am making a VB.NET plugin for a cad program called Rhinocreos 5.
I have everything set perfect, and I don't know what the cause of it is.
I am using .Show() instead of .ShowDialog(), because I need that thread open and I don't feel like doing any thread management (not paid enough lol)
Does anyone have any pointers for this? Has anyone else ran into a tab problem with Rhino5 and .NET?
EDIT**
Seems I have to use a MODELESS Form for a rhino plugin.... So I wont have any tab keys or arrow keys unless I do a hook. But since I need to make the plugin future proof (in case I am no longer working here), I won't be doing that either. But thanks for the answers, comments, and awesome downvotes.
Very difficult to guess what's going on from the information you have provided, but I'd check the following things in the following order:
The disobedient form is open and has focus.
The form has controls in it.
At least some of the controls are enabled, focusable have their TabStop set to true.
There is no low-level keyboard handling in action (PreviewKeyDown, hooks etc).
Finally I'd call ShowDialog() instead of Show(), passing main form as parameter (to make disobedient form a child of main form) and see if that makes a difference.
It was a modeless form inside of Rhino3D as a plugin.
Rhino3D uses all plugins in the main thread. So tab is not an option.
The workaround was to tag all controls with a tag work (I used "tabMe")
Then I store all the controls in a List myTabbyControls.
Each time I press tab, I would cycle through the list.
But thanks for the down votes. It's the running joke of SO.

Dojo dialog nesting

can a dojo dialog bring up another dojo dialog?
dojo 1.3 only supports one modal dialog at a time, so while, yes, one dialog can open another, closing the second destroys the modality of the first.
This happens because dojo.Dialog uses a single global underlay object that provides screen between the dialog and anything else on the page. You can make it work if you're wiling to create your own underlay for each dialog and manage the z-indexes yourself.
I understand this will be rectified in 1.4.
Yes, a dialog can open another dialog, but then you'd have two dialogs displayed -- they aren't modal between each other.
Since this is not the behavior I desire I've worked around this by creating my own handler -- it first checks for an open dialog, and if it finds one, closes it (and places it on a stack) before opening a new dialog. When it closes one it looks at the stack and re-opens dialogs lower on the stack.
Multiple dialogs can be opened prior to Dojo 1.4, but there are problems with accessibility in that case (tabIndex is handled wrong) - so if you need your app to be accessible and support mutliple dialogs., you need to upgrade to Dojo 1.4 when it comes out.
yes you are able to do it in dojo 1.6 and all above versions