naked scrollview

JesseW

Active Member
Licensed User
Longtime User
Erel, could we have a naked scrollview, one without a panel attached, that we could add other views, such as labels and edittext's, directly to? This would simplify at least a few scenarios that are currently hindered by the panel being in the middle.

By the way... really loving B4A!!! I've created my first app for the market, just waiting for my site to be launched to upload it. Mega-thanks!!!
 

susu

Well-Known Member
Licensed User
Longtime User
Count me in :D
 

JesseW

Active Member
Licensed User
Longtime User
You can remove the inner panel by calling ScrollView.Panel.RemoveView (Core v1.1 is required)

True enough, but scrollviews have no AddView method to add another view. Or does it???
 

JesseW

Active Member
Licensed User
Longtime User
I thought that by removing the panel from the scrollview and attaching an edittext directly, I'd be able to manipulate a full screen editor that would react to a keyboard popping up by pushing the bottom of the scrollview/edittext up to the top of the keyboard. Sadly, this hasn't worked yet. The overall height of the scrollview/edittext stays the same, and under certain conditions the keyboard will appear overlapped over the still full screen edittext hiding the bottom portion of it completely, and other times it will push the bottom of the edit text up as it should, but the top of the scrollview/edittext, as well as the app title label, is pushed way up off the top of the screen. In either case the overall height of the scrollview/edittext stays the same and does not compensate for the reduced space of available screen.

A friend turned me on to the xml setting fitsSystemWindows, but it has no corresponding set method to be used from the reflection library.

I'm at a loss. Erel, Andrew, is there anything you can think of? I'd hate to think I'm without an edittext that can't compensate for reduced space when the keyboard pops up. IMHO it'd be horribly unprofessional for me to upload an app to the market with the editing space overlapped by the keyboard, or pushed way up off the top of the screen.

Appreciate your time and trouble...
 

agraham

Expert
Licensed User
Longtime User
I had trouble seeing this until I realised it is relatated to the position of the insertion point in the EditTest. This just seems to be what Android does if the insertion point in the EditText wants to dip below the top of the keyboard. This seems to be the default action as described here Onscreen Input Methods | Android Developers
...one shown here is called pan and scan, and simply involves scrolling the application window around so that the currently focused view is visible. This is the default mode, since it is the safest for existing applications.
 

JesseW

Active Member
Licensed User
Longtime User
...This just seems to be what Android does if the insertion point in the EditText wants to dip below the top of the keyboard...

I don't know... the items on scrollviews on the built-in email app as well as the gmail app do not act this way. Neither does Mintoris basic, txtpad, ted, iedit or notepad. They all act correctly by anchoring the top of the scrollview and/or edittext to the top of the available space, and altering the bottom to react to changes in available screen space made by the keyboard popping up and down. This seems to be the default way android does it. In fact the time spent this morning has turned up not a single app or example if the keyboard overlapping the edit field. They all push the bottom of the edit field up to accommodate the keyboard while leaving the top of it anchored to the top of the available part of the viewable section of the screen.

Could it be the b4a wrapper of the scrollview? Andrew can you show me how to create a new scrollview object and attach it to the activity using your reflection library? It'd seriously take me a hundred years of trial and error. I sure appreciate your involvement :)
 

agraham

Expert
Licensed User
Longtime User
They all act correctly by anchoring the top of the scrollview and/or edittext to the top of the available space, and altering the bottom to react to changes in available screen space made by the keyboard popping up and down. This seems to be the default way android does it.
No. The article definitely states at least twice that pan and scan is the default. Here's another quote from it.
•Use pan and scan mode by default, unless it can reasonably guess that resize mode will work by the existence of lists, scroll views, etc.
An application that behaves differently is either doing something additional as described in that article or rolling its own way. For instance hacking android:windowSoftInputMode ="stateVisible|adjustResize" into the the default manifest as suggested further on in the article does stop the pan and scan but unfortunately you now can't see the text you are entering when the insertion point goes below the keyboard top edge. Someone with more interest in GUI things than I will have to play with this. I actually don't mind the default pan and scan behaviour.
Could it be the b4a wrapper of the scrollview?
No.
 

JesseW

Active Member
Licensed User
Longtime User
I had a chance to read a little of the article you mentioned. I understand the pan and scan mode example to read that a small edittext, as the example illustration where the browser is asking for a url in a small edittext, would be forced up into the viewable area, so the user can see what he/she is typing.

I'm working with one large edit field, that I want to inhabit all of the usable part of the screen, in the form of an edittext, that when the keyboard pops up, should remain anchored at the top and forced up at the bottom, reducing its size accordingly, and it's not. Either the bottom stays and the keyboard overlaps or if it is pushed up, the top is pushed up too, way up off the screen. Either way, the size of the edit field isn't changed to accommodate the reduced size of the usable screen area. I don't see this behavior in other apps that use large edit fields. In other apps, I see the size of the edit field reduced to accommodate the reduced area caused by the keyboard popping up.

