How can I prevent the showing of the Next or Done buttons of the Android VKB in a Codename One app?
Currently, for my app, they are a mess: the next button of the VKB doesn't focus the next field, but the previous. After tons of trials, I didn't find a way to make them working correctly (but there are fine on iOS and on the Simulator). I also tried to override the Layout.overridesTabIndices(com.codename1.ui.Container) and Layout.getChildrenInTraversalOrder(com.codename1.ui.Container) methods in the Form, but nothing changed on Android.
I supposed two possible causes: the use of a Form inside a Form or, more probably, the fact that I replace all the TextFields and Pickers in the same Form (and other components). Maybe the fact that the inner Form is deeply changed results in a confusion for the Android mapping of the "next" button.
That's why my request: because I didn't find a way to make the "next" button useful, I'm asking how I can avoid that it's been shown.
Thank you
Nesting forms would probably mess with the focus traversal/tab order.
Normally you should be able to override public TabIterator getTabIterator(Component start) to return a blank iterator. I'd suggest doing the same for both the parent and child form to disable the "next" feature.
Related
I want to create a custom Picker component, with the same functionality as the iOS Picker. The problem is that I want a completely different UI, basically a horizontal scrollview with two methods of input:
First one is easy, clicking one item results in that item being selected. The second way of inputting should be by scrolling, where the center one gets selected (like the iOS Picker). That's where I'm stuck.
While planing, I thought about using react-native-snap-carousel, my problem with that is that it needs a fixed itemWidth, which isn't suitable for text as the elements.
I also thought about somehow enabling snapping for my List, but that seems only to be possible with pagingEnabled = true, which isn't suitable for my use case.
What else could I try?
Thank's to anyone who is willing to help!
Does the Validate button in the Codename One Component Inspector Tree do a check of UI?
I've never seen a message, a log, a dialog or anything else clicking on it. What is the way to use it?
Right now it only checks for nested scrollables, the goal is to add additional checks for common pitfalls but this wasn't implemented yet. See: https://www.codenameone.com/blog/validate-owner-badges-imageviewer-picker-range.html
On a given form, we replace one component with another.
The original component is a series of TextFields, and the new form is some informational text and a button. We hide the first one, and show the second one (the UI designer has both Containers within the form).
I tried using scrollRectToVisible with various values but it didn't seem to make any difference with the scrolling.
continueButtonContainer.setHidden(false);
f.forceRevalidate();
Button continueButton =
(Button)StateMachine.GetInstance().findByName("ButtonContinue", f);
f.scrollComponentToVisible(continueButtonContainer);
f.scrollComponentToVisible(continueButton);
I'm expecting the continue button to be near the top of the screen.
If the screen was scrolled before displaying the continue button, the button ends up right at the bottom of the screen (it was below the bottom of the screen before I put in the scrollComponentToVisible line(s).
After the user scrolls the screen, the button goes up to where it needs to be, and stays there.
If the screen is not scrolled, the button appears where it should be.
I know I can probably add some invisible containers underneath the button and force them onto the screen, but I would rather have a slightly more robust solution.
There are a few issues with this. First you are using forceRevalidate which should be used in very rare cases.
Second it seems that you are invoking this on a Form, this is a bit misleading. While it seems that:
f.add(myCmp);
Adds a component to the form it is really a synonym to:
f.getContentPane().add(myCmp);
That's important because you need to invoke the scrollComponentToVisible on the scrollable container which will actually do the work and ideally be the direct parent of said component. I'm assuming it's the content pane in your case but it depends on layout etc.
The last part is letting the layout do its job. If you are invoking this before the form is showing this might not work. Notice that doing it after a call to show is meaningless as the form might take time with transitions. You can use a show listener or override the laidOut callback method to perform things like this.
I'm new to iAd Producer - what I'm really looking for is a replacement for Dashcode, since Apple seems to have abandoned it. But while it looks as though iAd Producer CAN produce iBooks Author widgets, it seems to be missing a few fundamental objects - namely checkboxes and radio buttons.
I'm sure there's a way to hack HTML and perhaps use jQuery to get the job done, but this was a relatively simple, straightforward thing in Dashcode. Am I missing something? With tools like buttons, sliders, and such, I'd think checkboxes and radio buttons would be included.
Anybody know an EASY way to replicate Dashcode functionality in iAdProducer?
Thanks!
I've had the exact same problem for the last week and finally came across a solution. You can "escape" the checkboxes in a way by including an empty onclick property to the checkbox or label that you want to affect. This should override native code that relates to cut-and-paste gestures and make checkboxes unusable. I've had success with this in iBooks Widget Tester.
Funny... we seem to be working on the same issue at the same time. Closest I've got to a solution is to build in iAd Producer using the HTML template. There you can add in the objects that are missing using HTML code while also adding drag and drop objects available in the software.
However, while I can populate my view with checkboxes and get them to be checked in iAd Producer's preview, when I preview on my iPad, I can't check the boxes. Radio buttons remain unresponsive too.
I am trying to build an app using Extjs 4.1. In general: it is a viewport with a tree panel on the west and a center panel that it is actually a tab-holder panel. When a user clicks on a tree node a tab is populating the center view. I had set an attribute in the tree panel that after selecting a node it gets deselected (deselectAll). The reason for this is that the user can open many tabs from different places (e.g. within each tab). But, when I set the above attribute it is producing an error (the “data” is undefined). The data that is undefined is the data related to the tree node. So, the question concerning selection model:
How can I address this problem (a solution may be to select the fist node, but I don’t want it)?
As for the history utility, I need to implement browser back button. Especially I want to disable browser’s refresh button. If user opens let’s say 15 tabs and accidentally click on browser refresh or “F5” he/she will lose everything. I had tried many things but with no luck. I am unable to understand “Ext history util”. So,
Is there any good example out there?
Could anybody guide me on how to do it?
Notice that the application is built respecting the new “MVC” architecture.
Stopping the refresh event is pretty easy - providing that your page has the focus. E.g.:
Ext.getDoc().on('keypress', function(event) {
if (event.getCharCode() == event.F5) {
event.stopEvent();
console.log('you stopped the refresh event');
}
});
If your page doesn't have the focus then there is nothing that can be done -- but most of the time your page loses the focus when a different browser tab is opened so F5 would be refreshing that one instead anyway.
I'm still trying to wrap my wits around the first part of your question, but I thought I would share that.
EDIT
Instead of trying to stop the default browser behavior (something which you can only do on a very limited basis), you should look into state management. ExtJS supports it on many components. Here is the ExtJS example.
Also here is the example of controlling browser history.