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...