Re: Front and Back Scripts on Mobile

[Mark Wieder]

On 07/06/2016 12:11 PM, Sannyasin Brahmanathaswami wrote:

Plus I was recently scolded off list for reporting bugs that were actually my 
ignorance.


Whoever did the scolding (you know who you are) did no service to you, 
to the user base in general, and to LiveCode quality. If you think you 
have a bug you should report it. Having users hesitant to report bugs 
does nobody any good. It's up to the bug triage team to decide what's what.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

LOL!  because I'm not the one that codes 4D… if you have been going to the 
annual 4D conference(s) and think you see me there.. that's actually 
Shanmuganathaswami and Siddhanathaswami, not me..

They are the 4D wizards…

From: use-livecode <use-livecode-boun...@lists.runrev.com> on behalf of Mike 
Kerner <mikeker...@roadrunner.com>
Reply-To: How LiveCode <use-livecode@lists.runrev.com>
Date: Wednesday, July 6, 2016 at 9:36 AM
To: How LiveCode <use-livecode@lists.runrev.com>
Subject: Re: Front and Back Scripts on Mobile

BR, why can't I just call you "4D wonk"?

On Wed, Jul 6, 2016 at 3:11 PM, Sannyasin Brahmanathaswami 
<bra...@hindu.org<mailto:bra...@hindu.org>
wrote:

This seems to "elementary" that I could not imagine the team would not see
this before release. So I assumed it was by design. Plus I was recently
scolded off list for reporting bugs that were actually my ignorance.  (even
though in fact 75% of my reports are legit bugs) So now I'm a bit gun shy
about reporting bugs until I flog it to death on this list first. Once it
stops moving (no more replies from anyone)  then I bug report it.

I assume you feel that we should be able add stack files on  mobile… so, I
will report it.

BR

Richard wrote:

Subject: Re: Front and Back Scripts on Mobile

but the button to add stack
> files the standalone builder for mobile is dimmed.

That doesn't seem as much a documentation error as a Standalone Builder
bug.  Have you reported it?
___
use-livecode mailing list
use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode




--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> Richard wrote:
> That doesn't seem as much a documentation error as a Standalone
> Builder bug. Have you reported it?
>
> This seems to "elementary" that I could not imagine the team would
> not see this before release.

There are some regressions that mystify me too.

> So I assumed it was by design.

Sometimes design decisions merit reconsideration (see File -> New Stack).

> Plus I was recently scolded off list for reporting bugs that were
> actually my ignorance.  (even though in fact 75% of my reports are
> legit bugs) So now I'm a bit gun shy about reporting bugs until I
> flog it to death on this list first.

Perhaps it's the tone during the flogging that the team found tiresome.

Yours aren't nearly as bad as some of the stuff I see here and in the 
forums, where it's as though the Internet somehow precludes basic good 
manners, writing with a tone that appears to presume the team is either 
stupid, lazy, or both.  It's exhausting to read such things, and more 
than a bit demotivating.


Courteous results-focused professionalism goes a long way.

I've submitted a few bugs which were later explained as unnecessary, but 
since I try to be respectful when communicating they return the favor.


Good manners are the lubricant of teamwork.

> I assume you feel that we should be able add stack files on  mobile…
> so, I will report it.

I see no reason why it should be prevented.  If there is a reason 
they'll close it with an explanation.  If there's any heat feel free to 
mention that report was my suggestion.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Mike Kerner]

BR, why can't I just call you "4D wonk"?

On Wed, Jul 6, 2016 at 3:11 PM, Sannyasin Brahmanathaswami <bra...@hindu.org
> wrote:

> This seems to "elementary" that I could not imagine the team would not see
> this before release. So I assumed it was by design. Plus I was recently
> scolded off list for reporting bugs that were actually my ignorance.  (even
> though in fact 75% of my reports are legit bugs) So now I'm a bit gun shy
> about reporting bugs until I flog it to death on this list first. Once it
> stops moving (no more replies from anyone)  then I bug report it.
>
> I assume you feel that we should be able add stack files on  mobile… so, I
> will report it.
>
> BR
>
> Richard wrote:
>
> Subject: Re: Front and Back Scripts on Mobile
>
> but the button to add stack
> > files the standalone builder for mobile is dimmed.
>
> That doesn't seem as much a documentation error as a Standalone Builder
> bug.  Have you reported it?
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

This seems to "elementary" that I could not imagine the team would not see this 
before release. So I assumed it was by design. Plus I was recently scolded off 
list for reporting bugs that were actually my ignorance.  (even though in fact 
75% of my reports are legit bugs) So now I'm a bit gun shy about reporting bugs 
until I flog it to death on this list first. Once it stops moving (no more 
replies from anyone)  then I bug report it.

I assume you feel that we should be able add stack files on  mobile… so, I will 
report it.

BR

Richard wrote:

Subject: Re: Front and Back Scripts on Mobile

but the button to add stack
> files the standalone builder for mobile is dimmed.

That doesn't seem as much a documentation error as a Standalone Builder
bug.  Have you reported it?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

Yes…Andre built a robust logging feature into the backscript. I can fire a log 
entry like this in the backscript

on createScroller pName
   logRaw "Go this far!"
  etc.

Also see other thread… with more detail on the issue. I *can* get the scroller 
to work on cd 1 of stack A, but then when we go to cd 1 of Stack B which also 
has a scroller, it will then work there… but not if I go back to cd 1 of stack 
A. So far the only way I can get it to work reliably is to put the same 
handlers into the stack script of each stack. So now I'm want to try a behavior 
instead… but I can't get the external script only stack into memory.  All I can 
say is… at this rate trial and error fumbling I will never get Alzheimer's (ha)

and the log shows this  when run on desktop.

ASIDE: FYI for the short form of my name you can use "Brahma" as in the bull  
-- or the beer brand in Brasil whichever is easiest to remember.



