Maximum field height?
ambassador at fourthworld.com
Sun Apr 5 16:22:24 EDT 2020
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?
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode