Maximum field height?

[Richard Gaskin]

J. Landman Gay wrote:

 > On 4/5/20 1:12 PM, Richard Gaskin via use-livecode wrote:
 >
 >> Once I saw that the scroller works well on the field content I've
 >> been working with, I added a routine to my mobile lib that
 >> automatically removes the vScrollbar from any non-editable field
 >> that has one, and instantiates a matching scroller over it.
 >
 > That's my standard procedure too, unless I'm using a pseudo-scrolling
 > handler that allows pushing up or down on the field on desktop. It's
 > basically a simulation, but for quick access during development it's
 > faster to just use the built-in scrollbar.

Exactly. Reducing the differences between runtime and development is a 
cornerstone of The xTalk Way.

Dropping a field on a card works. If we want it scrollable, we click a 
checkbox.  Once clicked, it works everywhere, adapting to the UI 
conventions of the host platform. Why should that not work on a phone?

A generic solution REALLY SHOULD BE IN THE ENGINE (is that loud enough? 
Good), but in the dismaying absence of that feature completion some ten 
years later, being able to work around it by having a generic solution 
in a library is acceptable.

That is, if it works:

 >> So yes, I'm using the field directly with no enclosing group, but no,
 >> I don't use the desktop scrollbar on mobile; the scroller overlay
 >> does a good job of tracking the user interaction, with the
 >> appropriate endpoint indication and all, and scrolling the field in
 >> response to the scroller's messages has worked well.
 >
 > I just released an app using this method and on iOS the stutter is
 > quite noticeable, as well as on Android devices with slower CPUs.
 > It's okay for short text, sort of (though there's a brief
 > jerk) but for anything longer it fails.

Good to know.  Thanks.

It's a good thing for the more sensitive readers of this list that I 
have a busy Sunday planned, because my ALL CAPS portion above is just a 
small sample of the "When Keeping It Real Goes Wrong" episode I would 
otherwise drop on this list like a truckload of customer advocacy bricks.

Suffice to say politely and succinctly: a decade later, LC for mobile 
remains half-baked compared to what it could be, compared to The xTalk 
Way that rests at the heart of its origins.

There, I said it. Someone had to.

And it's too bad, because on the desktop it absolutely rocks beyond just 
about any other option on the planet.

It doesn't need to be this way.

Software is eating the world, The xTalk Way is supremely productive, and 
LiveCode is the most powerful xTalk ever.

LiveCode should be eating the planet. That it isn't is a function of the 
customer experience. If we don't soberly own that, there is no 
meaningful growth path forward.


 > Up until LC 9 it was possible to set the field to use a scrolling
 > layermode in the property inspector, but that's been removed. You
 > can still set it by script, but it has no effect (and probably never
 > did) and the engine defaults to dynamic layermode instead.

If a scrolling field can't be scrolled on mobile with checkbox ease for 
the developer and well-met expectations for the user, that would be a bug.

Let's not lower the bar. Let's complete the implementation.

Let's deliver excellence, and enjoy excellent growth.

The world is hungry for highly productive software development 
solutions, right now more than ever. Can we feed them?

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com