From: use-livecode <use-livecode-boun...@lists.runrev.com> on behalf of Mike 
Kerner <mikeker...@roadrunner.com>
Reply-To: How LiveCode <use-livecode@lists.runrev.com>
Date: Wednesday, July 6, 2016 at 7:54 AM
To: How LiveCode <use-livecode@lists.runrev.com>
Subject: Re: Front and Back Scripts on Mobile

San,
I have only been paying light attention to this thread, so if I missed
this, please ignore.  Have you checked to find out if something else is
silently killing your script cascade before it gets to the backscript?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[J. Landman Gay]

On 7/5/2016 10:21 PM, Sannyasin Brahmanathaswami wrote:

Stack A home.livecode | card 1 | group "portal-links"
  on open card
  createScroller "portal-links"

Stack B surprise-me.livecode t| card 2 | group "surprise-links"


on open card
  createScroller "surprise-links"

things improved somewhat…

It does not matter whether I use this or Ralph's code (I did set the 
scrollingEnabled)
And it does not matter whether if we put this in the back script or duplicate 
it in each stack script (not ideal.. but just to test…)

go stack 1 # from button on Stack 0 -- scroller on stack 1 scrolls
go stack 2 # from button on stack 1 -- scroller on stack 2 scrolls
go stack 1 # from button on stack 2 -- scroller on stack 1 no longer scrolls
go stack 2 # from button on stack 1 - scroller continues to scroll now on stack 
2

ergo the scroller on Card 1 | Stack A  "group "portal-links"  has been deleted.


It's more likely it's just not scrolling. It's best to delete all native 
controls on closecard and recreate them on preOpenCard (not sure about 
widgets, but this was true of controls created by script.) Otherwise 
behavior can be unreliable. I can't remember now if you're doing that or 
not.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> Part of the solution is more examples/amd explanation(s) in the
> dictionary itself. For example, right now I'm struggling with getting
> a mobileCreateScroller to work from a backscript.
>
> I think it may do better using an external lc.livecodescript script
> only as a behavior but the dictionary gives no example of how to
> actually implement that in a portable fashion. There is no clear
> indication of exactly how an external stack is loaded into memory and
> made available on mobile. on infers that it should be part of your
> stack files and they in a preopen stack handler one should probably
> "go stack mybehavior.livecodescript"  but the button to add stack
> files the standalone builder for mobile is dimmed.

That doesn't seem as much a documentation error as a Standalone Builder 
bug.  Have you reported it?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Mike Kerner]

San,
I have only been paying light attention to this thread, so if I missed
this, please ignore.  Have you checked to find out if something else is
silently killing your script cascade before it gets to the backscript?

On Wed, Jul 6, 2016 at 1:46 PM, Sannyasin Brahmanathaswami <bra...@hindu.org
> wrote:

> Part of the solution is more examples/amd explanation(s) in the dictionary
> itself. For example, right now I'm struggling with getting a
> mobileCreateScroller to work from a backscript.
>
> I think it may do better using an external lc.livecodescript script only
> as a behavior but the dictionary gives no example of how to actually
> implement that in a portable fashion. There is no clear indication of
> exactly how an external stack is loaded into memory and made available on
> mobile. on infers that it should be part of your stack files and they in a
> preopen stack handler one should probably "go stack
> mybehavior.livecodescript"  but the button to add stack files the
> standalone builder for mobile is dimmed.
>
> So this kind of thing is very, very costly in terms of time needed to do
> hit and miss testing… 2 days for me now…I think I have built and loaded my
> app nearly 75 times onto my iPhone…
>
> BR
>
> From: use-livecode <use-livecode-boun...@lists.runrev.com> on behalf of
> Erik Beugelaar <ebeugel...@gmail.com>
> Reply-To: How LiveCode <use-livecode@lists.runrev.com>
> Date: Tuesday, July 5, 2016 at 10:57 PM
> To: How LiveCode <use-livecode@lists.runrev.com>
> Subject: RE: Front and Back Scripts on Mobile
>
> On the LiveCode website there are a lot of lessons but they all dealing
> with
> different aspects how to do this or that and I miss a good example of an
> application showing how to structure and setup a LiveCode app from the
> start
> (database CRUD handling, update mechanism for the app etc.).
> In this thread samples about back- and frontscript which you can general
> use
> every time over again. Best ways to do this or that etc.
>
> I am thinking about a Kitchensink app or this available somewhere?
>
> Regards,
> Erik
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

Part of the solution is more examples/amd explanation(s) in the dictionary 
itself. For example, right now I'm struggling with getting a 
mobileCreateScroller to work from a backscript.

I think it may do better using an external lc.livecodescript script only as a 
behavior but the dictionary gives no example of how to actually implement that 
in a portable fashion. There is no clear indication of exactly how an external 
stack is loaded into memory and made available on mobile. on infers that it 
should be part of your stack files and they in a preopen stack handler one 
should probably "go stack mybehavior.livecodescript"  but the button to add 
stack files the standalone builder for mobile is dimmed.

So this kind of thing is very, very costly in terms of time needed to do hit 
and miss testing… 2 days for me now…I think I have built and loaded my app 
nearly 75 times onto my iPhone…

BR

From: use-livecode <use-livecode-boun...@lists.runrev.com> on behalf of Erik 
Beugelaar <ebeugel...@gmail.com>
Reply-To: How LiveCode <use-livecode@lists.runrev.com>
Date: Tuesday, July 5, 2016 at 10:57 PM
To: How LiveCode <use-livecode@lists.runrev.com>
Subject: RE: Front and Back Scripts on Mobile

On the LiveCode website there are a lot of lessons but they all dealing with
different aspects how to do this or that and I miss a good example of an
application showing how to structure and setup a LiveCode app from the start
(database CRUD handling, update mechanism for the app etc.).
In this thread samples about back- and frontscript which you can general use
every time over again. Best ways to do this or that etc.

I am thinking about a Kitchensink app or this available somewhere?