Edit: I see you responded while I was typing. I appreciate your help, I really do, I just don't think I'm explaining the behavior where you understand what's happening. I suppose I will give up on it for now. The friend that's helping is the author of Mintoris Basic, and he also can't see why it's acting this way either. He's using java instead of b4a, and uses xml instead of programmatic object creation and placement, and states he does nothing special, but yet his large edit text, both with and without being used on a scrollview, acts correctly. I dunno...
 
Last edited:

JesseW

Active Member
Licensed User
Longtime User
...For instance hacking android:windowSoftInputMode ="stateVisible|adjustResize" into the the default manifest as suggested further on in the article does stop the pan and scan but unfortunately you now can't see the text you are entering when the insertion point goes below the keyboard top edge....

Well, that's kinda my point. All other full screen editor apps I've seen, when the keyboard pops up, resizes and realigns the edit field so the bottom of the edit field is moved up to the top of the keyboard so that the cursor CAN'T go below the top of the keyboard.
 

aldweb

Member
Licensed User
Longtime User
Well, that's kinda my point. All other full screen editor apps I've seen, when the keyboard pops up, resizes and realigns the edit field so the bottom of the edit field is moved up to the top of the keyboard so that the cursor CAN'T go below the top of the keyboard.

Hello. I agree 100% with this point, not only for the edittext view but for all other views as well (like listview...). I am also trapped with this issue in my proof of concept application (playing with the trial version since a few days).
Is clearly and highly missing in the current B4A v1.1 a way to redraw the screens' views according to a keyboard popup event that we should be able to track. We should definitely be able to tell that some views should not be resized (like a button, a one line edittext or label...), some views should be resizable (like a listview, a multiple lines edittext or label...) in the event of such a keyboard popup.

Cheers,
aldweb
 
Last edited:

aldweb

Member
Licensed User
Longtime User
Great, this is highly required and will be an impressive improvement.

Cheers,
aldweb
 

JesseW

Active Member
Licensed User
Longtime User
I will check this issue.

Thank you Erel. Your involvement means a lot :) With the keyboard overlapping the bottom section of the edittext, it was impossible to see the text it was hiding, and difficult to move the cursor into that area. And if the cursor (AGraham called it Insertion Point) was in that area, the top of the edit text would be pushed up off the top of the screen, again not visible to the user. This behavior is highly unprofessional and I would never release an app acting in this manner. A keyboard popup event might allow code the opportunity see the increased/decreased size of available screen real-estate and adjust accordingly.

Thank you aldweb for agreeing.
 

JesseW

Active Member
Licensed User
Longtime User
...Here's another quote from it.
•Use pan and scan mode by default, unless it can reasonably guess that resize mode will work by the existence of lists, scroll views, etc.

Andrew, I re-read your quote above and noticed that it states resize mode (instead of pan and scan I presume) will work by the existance of lists, scrollviews, etc. This entire discussion started by me wanting to put an edittext on a fullscreen scrollview and have it act like other full screen editors. Is there anything you can think of to revert an activity to this mode? Thanks again for your help.

This from http://developer.android.com/resources/articles/on-screen-inputs.html
Most often the preferred screen layout is a resize, where the application's window is resized to be entirely visible. An example is shown here, when composing an e-mail message ... The size of the application window is changed so that none of it is hidden by the IME, allowing full access to both the application and IME. This of course only works for applications that have a resizeable area that can be reduced to make enough space, but the vertical space in this mode is actually no less than what is available in landscape orientation, so very often an application can already accommodate it.

Erel / Andrew... this is what I've been talking about this whole time. Appreciate your help :)
 
Last edited:

JesseW

Active Member
Licensed User
Longtime User
The answer lies here I believe. Unfortunately I don't see a way to change it through a reflection object because there doesn't seem to be a corresponding set method.

This is from http://developer.android.com/guide/topics/manifest/activity-element.html

<activity android:windowSoftInputMode=["stateUnspecified", "stateUnchanged", "stateHidden", "stateAlwaysHidden", "stateVisible", "stateAlwaysVisible", "adjustUnspecified "adjustResize", "adjustPan"] >
 

agraham

Expert
Licensed User
Longtime User
this is what I've been talking about this whole time.
I know what you have been talking about from the beginning. If you look in post #11 above above you will see that I already tried changing the SoftInputMode and it doesn't produce the required result. I suspect it may be because a Basic4Android layout is based on an AbsoluteLayout but I'll leave that to Erel to establish - or otherwise.
 
Top