Entradas de decsoft

Hello,

First of all, honestly I really don't think a WYSIWYG editor can be good here. About DevExpress (I never use DevExpress, even when appear a good package of components), they are very expensive to my economy edunt. Just take a look by yourself.

Hello,

Sorry, can you explain a little more about tin?

Hello,

In fact the "overflow" already exists in controls like Container, Report and HTML Content, because they are useful sometimes. The new are the Focus and Blur events in all Inputs, Select, MultiSelect and Textarea controls. And the interesting "InputsScroll" sample.

Yes, certainly everyday we can learn something more. :)

Hello,

After some tests, the behaviour can't be reproduced with the view itself, even if we set their "height" at start. I am not sure about, because the view is itself a DIV element like a Container control, however, probably it's the way in how the controls are placed in the view. It's not exactly the same if they are placed inside a Container than if they are placed in the view.

Hello,

Did the "view" can overflow too?

Maybe... if we set their height in the same way than the Container. I did not try it however.

Hello,

Glad to know tin! And thanks for your kindly words.

"The Container have their CSS "overflow-x" set to "auto"" where the code you place it?

You can use the "Inline CSS" app's option or an external CSS file or the control inspector, which is what I do this time:

Hello,

Update your AB copy tin. I add the new "InputsScroll" app sample that have a behaviour like you wanted. The point is to use a Container control. Inside that control we can place the Inputs (or other controls) we wanted. The Container have their CSS "overflow-x" set to "auto". The view's Show event is used to set the Container height at the start.

The application behaviour is like you wanted and, furthermore, we no need to be worry about the Inputs position: the system automatically place the right Input visible. So, even when I add the new Focus and Blur events to all the Inputs, Select, MultiSelect and Textarea controls, in fact we no need to use that events here.

Please tell me if you found useful this tin.

P.S. I test the "InputsScroll" sample here in my 4'' Android 4.4.2 and my 4.7'' Android 5.1.1.

Hello,

Yes; we have a Container control in App Builder. I am now try with the Container control. We can put the inputs inside a container and play with the container "overflow". I will inform you about my tests.

Hello,

Yes; in fact, to me the first approach is good enough, but, the second one also looks good.

How do you get it done tin?

No problem. :)

Hello,

Just to add that I try also with the "GoogleMaps" app sample and the things works like expected: the layout is not broken here in my Android 4.4.2 device. The app is scaled when the keyboard appear and then is scaled again when the keyboard is hidden.

1. App started

2. Keyboard is shown

3. Keyboard is hidden

Hello,

The point is that the "android-windowSoftInputMode" appear in the Phonegap documentation (maybe old?) but not in the recent versions of Apache Cordova. Maybe, for some reason, this option is not take in consideration. And about the "ScrollView" it's Apache Cordova who does not uses something like that... except maybe by using some thirdty party plugin.

But I want to get back to the main question of this thread tin. After test the "Validator" app sample, which contains lot of Text Input controls, I found the behaviour you mentioned: the layout is "break" after the keyboard is show/hide. However, what I try is to uncheck the "Allow user zoom" option, which is checked by default:

After doing that, I try again with the "Validator" app sample, and certainly I can view the expected behaviour:

1. The view is scaled when the keyboard appear.

2. We can select any input control to enter data.

3. After the keyboard is hide, the app layout is restored (not breaked).

The problem now is I can see this "Allow user zoom" option unchecked in your app options (above)... but maybe you can verify that. As I say, the behaviour I experiment with the "Validator" sample is good and allow us to enter input data without problems or layout breaks.

Hello,

About the option:

I am investigating, but, if you wanted, you can try it by placing the above option (XML element) into the Cordova's configuration Extra XML option:

Take a look here too for possible "android-windowSoftInputMode" values:

http://developer.android.com/intl/es/guide/topics/manifest/activity-element.html#wsoft

Hello,

One question (I think important), are you using the Fullscreen option tin?

Hello,

This is strange. You are saying the keyboard leave the layout "reduced" after the keyboard is closed? This is what I can't understand, because this is not the behaviour in my tests. In my tests the layout is "scaled" when the keyboard is displayed, and then the layout is "scaled" again, that is, when the keyboard is hide...