Regards,
Erik
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Front and Back Scripts on Mobile

[Erik Beugelaar]

On the LiveCode website there are a lot of lessons but they all dealing with
different aspects how to do this or that and I miss a good example of an
application showing how to structure and setup a LiveCode app from the start
(database CRUD handling, update mechanism for the app etc.). 
In this thread samples about back- and frontscript which you can general use
every time over again. Best ways to do this or that etc.

I am thinking about a Kitchensink app or this available somewhere?

Regards,
Erik


Sent from solidit

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Ralph DiMola
Sent: woensdag 6 juli 2016 03:30
To: 'How to use LiveCode' <use-livecode@lists.runrev.com>
Subject: RE: Front and Back Scripts on Mobile

Richard Gaskin wrote:
why isn't it in the tin?

Maybe there should be a "MobileNative" property on a field. If set to true
then all that stuff we've talked about would be invoked. Setting the
vscrollbar to true would create the native scroller. When a field is not
locked(for input) then only a limited subset of the field object would be
available for native input. Or the more I think about it 2 properties
"MobileNativeInput" and "MobileNativeOutput" to allow read-only native
fields might be more appropriate. In the beginning all this fuss to make a
mobile scroller got LC mobile off the ground, but it seems to me that it's
time to fold it into the LC field object.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

See other post… the dictionary says

Optional string to use to identify the control. The controlName must be unique 
amongst all existing controls and cannot be an integer.

so I set the name of the group of links on 

Stack A home.livecode | card 1 | group "portal-links"
  on open card
  createScroller "portal-links"

Stack B surprise-me.livecode t| card 2 | group "surprise-links"  


on open card
  createScroller "surprise-links"

things improved somewhat…

It does not matter whether I use this or Ralph's code (I did set the 
scrollingEnabled)
And it does not matter whether if we put this in the back script or duplicate 
it in each stack script (not ideal.. but just to test…)

go stack 1 # from button on Stack 0 -- scroller on stack 1 scrolls
go stack 2 # from button on stack 1 -- scroller on stack 2 scrolls
go stack 1 # from button on stack 2 -- scroller on stack 1 no longer scrolls
go stack 2 # from button on stack 1 - scroller continues to scroll now on stack 
2

ergo the scroller on Card 1 | Stack A  "group "portal-links"  has been deleted.

theoretically on desktop, one would trap "resume stack" in the stack being 
re-activated. but "resume stack" is not amessage that fires on mobile… so when 
switching between stacks on mobile that are, presumably, still open in memory, 
how to fire a script in the stack being re-activated? (assuming this is the 
solution… to the scrolling problem we would delete and re-create the scroller 
on the fly, though this seems overkill…I don't see anything in the dictionary 
that says we cannot have multiple mobile scrollers open and funcational at the 
same time… though perhaps this is mandated but no documented? 


command CreateScroller pName -- scrolling regions,groups, fields
if not isMobile() then exit CreateScroller
deleteMobileControl pName -- delete any existing
# it also doesn't help to comment out the above line…
put (the rect of control pName) into tRect
mobileControlCreate "scroller", pName
mobileControlSet pName, "rect", tRect
put ("0,0," & (the formattedwidth of control pName) & "," & the formattedheight 
of control pName) into tRect
mobileControlSet pName, "contentRect" , tRect
mobileControlSet pName, "hScroll" , 0
mobileControlSet pName, "vScroll" , 0
mobileControlSet pName, "hIndicator" , false
mobileControlSet sName , "scrollingEnabled" , true
mobileControlSet pName, "visible", true
end CreateScroller
on scrollerDidScroll hScrolled, vScrolled
put mobileControlTarget() into tControlID
set the vscroll of control tControlID to vscrolled
pass scrollerDidScroll
end scrollerDidScroll



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

Thanks for all the input… meanwhile more sleuthing here… has revealed the 
problem (not the solution, yet…)

Note the architecture… where I think the problem lies

loader.livecode # inserts backscript with the create and delete mobile scroller 
pName where pName is the object, in this case, a group "portal-links" on card 1 
of

Stack A -- home.livecode… # card 1 and the open card handler fires:

createScroller "portal-links"


Stack B - "Surprise-Me"  # card one of this stack uses the same model/objects 
as card 1 of the home stack: ergo another group "portal-links" but with 
different links… but group had the same name in Stack A as in Stack B

OK so… when I load the app on the phone… the loader stack opens home.livecode 
and this runs


command CreateScroller pName -- scrolling regions,groups, fields

if not isMobile() then exit CreateScroller

deleteMobileControl pName -- delete any existing

put (the rect of control pName) into tRect
etc…

So far so good. I can scroll the portal links group on Stack A… ha. me thinks 
all is well… UNTIL I click the button on the portal links that opens the second 
Stack  B "Surprise-me"  which also issue another command in the card script  
(note that I am not closing stack home… perhaps I should)

createScroller "portal-links"

it fails… to scroll… and when I go back to stack A "home" the portal-links 
group also fails to scroll.

ergo:

deleteMobileControl pName  has effectively wiped out the scroller 
"portal-links" in Stack A while at the same time failing to create a new 
scroller  "portal-links  on card 1 of Stack B

Now neither the portal-links group on Stack A or B will scroll.

So I'm off not to study all the posts you all made… this is interesting and 
important…because if we intend to use a template model for instantiating common 
elements across stack… we need some how for the backscript to know what object 
is *really* the target.  (obviously)

tks!

BR


From: use-livecode <use-livecode-boun...@lists.runrev.com> on behalf of Richard 
Gaskin <ambassa...@fourthworld.com>
Reply-To: How LiveCode <use-livecode@lists.runrev.com>
Date: Tuesday, July 5, 2016 at 1:27 PM
To: How LiveCode <use-livecode@lists.runrev.com>
Subject: Re: Front and Back Scripts on Mobile


The downside is I have no idea why Bramanathaswami's code isn't working.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Front and Back Scripts on Mobile

[Ralph DiMola]

Richard Gaskin wrote:
why isn't it in the tin?

Maybe there should be a "MobileNative" property on a field. If set to true
then all that stuff we've talked about would be invoked. Setting the
vscrollbar to true would create the native scroller. When a field is not
locked(for input) then only a limited subset of the field object would be
available for native input. Or the more I think about it 2 properties
"MobileNativeInput" and "MobileNativeOutput" to allow read-only native
fields might be more appropriate. In the beginning all this fuss to make a
mobile scroller got LC mobile off the ground, but it seems to me that it's
time to fold it into the LC field object.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

Ralph DiMola wrote:

> In the beginning all this fuss to make a mobile scroller got LC
> mobile off the ground, but it seems to me that it's time to fold
> it into the LC field object.

The field part of it seems finally underway - that was the last of the 
stretch goals for the latest crowd funding, at $65,205 pledged of 
$55,000 goal.



Or $15,016 of $15,000, depending on which page you happened to have 
stumbled across (seems kinda confusing to me, but at least both exceeded 
their goals):



Just a shame to see it outstanding so long given that with just a few 
hours' work all of us had a very xTalk workflow in place on our own - 
everyone except newcomers not yet committed to the platform. :(  Oh 
well, better late than never.


One thing I'm not clear on about the new mobile-savvy field:  will it 
provide styled text on mobile?


I see so few mobile apps that support styled editable text that I'm not 
even sure if that's provided by the OS APIs or those devs rolled their 
own text engine.  But if the former it would be super-cool to have 
options for styled text in some of our apps.


Fields aside, there are still other areas where perhaps the community 
might pull together a best-of library for mobile support.


For example, the pinch-to-zoom Lesson doesn't really work well, but 
there's a stack in the forums that's much better.  And things like 
long-press, though not hard to script, would be welcome for newcomers 
getting started.  And factoring mobile-specific language elements so 
they don't throw errors when working on the desktop, etc.


And then there's testing.  Lots that can be done there.  I have error 
handlers in my test builds that might be handy, and I very rarely make 
test builds of the app per se at all - I made one app with all features 
enabled, and it downloads a menu stack from my server in which each 
button downloads an app I'm working on.  In the IDE I have a one-button 
plugin that SCPs the stack file I'm working on to my server, and before 
I can pick up my phone to launch my launcher app it's uploaded and 
ready, just a click away (didn't take more than a few minutes in an 
emulator to realize that just won't work out, way to slow, makes me 
wonder how other app devs deal with working in toolkits that don't make 
streaming apps a one-liner).


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Front and Back Scripts on Mobile

[Ralph DiMola]

Richard Gaskin wrote:
>why isn't it in the tin?

Maybe there should be a "MobileNative" property on a field. If set to true
then all that stuff we've talked about would be invoked. Setting the
vscrollbar to true would create the native scroller. When a field is not
locked(for input) then only a limited subset of the field object would be
available for native input. Or the more I think about it 2 properties
"MobileNativeInput" and "MobileNativeOutput" to allow read-only native
fields might be more appropriate. In the beginning all this fuss to make a
mobile scroller got LC mobile off the ground, but it seems to me that it's
time to fold it into the LC field object.


Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

Ralph DiMola wrote:

Thanks J! Yes exactly. I do all my coding around the LC field. When the user
enters data in the native field I then move it to the LC field and work on
it there. This allows IDE testing. Then when you start up the app set the
visible of the LC field to true if in IDE (JLG's dev()) and to false when
not in the IDE. In my case non-IDE is always mobile. You can layout the LC
fields in the IDE and then set the rect of the native field to the rect of
the now invisible LC field.


Aside from the ID pairing that's pretty much what I do - and Ken, and 
Dan, and most others I've talked to when I started playing with mobile, 
which makes me wonder:  if everyone's writing the same library over and 
over to get an xTalk-like workflow for mobile in LC, why isn't it in the 
tin?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Front and Back Scripts on Mobile

[Ralph DiMola]

Thanks J! Yes exactly. I do all my coding around the LC field. When the user
enters data in the native field I then move it to the LC field and work on
it there. This allows IDE testing. Then when you start up the app set the
visible of the LC field to true if in IDE (JLG's dev()) and to false when
not in the IDE. In my case non-IDE is always mobile. You can layout the LC
fields in the IDE and then set the rect of the native field to the rect of
the now invisible LC field.

Just a note:

I created a library alias's for all the mobile specific commands I have used
so far. For example if I need a lat/lon location in the IDE or mobile I just
call My alias:

Function SensorReading
Local GPS
if dev() then
  put 53.338960434184 into GPS["latitude"]
  put -43.6840746841539 into GPS["longitude"]
   else
  put mobileSensorReading("location", true) into GPS
end if
return GPS["Latitude"] , GPS["Longitude"]
end SensorReading

This has been mentioned before but I think all mobile specific commands
should act this way in the IDE.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Tuesday, July 05, 2016 7:15 PM
To: How to use LiveCode
Subject: Re: Front and Back Scripts on Mobile

If you assign a name to the native control, mobileControlTarget() returns it
instead of the number. It's a handy way to match up native controls to their
LC counterparts without keeping a reference list.


Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On July 5, 2016 6:03:49 PM Richard Gaskin <ambassa...@fourthworld.com>
wrote:

> Ralph DiMola wrote:
>
>  > This is what works for me
> ...
>  > on scrollerDidScroll hScrolled, vScrolled
>  >local ControlID
>  >--answer "Here!"
>  >try
>  >   put mobileControlTarget() into ControlID
>  >   set the vscroll of control ControlID of stack "xxx" to vscrolled
>  >   set the hscroll of control ControlID of stack "xxx" to hscrolled
>  >end try
>  >   pass scrollerDidScroll
>  > end scrollerDidScroll
>
> Now I'm confused.  If mobileControlTarget() returns the ID of the 
> native scroller, how does that affect the scroll of a LiveCode object 
> in the subsequent lines?
>
> Do we have control over mobile control IDs in a way that would allow 
> them to match LC object names or IDs?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

J. Landman Gay wrote:

> If you assign a name to the native control, mobileControlTarget()
> returns it instead of the number.

Ah, nice.  Must have missed that in the docs. Thanks.  After all these 
years whenever I come across something called "ID" my instinctive 
response is to treat it as a black box integer, to be passed around but 
not messed with.


The upside is this will take two lines out of my library. :)

The downside is I have no idea why Bramanathaswami's code isn't working.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[J. Landman Gay]

If you assign a name to the native control, mobileControlTarget() returns 
it instead of the number. It's a handy way to match up native controls to 
their LC counterparts without keeping a reference list.



Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On July 5, 2016 6:03:49 PM Richard Gaskin  wrote:


Ralph DiMola wrote:

 > This is what works for me
...
 > on scrollerDidScroll hScrolled, vScrolled
 >local ControlID
 >--answer "Here!"
 >try
 >   put mobileControlTarget() into ControlID
 >   set the vscroll of control ControlID of stack "xxx" to vscrolled
 >   set the hscroll of control ControlID of stack "xxx" to hscrolled
 >end try
 >   pass scrollerDidScroll
 > end scrollerDidScroll

Now I'm confused.  If mobileControlTarget() returns the ID of the native
scroller, how does that affect the scroll of a LiveCode object in the
subsequent lines?

Do we have control over mobile control IDs in a way that would allow
them to match LC object names or IDs?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  
  ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

Ralph DiMola wrote:

> This is what works for me
...
> on scrollerDidScroll hScrolled, vScrolled
>local ControlID
>--answer "Here!"
>try
>   put mobileControlTarget() into ControlID
>   set the vscroll of control ControlID of stack "xxx" to vscrolled
>   set the hscroll of control ControlID of stack "xxx" to hscrolled
>end try
>   pass scrollerDidScroll
> end scrollerDidScroll

Now I'm confused.  If mobileControlTarget() returns the ID of the native 
scroller, how does that affect the scroll of a LiveCode object in the 
subsequent lines?


Do we have control over mobile control IDs in a way that would allow 
them to match LC object names or IDs?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

RE: Front and Back Scripts on Mobile

[Ralph DiMola]

This is what works for me. Note the commented out answer dialog of the 
scroller. Uncomment it so you know the message path is correct. I think you are 
missing==> [mobileControlSet sName , "scrollingEnabled" , true]


command CreateScroll sName
   local crect
   
   if dev () then exit CreateScroll
   put (the rect of control sName) onto crect
   
   mobileControlCreate "scroller", sName
   mobileControlSet sName , "rect", crect
   mobileControlSet sName , "visible",  false   
end CreateScroll

command ActivateScroll sName , Xscroll , Yscroll
   Local crect , sRect
   
   if dev () then exit ActivateScroll
   put  ("0,0," & (the formattedwidth of control sName) & "," & the 
formattedheight of control sName + 20 ) into sRect
   mobileControlSet sName , "contentRect" ,  sRect
   mobileControlSet sName , "vIndicator" , true
   mobileControlSet sName , "scrollingEnabled" , true
   mobileControlSet sName , "visible", true
   if Xscroll is not empty and Xscroll >= 0 then
  mobileControlSet sName , "hScroll" , round(Xscroll)
   end if
   if Yscroll is not empty and Yscroll >= 0 then
  --answer sName , Xscroll , Yscroll
  mobileControlSet sName , "vScroll" , round(Yscroll)
   end if
   
end ActivateScroll

on scrollerDidScroll hScrolled, vScrolled
   local ControlID
   --answer "Here!"
   try
  put mobileControlTarget() into ControlID
  set the vscroll of control ControlID of stack "xxx" to vscrolled
  set the hscroll of control ControlID of stack "xxx" to hscrolled
   end try
   pass scrollerDidScroll
end scrollerDidScroll

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Sannyasin Brahmanathaswami
Sent: Tuesday, July 05, 2016 6:05 PM
To: How to use LiveCode
Subject: Re: Front and Back Scripts on Mobile

Hmmm, today it's not working… not sure how to debug… but buildomh on stand 
alone with this in the backscript


command CreateScroller pName -- scrolling regions,groups, fields

if not isMobile() then exit CreateScroller

deleteMobileControl pName -- delete any existing

put (the rect of control pName) into tRect

mobileControlCreate "scroller", pName

mobileControlSet pName, "rect", tRect

put ("0,0," & (the formattedwidth of control pName) & "," & the formattedheight 
of control pName) into tRect

mobileControlSet pName, "contentRect" , tRect

mobileControlSet pName, "hScroll" , 0

mobileControlSet pName, "vScroll" , 0

mobileControlSet pName, "hIndicator" , false

mobileControlSet pName, "visible", true

end CreateScroller

on scrollerDidScroll hScrolled, vScrolled

put mobileControlTarget() into tControlID

set the vscroll of control tControlID to vscrolled

pass scrollerDidScroll

end scrollerDidScroll

is failing… the control will not scroll


From: use-livecode <use-livecode-boun...@lists.runrev.com> on behalf of Richard 
Gaskin <ambassa...@fourthworld.com>
Reply-To: How LiveCode <use-livecode@lists.runrev.com>
Date: Saturday, July 2, 2016 at 8:47 AM
To: How LiveCode <use-livecode@lists.runrev.com>
Subject: Re: Front and Back Scripts on Mobile

I believe a more accurate description is that the scrollerDidScroll message is 
sent to the *script* that created the scroller, which many not necessarily be a 
stack.

In my case it's a backscript, and it works well.

It seemed painfully tedious to even think about typing scroller instantiation 
code for every controls that needs it, so I don't.
Instead, a backscript scans controls during preOpenCard and anything that needs 
a scroller gets one instantiated for it (along the way it also turns off 
scrollbars, since of course those are only useful on desktop).


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> Hmmm, today it's not working… not sure how to debug…
...
> on scrollerDidScroll hScrolled, vScrolled
>
> put mobileControlTarget() into tControlID
>
> set the vscroll of control tControlID to vscrolled
>
> pass scrollerDidScroll
>
> end scrollerDidScroll
>
> is failing… the control will not scroll

tControlID contains the ID of the mobile control, and what you want is 
the LiveCode object.


In my backscript I maintain a script-local var for that, an array where 
the key is the mobile control ID and the value is the LC object long ID.


I add new elements to it in the routine that instantiates mobile 
controls, and delete them in the closeCard handler that cleans up mobile 
controls.



PS: What email client do you use?  When pasting scripts it adds 
double-spaces between lines and removes leading tabs.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

Hmmm, today it's not working… not sure how to debug… but buildomh on stand 
alone with this in the backscript


command CreateScroller pName -- scrolling regions,groups, fields

if not isMobile() then exit CreateScroller

deleteMobileControl pName -- delete any existing

put (the rect of control pName) into tRect

mobileControlCreate "scroller", pName

mobileControlSet pName, "rect", tRect

put ("0,0," & (the formattedwidth of control pName) & "," & the formattedheight 
of control pName) into tRect

mobileControlSet pName, "contentRect" , tRect

mobileControlSet pName, "hScroll" , 0

mobileControlSet pName, "vScroll" , 0

mobileControlSet pName, "hIndicator" , false

mobileControlSet pName, "visible", true

end CreateScroller

on scrollerDidScroll hScrolled, vScrolled

put mobileControlTarget() into tControlID

set the vscroll of control tControlID to vscrolled

pass scrollerDidScroll

end scrollerDidScroll

is failing… the control will not scroll


From: use-livecode <use-livecode-boun...@lists.runrev.com> on behalf of Richard 
Gaskin <ambassa...@fourthworld.com>
Reply-To: How LiveCode <use-livecode@lists.runrev.com>
Date: Saturday, July 2, 2016 at 8:47 AM
To: How LiveCode <use-livecode@lists.runrev.com>
Subject: Re: Front and Back Scripts on Mobile

I believe a more accurate description is that the scrollerDidScroll
message is sent to the *script* that created the scroller, which many
not necessarily be a stack.

In my case it's a backscript, and it works well.

It seemed painfully tedious to even think about typing scroller
instantiation code for every controls that needs it, so I don't.
Instead, a backscript scans controls during preOpenCard and anything
that needs a scroller gets one instantiated for it (along the way it
also turns off scrollbars, since of course those are only useful on
desktop).


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[J. Landman Gay]

On 7/4/2016 11:42 AM, Richard Gaskin wrote:

J. Landman Gay wrote:


On July 4, 2016 9:34:52 AM Richard Gaskin wrote:


On the desktop, a scrollable object is distinguished by having
scrollbars.

On mobile, of course, we don't want the scrollbars shown since that's
not how mobile scrolling interaction works there.  But development
occurs on the desktop, so having scrollbars lets me work with the
objects in a way that makes sense in that environment, AND it
provides a flag to let my backscript know which objects will need a
scroller interaction overlay when run on mobile devices.


If the backscript removes the scrollbar when creating a native
scroller, how do you test when the user returns to the same card?
The desktop scrollbar will now be gone.


Yep, encountered that first time I ran it on my phone. :)

Since then the routines that instantiate naive mobile controls set a
custom property in each LC control they relate to.



Figured it had to be something like that. Thanks.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

J. Landman Gay wrote:

> On July 4, 2016 9:34:52 AM Richard Gaskin wrote:
>
>> On the desktop, a scrollable object is distinguished by having
>> scrollbars.
>>
>> On mobile, of course, we don't want the scrollbars shown since that's
>> not how mobile scrolling interaction works there.  But development
>> occurs on the desktop, so having scrollbars lets me work with the
>> objects in a way that makes sense in that environment, AND it
>> provides a flag to let my backscript know which objects will need a
>> scroller interaction overlay when run on mobile devices.
>
> If the backscript removes the scrollbar when creating a native
> scroller, how do you test when the user returns to the same card?
> The desktop scrollbar will now be gone.

Yep, encountered that first time I ran it on my phone. :)

Since then the routines that instantiate naive mobile controls set a 
custom property in each LC control they relate to.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[J. Landman Gay]

On July 4, 2016 9:34:52 AM Richard Gaskin  wrote:


On the desktop, a scrollable object is distinguished by having scrollbars.

On mobile, of course, we don't want the scrollbars shown since that's
not how mobile scrolling interaction works there.  But development
occurs on the desktop, so having scrollbars lets me work with the
objects in a way that makes sense in that environment, AND it provides a
flag to let my backscript know which objects will need a scroller
interaction overlay when run on mobile devices.


If the backscript removes the scrollbar when creating a native scroller, 
how do you test when the user returns to the same card? The desktop 
scrollbar will now be gone.



Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> @Richard:
>
> Thanks… confirmed… today it is working, yesterday it was not… go
> figure.  create scroller and scrollerdidscroll now in our backscript.
> awesome!

Once I got the hang of it I've been pretty pleased with LC's scroller 
handling.  And fortunately it seems the Dict entry does a fair job of 
describing where the message goes:


  The scrollerDidScroll message is sent to the object containing
  the script that created the scroller control.


> "Instead, a backscript scans controls during preOpenCard and anything
> that needs a scroller gets one instantiated for it (along the way it
> also turns off scrollbars, since of course those are only useful on
> desktop)."
>
> how does your scan "know" that a scroller is needed or not?

On the desktop, a scrollable object is distinguished by having scrollbars.

On mobile, of course, we don't want the scrollbars shown since that's 
not how mobile scrolling interaction works there.  But development 
occurs on the desktop, so having scrollbars lets me work with the 
objects in a way that makes sense in that environment, AND it provides a 
flag to let my backscript know which objects will need a scroller 
interaction overlay when run on mobile devices.


My backscript walks through all fields and groups on preOpenCard when 
running on a mobile OS.  When it finds an unlocked field it instantiates 
a mobile-native editable field, and when it finds a locked field it 
checks if it has scrollbars, and if so instantiates a scroller overlay. 
 Similarly, when it find a group with scrollbars it also instantiates a 
scroller overlay.



> And since I would prefer not to have scrollbars even on desktop…
> I am putting this in to the [field | group] (see below)

If that's working for you then who am I to suggest otherwise?  But for 
my own projects I try to meet user expectations of how interactions 
work, and the LC team has done a good job of providing nice scrolling 
behaviors on desktop and mobile.


The scrollBars in LC continue to impress me with the fluidity of their 
messaging, and on mobile the OS-native overlay is really the only way to 
deliver an experience that meets user expectations, smoothly responding 
to touch-and-drag operations and nicely supporting whatever 
end-of-scroll behavior the OS provides (the momentary translucent flash 
on Android or Apple's patented bounce-back on iOS*).


One of the great things about LC is that it lets us craft nearly any UI 
we want.  But when it comes to the basics with things like scrolling, 
I'm happy to adhere to OS conventions, with extra bonus points that LC 
generally makes that the easiest thing to do.


As for generalizing your script, probably the simplest way would be to 
move the script to a button or stack and assign it to fields that use it 
as a behavior.  With that one move it should continue to work for all 
fields that need it without modification.



> local sMouseLoc, sStartLoc,
>
> on mouseDown
> put the mouseloc into sMouseLoc
> put sMouseLoc into sStartLoc
> if not isMobile() then setScroll
> end if
> end mouseDown
>
> on setScroll
> if the mouse is down then
> lock screen
> if item 2 of sMouseLoc > the mouseV then
> set the vscroll of me to the vscroll of me - (the mouseV - item 2 of 
sMouseLoc)

> else
> set the vscroll of me to the vscroll of me + (item 2 of sMouseLoc - 
the mouseV)

> end if
> put the mouseloc into sMouseLoc
> send "setScroll" to me in 20 millisec
> unlock screen
> else
> put empty into sMouseLoc
> end if
> end setScroll


* Note for devs making custom UIs:  be very careful when using 
bounce-back as an end-of-scroll indicator.  On iOS you're probably fine, 
but in a few jurisdictions Apple's design patent on that has been 
upheld.  I'm obliged to note that I'm not an attorney; if you want to 
implement custom bounce-back it may be prudent to consult with an 
attorney licensed to practice in your area.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

@Richard:

Thanks… confirmed… today it is working, yesterday it was not… go figure.  
create scroller and scrollerdidscroll now in our backscript. awesome!

"Instead, a backscript scans controls during preOpenCard and anything
that needs a scroller gets one instantiated for it (along the way it
also turns off scrollbars, since of course those are only useful on
desktop)."

how does your scan "know" that a scroller is needed or not?

And since I would prefer not to have scrollbars even on desktop… I am putting 
this in to the [field | group] (see below)

I need to find a way to move this also to the back script so that it can work 
everywhere.. I guess "target" is my friend here. or perhaps this is a case for 
a behavior, but I'm unable to work out yet how to make this generic because 
"the target" returns the object under the mouse and not the name of the group 
that the object is part of.


local sMouseLoc, sStartLoc,

on mouseDown

put the mouseloc into sMouseLoc

put sMouseLoc into sStartLoc

if not isMobile() then setScroll

end if

end mouseDown

on setScroll

if the mouse is down then

lock screen

if item 2 of sMouseLoc > the mouseV then

set the vscroll of me to the vscroll of me - (the mouseV - item 2 of sMouseLoc)

else

set the vscroll of me to the vscroll of me + (item 2 of sMouseLoc - the mouseV)

end if

put the mouseloc into sMouseLoc

send "setScroll" to me in 20 millisec

unlock screen

else

put empty into sMouseLoc

end if

end setScroll



Now… if we can get *this* working from the backscript also for any field/group 
that needs to scroll, that will be even more awesome.



From: use-livecode <use-livecode-boun...@lists.runrev.com> on behalf of Richard 
Gaskin <ambassa...@fourthworld.com>
Reply-To: How LiveCode <use-livecode@lists.runrev.com>
Date: Saturday, July 2, 2016 at 8:47 AM
To: How LiveCode <use-livecode@lists.runrev.com>
Subject: Re: Front and Back Scripts on Mobile

I believe a more accurate description is that the scrollerDidScroll
message is sent to the *script* that created the scroller, which many
not necessarily be a stack.

In my case it's a backscript, and it works well.

It seemed painfully tedious to even think about typing scroller
instantiation code for every controls that needs it, so I don't.
Instead, a backscript scans controls during preOpenCard and anything
that needs a scroller gets one instantiated for it (along the way it
also turns off scrollbars, since of course those are only useful on
desktop).
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

> Ralph wrote:
>> I had this problem way back.  Mark noted that that the scroller
>> messages are sent to the stack that created the scroller.
>
> Does it makes sense to file this as an enhancement request?

I believe a more accurate description is that the scrollerDidScroll 
message is sent to the *script* that created the scroller, which many 
not necessarily be a stack.


In my case it's a backscript, and it works well.

It seemed painfully tedious to even think about typing scroller 
instantiation code for every controls that needs it, so I don't. 
Instead, a backscript scans controls during preOpenCard and anything 
that needs a scroller gets one instantiated for it (along the way it 
also turns off scrollbars, since of course those are only useful on 
desktop).


Because the backscript created the mobile scroller, it's also the 
recipient of the scrollerDidScroll message, where that handler obtains 
the mobileControlTarget to know which physical object to scroll, which 
it then does.


All that takes place in a backscript, so the thing being scrolled needs 
no code at all.


In this respect it seems a very xTalk way of working:

When my LC objects have scrollbars, the user can scroll them.  This 
happens automatically on desktop (via the engine) and mobile (via my 
backscript) alike.  I never need to think about it.  Whether it's 
running on desktop in the IDE or on my mobile device I get identical 
behavior.


Just as LiveCode minimizes differences between desktop platforms, for 
many basic things a little time spent generalizing mobileControlWhatever 
handlers into a backscript can also minimize differences between desktop 
and mobile.


Moving as much mobile-specific code as practical into a factored 
backscript like this has helped me regain the value of choosing an 
xTalk, by minimizing the differences between development and runtime. 
LiveCode is, after all, truly live code.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

Ralph wrote:
I had this problem way back.  Mark noted that that the scroller messages are 
sent to the stack that created the scroller.


Does it makes sense to file this as an enhancement request?

All modern CMV systems  provide for a controller to push  a single model across 
many views. And with most JS frameworks and even in old html "includes" the 
assumption is I can have a single script/code chunk and call this from anywhere 
and it works.  This has also been the assumed behavior of front and back 
scripts for xTalk  "forever"


So, having X number of mobile functions that cannot be placed in a front/back 
script and then triggered from any open stack (not just substacks of a main 
stack) on mobile seems somehow broken to me.  Am I missing something?

BR





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Ralph DiMola]

I had this problem way back.  Mark noted that that the scroller messages are 
sent to the stack that created the scroller.  


Ralph DiMola
IT Director
Evergreen Information Services



 Original message From: Sannyasin 
Brahmanathaswami <bra...@hindu.org> Date:07/02/2016  00:42  
(GMT-05:00) To: How to use LiveCode <use-livecode@lists.runrev.com> 
Subject: Re: Front and Back Scripts on Mobile 


We are looking to use some back scripts on mobile.

If I add this to a backscript

command testMessagePath pMessage
  answer pMessage with "OK"
end testMessagePath


Add this to either a back OR front script.

then add a button to the top of any card in the stack

testMessagePath "Got it"

save and reload the stack… it works on desktop, but not on mobile

OTOH some other commands in the back script *are* firing… because we have some 
set up functions that are not failing.

Are there caveats for using front and back scripts on mobile that we need 
understand?

BR


To add more failure points

this works if we put everything in the stack script of the stack that has the 
scrolling group. but if we move the "createScroller" and isMobile and 
scrollerDidScroll commands to the back or front script… they fail.

??


on opencard

set the vScroll of grp "portal-links" to 0 -- ensures correct initial alignment

createScroller "portal-links" -- replaces any existing one

end opencard



command CreateScroller pName -- scrolling fields

if not isMobile() then exit CreateScroller

deleteMobileControl pName -- delete any existing

put (the rect of control pName) into tRect

mobileControlCreate "scroller", pName

mobileControlSet pName, "rect", tRect

put ("0,0," & (the formattedwidth of control pName) & "," & the formattedheight 
of control pName) into tRect

mobileControlSet pName, "contentRect" , tRect

mobileControlSet pName, "hScroll" , 0

mobileControlSet pName, "vScroll" , 0

mobileControlSet pName, "hIndicator" , false

-- if pName = "quote" then

-- mobileControlSet pName, "vIndicator", true

-- end if

mobileControlSet pName, "visible", true

end CreateScroller

on scrollerDidScroll hScrolled, vScrolled

put mobileControlTarget() into tControlID

set the vscroll of control tControlID to vscrolled

pass scrollerDidScroll

end scrollerDidScroll

function isMobile -- jg, for convenience

return the environment is "mobile"

end isMobile

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

We are looking to use some back scripts on mobile.

If I add this to a backscript

command testMessagePath pMessage
  answer pMessage with "OK"
end testMessagePath


Add this to either a back OR front script.

then add a button to the top of any card in the stack

testMessagePath "Got it"

save and reload the stack… it works on desktop, but not on mobile

OTOH some other commands in the back script *are* firing… because we have some 
set up functions that are not failing.

Are there caveats for using front and back scripts on mobile that we need 
understand?

BR


To add more failure points

this works if we put everything in the stack script of the stack that has the 
scrolling group. but if we move the "createScroller" and isMobile and 
scrollerDidScroll commands to the back or front script… they fail.

??


on opencard

set the vScroll of grp "portal-links" to 0 -- ensures correct initial alignment

createScroller "portal-links" -- replaces any existing one

end opencard



command CreateScroller pName -- scrolling fields

if not isMobile() then exit CreateScroller

deleteMobileControl pName -- delete any existing

put (the rect of control pName) into tRect

mobileControlCreate "scroller", pName

mobileControlSet pName, "rect", tRect

put ("0,0," & (the formattedwidth of control pName) & "," & the formattedheight 
of control pName) into tRect

mobileControlSet pName, "contentRect" , tRect

mobileControlSet pName, "hScroll" , 0

mobileControlSet pName, "vScroll" , 0

mobileControlSet pName, "hIndicator" , false

-- if pName = "quote" then

-- mobileControlSet pName, "vIndicator", true

-- end if

mobileControlSet pName, "visible", true

end CreateScroller

on scrollerDidScroll hScrolled, vScrolled

put mobileControlTarget() into tControlID

set the vscroll of control tControlID to vscrolled

pass scrollerDidScroll

end scrollerDidScroll

function isMobile -- jg, for convenience

return the environment is "mobile"

end isMobile

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Front and Back Scripts on Mobile

[Sannyasin Brahmanathaswami]

We are looking to use some back scripts on mobile.

If I add this to a backscript

command testMessagePath pMessage
  answer pMessage with "OK"
end testMessagePath


Add this to either a back OR front script.

then add a button to the top of any card in the stack

testMessagePath "Got it"

save and reload the stack… it works on desktop, but not on mobile

OTOH some other commands in the back script *are* firing… because we have some 
set up functions that are not failing.

Are there caveats for using front and back scripts on mobile that we need 
understand?

BR


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode