Re: Controls on mobile apps - am I missing something?

[Richard Gaskin]

Ben Rubinstein wrote:

> A checkbox on each desktop platform takes on something at least
> approximately akin to the native appearance.
...
> But on iOS there's not the slightest attempt, which seems odd
> considering how much effort has gone into supporting the mobile
> platforms.
>
> And yes, you don't see often see a checkbox as such on iOS (apologies
> for concentrating on iOS but I'm not as familiar with Android).

People do all sorts of things.  Some might even have a 45-degree angled 
progress bar.  Not everything folks might want comes in the tin. :)


The HIGs for both iOS and Android suggest using a slider switch instead, 
which LC provides with a widget in v8.


Personally I think the checkbox is not only arguably less ambiguous, but 
a definite space-saver as well.  But alas it's not what either OS 
suggests we use for Boolean selectors.



> The native Mac display for a progress bar would look entirely
> suitable on iOS; if that's actually invoked by API (is it?) it still
> wouldn't take much work to draw it directly, and then again we'd get
> 'native' appearance that 'just worked' on each platform.

Fixed-length progress bars are definitely problematic.  Long processes 
for which we'd use a progress bar on the desktop should be extremely 
rare in a mobile app. With a handheld device there's a premium on the 
user's time, and any lengthy process may merit reconsideration, perhaps 
refactored to something that could be chunked in the background, or 
handled through some other means.  I suppose there may be cases where 
it's unavoidable, but IMO those should be the last resort when all other 
options have been tried.  Users really demand responsiveness in handheld 
devices, and apps that feel sluggish won't live long on the device.


That said, indeterminate progress indicators are frequently used on 
desktop and mobile, often for syncing and are almost always short-lived. 
 And unfortunately they're currently not possible to implement well in 
LiveCode at all.  These would require threaded GIFs, or threaded OS API 
hooks, neither of which we have.  Indeed, we're reminded of this each 
time we build a standalone, watching LC's progress indicator stutter 
frequently as it goes through its steps.


Now that LC Builder has been funded to include support for addressing 
APIs other than those based in C, I'm hoping we can get a crew together 
to have either OS-driven indeterminate progress indicators or 
separately-threaded GIF playback (or maybe both, since each is useful in 
its own right).



> As for radio buttons, using the pick control is really not a
> replacement; one is an interface element which permanently displays
> the status (and clearly indicates that the user can only make a
> single choice), and can be interacted with along with any other
> controls; whereas the mobile list picker appears temporarily only
> when the user explicitly decides to change this setting, and then
> can't do anything else until they make their choice and dismiss it.

Yes, which is why I mentioned that the on-screen element I use is an 
option control.  On mobile this renders as a button, and if I set its 
border and colors properly to compliment my app's appearance it can look 
quite nice.  If I find a case where I don't like the look I can have my 
library change its style to anything else on the fly.  The reason I use 
an option control is primarily because it lets me build rapidly in the 
IDE, providing the closest behavioral match for the mobile conventions 
to be invoked later at runtime.


I agree that hand-writing the code to tie it into the picker is tedious, 
which is why I only wrote it only once in a bit more generalized way and 
now my library does that for me.  I never think about that anymore.



> RunRev first made the product work on mobile platforms, it was a
> triumph, and we willingly put up with all the workarounds and
> emulations that were necessary to make the apps not look shit.
>
> But it's been six years now.

Whether an app looks like merde or not is more a function of the 
developer than of the engine.  I've seen many apps on the desktop that 
look completely horrible, even though it's not that hard to make a good 
looking app in LC.


On mobile we need to work a bit harder, but it's still doable.

Given the many years since scriptable mobile-native controls first 
premiered, it is a bit of a head-scratcher that I'm writing a version of 
the same library that Chipp, Ken, and so many others I've spoken to has 
written, nearly everyone except the vendor. :)


But I don't get paid to wait for others to make my work even easier.  I 
appreciate it when they do, but I've looked around for an even simpler 
solution as flexible as LC with the same platform coverage and I just 
can't find it.


So warts and all, I do what I can with what's available and for the most 
part I like it.  As the great bard Donald Rumsfeld once said, "You go to 
war with the army you have."


LC continues to 

TTS for mobile?

[Nicolas Cueto]

Very much out of my league in this, I'm sure, but...

Could someone give a general outline of how to add text-to-speech functions
to LC-built Android and iOS apps?

Alternatively, perhaps a rough estimate about the cost of hiring someone to
do this?

Thanks.

--
Nicolas Cueto
___
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: Vertical progress bar

[[-hh]]

There is also progress display available along slightly more complicated
objects than rotated lines, for example as HTML5 standalones (also as
Raspi-stacks #65-#68):

= Along a free polygon
http://hh.on-rev.com/html5/progressPoly2-8.0.0-dp-15X.html
= Along a regular polygon (choose 2 at top right for a line)
http://hh.on-rev.com/html5/hhProgressHTML5_1-8.0.0-dp-15X.html
= Along a bezier curve of order 2-9
http://hh.on-rev.com/html5/hhProgressHTML5_2-8.0.0-dp-15X.html
= Along math relations (for ex. spirals or  the 'adobe-logo')
http://hh.on-rev.com/html5/hhProgressHTML5_3-8.0.0-dp-15X.html

Hit "D" to show a progress demo (running 0-100%).
The check right of "D" lets you change the "base curve" (even while the
progress is running).



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Vertical-progress-bar-tp4706135p4706157.html
Sent from the Revolution - User mailing list archive at Nabble.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: Stopping a script

[Mike Bonner]

Since you're using a repeat until.. You can do repeat until (your first
requirement)  or not myflag

where on mouseenter you set myflag to true
on mouseleave you set it to false.

As a quick example (not using a flag, but even so you get the idea...)
repeat until the thumbpos of me  >= the endvalue of me or the shiftkey is
down
  set the thumbpos of me to the thumbpos of me + 1
  wait 10 millisec with messages
   end repeat

The above repeat loop fills up a progress bar.
You'll want a wait with messages somewhere in your repeat loop otherwise
there won't be time to set a flag.  (Not really necessary here because it
checks the shiftkey on each loop, but.. well ok it is necessary for the
screen to update and slow down the fill of the progress bar)

Even a wait 0 with messages should allow for your mouseleave to fire and
set your flag.

Also, if you're using small enough move increments, it would probably work
just as well to "set the loc.." of your button to the new location.  (or if
you don't mind it "jumping" around)


On Tue, Jun 28, 2016 at 1:57 PM, Tore Nilsen  wrote:

> Agreed. The send moveFigure to me in the moveFigure handler could be
> removed if you only want the figure to move once each time the mouse enters
> the object.
>
> I handed my students a stack with a similar script where a button would
> jump to a new loc each time the tried to press it. (The loc was randomly
> chosen though)
> They had to figure out how to stop this from happening, without deleting
> any of the code I had written.
>
>
> Tore
> > 28. jun. 2016 kl. 21.49 skrev Dar Scott :
> >
> > This could end up with several copies of moveFigure in pending
> messages.  Don't resend if the flag is false.  Or, cancel the message.
> >
> > (And you might be able to do this with moveStopped instead of send.)
> >
> >> On Jun 28, 2016, at 1:45 PM, Tore Nilsen  wrote:
> >>
> >> The variables needs to be global rather than local if the scripts are
> to be placed in both the card script and the script of the figure that
> should be moved. The first line of the card script and the first line of
> the script in the object should then read:
> >>
> >> global sMoveLine,sMoveSteps,sMove
> >>
> >> Tore
> >>
> >>> 28. jun. 2016 kl. 21.40 skrev Tore Nilsen :
> >>>
> >>> I am not quite sure I understand what you are trying to do , but I’ll
> have a go at it:
> >>>
> >>> /*This is what I would put into the cardscript*/
> >>>
> >>> local sMoveLine,sMoveSteps,sMove
> >>>
> >>> on openCard
> >>>
> >>> put field "moveSpots" into sMoveSteps --put the coordinates into a
> variable for faster execution of script
> >>>
> >>> put 0 into sMoveLine -- initialising the steps
> >>>
> >>> put "false" into sMove -- initialising a variable to control movement
> >>>
> >>> end openCard
> >>>
> >>>
> >>> /*This would go into the script of the object that should be moved*/
> >>>
> >>> on mouseEnter
> >>>
> >>> put not sMove into sMove -- change the movement control to true
> >>>
> >>> add 1 to sMoveLine -- get the next set of coordinates
> >>>
> >>> send moveFigure to me in x milliseconds --starts/stops the movement
> >>>
> >>> end mouseEnter
> >>>
> >>>
> >>> on moveFigure
> >>>
> >>> if sMove is true then
> >>>
> >>> put line sMoveLine of sMoveSteps into tNewLoc -- finds the new location
> >>>
> >>> move me to tNewLoc in y seconds -- moves to the new location in
> specified time
> >>>
> >>> end if
> >>>
> >>> send moveFigure to me in x milliseconds --starts/stops the movement
> >>>
> >>> end moveFigure
> >>>
> >>>
> >>> on mouseLeave
> >>>
> >>> put "false" into sMove
> >>>
> >>> end mouseLeave
> >>>
> >>>
> >>> Regards Tore
> >>>
> >>>
> >>>
>  28. jun. 2016 kl. 21.05 skrev d...@swcp.com:
> 
>  correction:  the walking figure used 'send' not 'move'
> 
> > On Jun 28, 2016, at 12:59 PM, Dar Scott  wrote:
> >
> > Maybe this is a good time to introduce the event style of
> programming.
> >
> > Focus on 'move...without waiting', and 'moveStopped' and maybe
> 'send'.
> >
> > Well, if the details allow that.  If using moveStopped makes things
> jerky, then you might need to do something else.  However, I think my
> grandson made a walking stick figure doing this.
> >
> > When you stop, not only stop moving but also set a flag so
> moveStopped does not start the next motion.
> >
> >
> >> On Jun 28, 2016, at 12:32 PM, Richmond 
> wrote:
> >>
> >> I have a *button* which, when I click on it, sends a *graphic
> object* off on a mad journey all over
> >> a *card* based on reading positions from a*listField*.
> >>
> >> I have tried *STOP MOVING* to interrupt that script, but that does
> *NOT* work
> >> because the graphic is executing a large number of very short
> movements in a cycling
> >> *REPEAT UNTIL* structure.
> >>
> >> Ideally (Ho, Ho, Ho.) I should 

Re: Controls on mobile apps - am I missing something?

[Ben Rubinstein]

Richard,

Thanks for your reply (and thanks Mike for the tmControls recommendation). I'm 
aware that we can make our own controls; and can use some native ones.


But surely the point of LiveCode being cross platform is that we shouldn't 
need to?


A checkbox on each desktop platform takes on something at least approximately 
akin to the native appearance.  In some cases in years gone by we used to see 
that the Mac controls at least started to look dated; because the engine drew 
approximations of the native controls, when Apple updated the OS they didn't 
look as modern. But they still looked like Mac; and something similar happened 
on Windows when that OS refreshed the UI, but again our software was 
recognisably Windows like.


But on iOS there's not the slightest attempt, which seems odd considering how 
much effort has gone into supporting the mobile platforms.


And yes, you don't see often see a checkbox as such on iOS (apologies for 
concentrating on iOS but I'm not as familiar with Android). But given that 
RunRev have made a switch widget and shipped it with the system, why not 
bundle it into the core and use that to render a 'checkbox'?  The native Mac 
display for a progress bar would look entirely suitable on iOS; if that's 
actually invoked by API (is it?) it still wouldn't take much work to draw it 
directly, and then again we'd get 'native' appearance that 'just worked' on 
each platform.


As for radio buttons, using the pick control is really not a replacement; one 
is an interface element which permanently displays the status (and clearly 
indicates that the user can only make a single choice), and can be interacted 
with along with any other controls; whereas the mobile list picker appears 
temporarily only when the user explicitly decides to change this setting, and 
then can't do anything else until they make their choice and dismiss it. (I'm 
glad to have it, of course - I just don't think it's very close match for 
radio buttons.)


Your library sounds very impressive; and tmControls look great too. When 
RunRev first made the product work on mobile platforms, it was a triumph, and 
we willingly put up with all the workarounds and emulations that were 
necessary to make the apps not look shit.


But it's been six years now.

I accept that native desktop elements won't always be appropriate on mobile; I 
don't expect that apps trying to use 'standard' interfaces will just be write 
once, run anywhere.


But after six years, I was just genuinely surprised to find that the standard 
controls still look shit, when they don't need to. I thought I must have 
missed a setting for theme or something like it.


Ben

On 27/06/2016 19:41, Richard Gaskin wrote:

Ben Rubinstein wrote:


My previous mobile app dabbling had involved entirely custom
interfaces. Now I'm trying to create a more straightforward app
with a more conventional interface - and I'm getting a horrible
dichotomy between the widgets (header bar, navigation bar, switch
control, segmented control) and the traditional controls (radio
buttons, sliders, progress bars, etc).  The latter look fine
on Mac; but on iOS, they've gone back to Motif, which is to say
several decades.


iOS does not contain the APIs to render Mac controls, so LC defaults to its
built-in Motif emulation.

Most desktop controls are unsuitable for use on mobile anyway, so using the
types of mobile controls users are accustomed to is a better bet.

Buttons are buttons, of course, and you can get very good appearances by just
changing the style to rectangle or roundRect, with whatever background and
hilite colors compliment your app's appearance.

Radio control take up too much space on small devices.  More commonly pick
lists are used, and LC provides commands to instantiate OS-native pick lists
on mobile.

The closest fit for a radio control on mobile might be an option control,
which is what I use as the on-screen control the user clicks to bring up the
pick list.

For those, and editable fields and scrollers, it took me about 10 minutes to
find the process of scripting the instantiation of their mobile-native
counterparts tedious to the point of feeling silly.  So instead I wrote a
backscript that catches preOpenCard to do my instantiation for me.

My lib examines the controls on the card and then calls mobileControlCreate as
needed, making editable text fields, scroll interaction overlays, etc. as 
needed.

Once I figured out that scrollers for fields are actually MUCH simpler than
the LC Lesson for that suggests, getting the basic functionality in place took
just a couple hours.  In fact, given how liberating it is to be able to use
LiveCode objects on the desktop and have a lib automatically take care of
replacing them with their mobile-native counterparts, even mapping relevant
messages between them so I don't need to write as much platform-forked code,
I've been surprised this isn't included with LC itself.

I'm still making lots of changes to my 

Re: Vertical progress bar

[Ali Lloyd]

> I wonder how a 45 degree progress bar could be made?

A progress bar widget with arbitrary rotation would be relatively easy,
perhaps a good first widget project, should anyone be looking for such a
thing.

There's even some code for a progress bar widget lying around in the
LiveCode GitHub repo...
https://github.com/livecode/livecode/blob/develop/extensions/widgets/progressbar/progressbar.lcb

On Tue, Jun 28, 2016 at 7:53 PM Dar Scott  wrote:

> I make weird ones out of polygons.  In this case, use one for the outline
> and one filled polygon for the progress.  Group them and have a group
> property do the math.
>
> > On Jun 28, 2016, at 12:46 PM, Richmond 
> wrote:
> >
> > I wonder how a 45 degree progress bar could be made?
> >
> > R.
> >
> > On 28.06.2016 21:44, Mark Wieder wrote:
> >> Tore Nilsen  writes:
> >>
> >>> If the rect is square the scrollbar/progressbar will be vertical.
> >> Thanks.
> >> Laziness/procrastination FTW.
> >>
> >
> >
> > ___
> > 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: Stopping a script

[Tore Nilsen]

Agreed. The send moveFigure to me in the moveFigure handler could be removed if 
you only want the figure to move once each time the mouse enters the object.

I handed my students a stack with a similar script where a button would jump to 
a new loc each time the tried to press it. (The loc was randomly chosen though)
They had to figure out how to stop this from happening, without deleting any of 
the code I had written.


Tore
> 28. jun. 2016 kl. 21.49 skrev Dar Scott :
> 
> This could end up with several copies of moveFigure in pending messages.  
> Don't resend if the flag is false.  Or, cancel the message.  
> 
> (And you might be able to do this with moveStopped instead of send.)
> 
>> On Jun 28, 2016, at 1:45 PM, Tore Nilsen  wrote:
>> 
>> The variables needs to be global rather than local if the scripts are to be 
>> placed in both the card script and the script of the figure that should be 
>> moved. The first line of the card script and the first line of the script in 
>> the object should then read:
>> 
>> global sMoveLine,sMoveSteps,sMove 
>> 
>> Tore
>> 
>>> 28. jun. 2016 kl. 21.40 skrev Tore Nilsen :
>>> 
>>> I am not quite sure I understand what you are trying to do , but I’ll have 
>>> a go at it:
>>> 
>>> /*This is what I would put into the cardscript*/
>>> 
>>> local sMoveLine,sMoveSteps,sMove
>>> 
>>> on openCard
>>> 
>>> put field "moveSpots" into sMoveSteps --put the coordinates into a variable 
>>> for faster execution of script
>>> 
>>> put 0 into sMoveLine -- initialising the steps
>>> 
>>> put "false" into sMove -- initialising a variable to control movement
>>> 
>>> end openCard
>>> 
>>> 
>>> /*This would go into the script of the object that should be moved*/
>>> 
>>> on mouseEnter
>>> 
>>> put not sMove into sMove -- change the movement control to true
>>> 
>>> add 1 to sMoveLine -- get the next set of coordinates
>>> 
>>> send moveFigure to me in x milliseconds --starts/stops the movement
>>> 
>>> end mouseEnter
>>> 
>>> 
>>> on moveFigure
>>> 
>>> if sMove is true then
>>> 
>>> put line sMoveLine of sMoveSteps into tNewLoc -- finds the new location
>>> 
>>> move me to tNewLoc in y seconds -- moves to the new location in specified 
>>> time
>>> 
>>> end if
>>> 
>>> send moveFigure to me in x milliseconds --starts/stops the movement
>>> 
>>> end moveFigure
>>> 
>>> 
>>> on mouseLeave
>>> 
>>> put "false" into sMove
>>> 
>>> end mouseLeave
>>> 
>>> 
>>> Regards Tore
>>> 
>>> 
>>> 
 28. jun. 2016 kl. 21.05 skrev d...@swcp.com:
 
 correction:  the walking figure used 'send' not 'move'
 
> On Jun 28, 2016, at 12:59 PM, Dar Scott  wrote:
> 
> Maybe this is a good time to introduce the event style of programming.  
> 
> Focus on 'move...without waiting', and 'moveStopped' and maybe 'send'.  
> 
> Well, if the details allow that.  If using moveStopped makes things 
> jerky, then you might need to do something else.  However, I think my 
> grandson made a walking stick figure doing this.  
> 
> When you stop, not only stop moving but also set a flag so moveStopped 
> does not start the next motion.  
> 
> 
>> On Jun 28, 2016, at 12:32 PM, Richmond  
>> wrote:
>> 
>> I have a *button* which, when I click on it, sends a *graphic object* 
>> off on a mad journey all over
>> a *card* based on reading positions from a*listField*.
>> 
>> I have tried *STOP MOVING* to interrupt that script, but that does *NOT* 
>> work
>> because the graphic is executing a large number of very short movements 
>> in a cycling
>> *REPEAT UNTIL* structure.
>> 
>> Ideally (Ho, Ho, Ho.) I should like to be able to have something like 
>> this:
>> 
>> the mad movement script starts executing when triggered by a 
>> *mouseEnter* script
>> in the *graphic object* that moves,
>> 
>> and
>> 
>> some sort of *STOP SCRIPT* in a *mouseLeave* script in the same *graphic 
>> object*.
>> 
>> Now, I know that sounds a bit *bonkers*, but I am writing this on behalf 
>> of a very bright chap
>> who is attending my Summer classes, and I do understand what he is 
>> trying to achieve.
>> 
>> Richmond.
>> ___
>> 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: Stopping a script

[dsc]

Arg.  I mean cancel in mouseLeave.

> On Jun 28, 2016, at 1:49 PM, Dar Scott  wrote:
> 
> This could end up with several copies of moveFigure in pending messages.  
> Don't resend if the flag is false.  Or, cancel the message.  
> 
> (And you might be able to do this with moveStopped instead of send.)
> 
>> On Jun 28, 2016, at 1:45 PM, Tore Nilsen  wrote:
>> 
>> The variables needs to be global rather than local if the scripts are to be 
>> placed in both the card script and the script of the figure that should be 
>> moved. The first line of the card script and the first line of the script in 
>> the object should then read:
>> 
>> global sMoveLine,sMoveSteps,sMove 
>> 
>> Tore
>> 
>>> 28. jun. 2016 kl. 21.40 skrev Tore Nilsen :
>>> 
>>> I am not quite sure I understand what you are trying to do , but I’ll have 
>>> a go at it:
>>> 
>>> /*This is what I would put into the cardscript*/
>>> 
>>> local sMoveLine,sMoveSteps,sMove
>>> 
>>> on openCard
>>> 
>>> put field "moveSpots" into sMoveSteps --put the coordinates into a variable 
>>> for faster execution of script
>>> 
>>> put 0 into sMoveLine -- initialising the steps
>>> 
>>> put "false" into sMove -- initialising a variable to control movement
>>> 
>>> end openCard
>>> 
>>> 
>>> /*This would go into the script of the object that should be moved*/
>>> 
>>> on mouseEnter
>>> 
>>> put not sMove into sMove -- change the movement control to true
>>> 
>>> add 1 to sMoveLine -- get the next set of coordinates
>>> 
>>> send moveFigure to me in x milliseconds --starts/stops the movement
>>> 
>>> end mouseEnter
>>> 
>>> 
>>> on moveFigure
>>> 
>>> if sMove is true then
>>> 
>>> put line sMoveLine of sMoveSteps into tNewLoc -- finds the new location
>>> 
>>> move me to tNewLoc in y seconds -- moves to the new location in specified 
>>> time
>>> 
>>> end if
>>> 
>>> send moveFigure to me in x milliseconds --starts/stops the movement
>>> 
>>> end moveFigure
>>> 
>>> 
>>> on mouseLeave
>>> 
>>> put "false" into sMove
>>> 
>>> end mouseLeave
>>> 
>>> 
>>> Regards Tore
>>> 
>>> 
>>> 
 28. jun. 2016 kl. 21.05 skrev d...@swcp.com:
 
 correction:  the walking figure used 'send' not 'move'
 
> On Jun 28, 2016, at 12:59 PM, Dar Scott  wrote:
> 
> Maybe this is a good time to introduce the event style of programming.  
> 
> Focus on 'move...without waiting', and 'moveStopped' and maybe 'send'.  
> 
> Well, if the details allow that.  If using moveStopped makes things 
> jerky, then you might need to do something else.  However, I think my 
> grandson made a walking stick figure doing this.  
> 
> When you stop, not only stop moving but also set a flag so moveStopped 
> does not start the next motion.  
> 
> 
>> On Jun 28, 2016, at 12:32 PM, Richmond  
>> wrote:
>> 
>> I have a *button* which, when I click on it, sends a *graphic object* 
>> off on a mad journey all over
>> a *card* based on reading positions from a*listField*.
>> 
>> I have tried *STOP MOVING* to interrupt that script, but that does *NOT* 
>> work
>> because the graphic is executing a large number of very short movements 
>> in a cycling
>> *REPEAT UNTIL* structure.
>> 
>> Ideally (Ho, Ho, Ho.) I should like to be able to have something like 
>> this:
>> 
>> the mad movement script starts executing when triggered by a 
>> *mouseEnter* script
>> in the *graphic object* that moves,
>> 
>> and
>> 
>> some sort of *STOP SCRIPT* in a *mouseLeave* script in the same *graphic 
>> object*.
>> 
>> Now, I know that sounds a bit *bonkers*, but I am writing this on behalf 
>> of a very bright chap
>> who is attending my Summer classes, and I do understand what he is 
>> trying to achieve.
>> 
>> Richmond.
>> ___
>> 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
>>> 
>>> ___
>>> use-livecode mailing list
>>> use-livecode@lists.runrev.com
>>> Please visit this url to subscribe, 

Re: Stopping a script

[Dar Scott]

This could end up with several copies of moveFigure in pending messages.  Don't 
resend if the flag is false.  Or, cancel the message.  

(And you might be able to do this with moveStopped instead of send.)

> On Jun 28, 2016, at 1:45 PM, Tore Nilsen  wrote:
> 
> The variables needs to be global rather than local if the scripts are to be 
> placed in both the card script and the script of the figure that should be 
> moved. The first line of the card script and the first line of the script in 
> the object should then read:
> 
> global sMoveLine,sMoveSteps,sMove 
> 
> Tore
> 
>> 28. jun. 2016 kl. 21.40 skrev Tore Nilsen :
>> 
>> I am not quite sure I understand what you are trying to do , but I’ll have a 
>> go at it:
>> 
>> /*This is what I would put into the cardscript*/
>> 
>> local sMoveLine,sMoveSteps,sMove
>> 
>> on openCard
>> 
>> put field "moveSpots" into sMoveSteps --put the coordinates into a variable 
>> for faster execution of script
>> 
>> put 0 into sMoveLine -- initialising the steps
>> 
>> put "false" into sMove -- initialising a variable to control movement
>> 
>> end openCard
>> 
>> 
>> /*This would go into the script of the object that should be moved*/
>> 
>> on mouseEnter
>> 
>> put not sMove into sMove -- change the movement control to true
>> 
>> add 1 to sMoveLine -- get the next set of coordinates
>> 
>> send moveFigure to me in x milliseconds --starts/stops the movement
>> 
>> end mouseEnter
>> 
>> 
>> on moveFigure
>> 
>> if sMove is true then
>> 
>> put line sMoveLine of sMoveSteps into tNewLoc -- finds the new location
>> 
>> move me to tNewLoc in y seconds -- moves to the new location in specified 
>> time
>> 
>> end if
>> 
>> send moveFigure to me in x milliseconds --starts/stops the movement
>> 
>> end moveFigure
>> 
>> 
>> on mouseLeave
>> 
>> put "false" into sMove
>> 
>> end mouseLeave
>> 
>> 
>> Regards Tore
>> 
>> 
>> 
>>> 28. jun. 2016 kl. 21.05 skrev d...@swcp.com:
>>> 
>>> correction:  the walking figure used 'send' not 'move'
>>> 
 On Jun 28, 2016, at 12:59 PM, Dar Scott  wrote:
 
 Maybe this is a good time to introduce the event style of programming.  
 
 Focus on 'move...without waiting', and 'moveStopped' and maybe 'send'.  
 
 Well, if the details allow that.  If using moveStopped makes things jerky, 
 then you might need to do something else.  However, I think my grandson 
 made a walking stick figure doing this.  
 
 When you stop, not only stop moving but also set a flag so moveStopped 
 does not start the next motion.  
 
 
> On Jun 28, 2016, at 12:32 PM, Richmond  
> wrote:
> 
> I have a *button* which, when I click on it, sends a *graphic object* off 
> on a mad journey all over
> a *card* based on reading positions from a*listField*.
> 
> I have tried *STOP MOVING* to interrupt that script, but that does *NOT* 
> work
> because the graphic is executing a large number of very short movements 
> in a cycling
> *REPEAT UNTIL* structure.
> 
> Ideally (Ho, Ho, Ho.) I should like to be able to have something like 
> this:
> 
> the mad movement script starts executing when triggered by a *mouseEnter* 
> script
> in the *graphic object* that moves,
> 
> and
> 
> some sort of *STOP SCRIPT* in a *mouseLeave* script in the same *graphic 
> object*.
> 
> Now, I know that sounds a bit *bonkers*, but I am writing this on behalf 
> of a very bright chap
> who is attending my Summer classes, and I do understand what he is trying 
> to achieve.
> 
> Richmond.
> ___
> 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
>> 
>> ___
>> 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 

Re: Stopping a script

[Tore Nilsen]

The variables needs to be global rather than local if the scripts are to be 
placed in both the card script and the script of the figure that should be 
moved. The first line of the card script and the first line of the script in 
the object should then read:

global sMoveLine,sMoveSteps,sMove 

Tore

> 28. jun. 2016 kl. 21.40 skrev Tore Nilsen :
> 
> I am not quite sure I understand what you are trying to do , but I’ll have a 
> go at it:
> 
> /*This is what I would put into the cardscript*/
> 
> local sMoveLine,sMoveSteps,sMove
> 
> on openCard
> 
> put field "moveSpots" into sMoveSteps --put the coordinates into a variable 
> for faster execution of script
> 
> put 0 into sMoveLine -- initialising the steps
> 
> put "false" into sMove -- initialising a variable to control movement
> 
> end openCard
> 
> 
> /*This would go into the script of the object that should be moved*/
> 
> on mouseEnter
> 
> put not sMove into sMove -- change the movement control to true
> 
> add 1 to sMoveLine -- get the next set of coordinates
> 
> send moveFigure to me in x milliseconds --starts/stops the movement
> 
> end mouseEnter
> 
> 
> on moveFigure
> 
> if sMove is true then
> 
> put line sMoveLine of sMoveSteps into tNewLoc -- finds the new location
> 
> move me to tNewLoc in y seconds -- moves to the new location in specified time
> 
> end if
> 
> send moveFigure to me in x milliseconds --starts/stops the movement
> 
> end moveFigure
> 
> 
> on mouseLeave
> 
> put "false" into sMove
> 
> end mouseLeave
> 
> 
> Regards Tore
> 
> 
> 
>> 28. jun. 2016 kl. 21.05 skrev d...@swcp.com:
>> 
>> correction:  the walking figure used 'send' not 'move'
>> 
>>> On Jun 28, 2016, at 12:59 PM, Dar Scott  wrote:
>>> 
>>> Maybe this is a good time to introduce the event style of programming.  
>>> 
>>> Focus on 'move...without waiting', and 'moveStopped' and maybe 'send'.  
>>> 
>>> Well, if the details allow that.  If using moveStopped makes things jerky, 
>>> then you might need to do something else.  However, I think my grandson 
>>> made a walking stick figure doing this.  
>>> 
>>> When you stop, not only stop moving but also set a flag so moveStopped does 
>>> not start the next motion.  
>>> 
>>> 
 On Jun 28, 2016, at 12:32 PM, Richmond  wrote:
 
 I have a *button* which, when I click on it, sends a *graphic object* off 
 on a mad journey all over
 a *card* based on reading positions from a*listField*.
 
 I have tried *STOP MOVING* to interrupt that script, but that does *NOT* 
 work
 because the graphic is executing a large number of very short movements in 
 a cycling
 *REPEAT UNTIL* structure.
 
 Ideally (Ho, Ho, Ho.) I should like to be able to have something like this:
 
 the mad movement script starts executing when triggered by a *mouseEnter* 
 script
 in the *graphic object* that moves,
 
 and
 
 some sort of *STOP SCRIPT* in a *mouseLeave* script in the same *graphic 
 object*.
 
 Now, I know that sounds a bit *bonkers*, but I am writing this on behalf 
 of a very bright chap
 who is attending my Summer classes, and I do understand what he is trying 
 to achieve.
 
 Richmond.
 ___
 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
> 
> ___
> 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: Stopping a script

[Tore Nilsen]

I am not quite sure I understand what you are trying to do , but I’ll have a go 
at it:

/*This is what I would put into the cardscript*/

local sMoveLine,sMoveSteps,sMove

on openCard

put field "moveSpots" into sMoveSteps --put the coordinates into a variable for 
faster execution of script

put 0 into sMoveLine -- initialising the steps

put "false" into sMove -- initialising a variable to control movement

end openCard


/*This would go into the script of the object that should be moved*/

on mouseEnter

put not sMove into sMove -- change the movement control to true

add 1 to sMoveLine -- get the next set of coordinates

send moveFigure to me in x milliseconds --starts/stops the movement

end mouseEnter


on moveFigure

if sMove is true then

put line sMoveLine of sMoveSteps into tNewLoc -- finds the new location

move me to tNewLoc in y seconds -- moves to the new location in specified time

end if

send moveFigure to me in x milliseconds --starts/stops the movement

end moveFigure


on mouseLeave

put "false" into sMove

end mouseLeave


Regards Tore



> 28. jun. 2016 kl. 21.05 skrev d...@swcp.com:
> 
> correction:  the walking figure used 'send' not 'move'
> 
>> On Jun 28, 2016, at 12:59 PM, Dar Scott  wrote:
>> 
>> Maybe this is a good time to introduce the event style of programming.  
>> 
>> Focus on 'move...without waiting', and 'moveStopped' and maybe 'send'.  
>> 
>> Well, if the details allow that.  If using moveStopped makes things jerky, 
>> then you might need to do something else.  However, I think my grandson made 
>> a walking stick figure doing this.  
>> 
>> When you stop, not only stop moving but also set a flag so moveStopped does 
>> not start the next motion.  
>> 
>> 
>>> On Jun 28, 2016, at 12:32 PM, Richmond  wrote:
>>> 
>>> I have a *button* which, when I click on it, sends a *graphic object* off 
>>> on a mad journey all over
>>> a *card* based on reading positions from a*listField*.
>>> 
>>> I have tried *STOP MOVING* to interrupt that script, but that does *NOT* 
>>> work
>>> because the graphic is executing a large number of very short movements in 
>>> a cycling
>>> *REPEAT UNTIL* structure.
>>> 
>>> Ideally (Ho, Ho, Ho.) I should like to be able to have something like this:
>>> 
>>> the mad movement script starts executing when triggered by a *mouseEnter* 
>>> script
>>> in the *graphic object* that moves,
>>> 
>>> and
>>> 
>>> some sort of *STOP SCRIPT* in a *mouseLeave* script in the same *graphic 
>>> object*.
>>> 
>>> Now, I know that sounds a bit *bonkers*, but I am writing this on behalf of 
>>> a very bright chap
>>> who is attending my Summer classes, and I do understand what he is trying 
>>> to achieve.
>>> 
>>> Richmond.
>>> ___
>>> 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

___
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: Stopping a script

[Paul Hibbert]

When testing repeats I usually include a line something like;

if the altKey is down then exit repeat -- or you could use exit to top

Paul

> On Jun 28, 2016, at 11:32 AM, Richmond  wrote:
> 
> I have tried *STOP MOVING* to interrupt that script, but that does *NOT* work
> because the graphic is executing a large number of very short movements in a 
> cycling
> *REPEAT UNTIL* structure.


___
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: Stopping a script

[dsc]

correction:  the walking figure used 'send' not 'move'

> On Jun 28, 2016, at 12:59 PM, Dar Scott  wrote:
> 
> Maybe this is a good time to introduce the event style of programming.  
> 
> Focus on 'move...without waiting', and 'moveStopped' and maybe 'send'.  
> 
> Well, if the details allow that.  If using moveStopped makes things jerky, 
> then you might need to do something else.  However, I think my grandson made 
> a walking stick figure doing this.  
> 
> When you stop, not only stop moving but also set a flag so moveStopped does 
> not start the next motion.  
> 
> 
>> On Jun 28, 2016, at 12:32 PM, Richmond  wrote:
>> 
>> I have a *button* which, when I click on it, sends a *graphic object* off on 
>> a mad journey all over
>> a *card* based on reading positions from a*listField*.
>> 
>> I have tried *STOP MOVING* to interrupt that script, but that does *NOT* work
>> because the graphic is executing a large number of very short movements in a 
>> cycling
>> *REPEAT UNTIL* structure.
>> 
>> Ideally (Ho, Ho, Ho.) I should like to be able to have something like this:
>> 
>> the mad movement script starts executing when triggered by a *mouseEnter* 
>> script
>> in the *graphic object* that moves,
>> 
>> and
>> 
>> some sort of *STOP SCRIPT* in a *mouseLeave* script in the same *graphic 
>> object*.
>> 
>> Now, I know that sounds a bit *bonkers*, but I am writing this on behalf of 
>> a very bright chap
>> who is attending my Summer classes, and I do understand what he is trying to 
>> achieve.
>> 
>> Richmond.
>> ___
>> 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: Stopping a script

[Dar Scott]

Maybe this is a good time to introduce the event style of programming.  

Focus on 'move...without waiting', and 'moveStopped' and maybe 'send'.  

Well, if the details allow that.  If using moveStopped makes things jerky, then 
you might need to do something else.  However, I think my grandson made a 
walking stick figure doing this.  

When you stop, not only stop moving but also set a flag so moveStopped does not 
start the next motion.  


> On Jun 28, 2016, at 12:32 PM, Richmond  wrote:
> 
> I have a *button* which, when I click on it, sends a *graphic object* off on 
> a mad journey all over
> a *card* based on reading positions from a*listField*.
> 
> I have tried *STOP MOVING* to interrupt that script, but that does *NOT* work
> because the graphic is executing a large number of very short movements in a 
> cycling
> *REPEAT UNTIL* structure.
> 
> Ideally (Ho, Ho, Ho.) I should like to be able to have something like this:
> 
> the mad movement script starts executing when triggered by a *mouseEnter* 
> script
> in the *graphic object* that moves,
> 
> and
> 
> some sort of *STOP SCRIPT* in a *mouseLeave* script in the same *graphic 
> object*.
> 
> Now, I know that sounds a bit *bonkers*, but I am writing this on behalf of a 
> very bright chap
> who is attending my Summer classes, and I do understand what he is trying to 
> achieve.
> 
> Richmond.
> ___
> 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: Vertical progress bar

[Dar Scott]

I make weird ones out of polygons.  In this case, use one for the outline and 
one filled polygon for the progress.  Group them and have a group property do 
the math.  

> On Jun 28, 2016, at 12:46 PM, Richmond  wrote:
> 
> I wonder how a 45 degree progress bar could be made?
> 
> R.
> 
> On 28.06.2016 21:44, Mark Wieder wrote:
>> Tore Nilsen  writes:
>> 
>>> If the rect is square the scrollbar/progressbar will be vertical.
>> Thanks.
>> Laziness/procrastination FTW.
>> 
> 
> 
> ___
> 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: Vertical progress bar

[rjd318]

Wow! Is right =)  I was already planning crazy stuff in my head as to how to do 
this (it wasn't going well) so thank you so much for the info!

> On Jun 28, 2016, at 12:39 PM, Tore Nilsen  wrote:
> 
> If the rect is square the scrollbar/progressbar will be vertical.
> 
> Tore
>> 28. jun. 2016 kl. 19.34 skrev Mark Wieder :
>> 
>> Dar Scott  writes:
>> 
>>> 
>>> Wow!  That is cool!  How did you even discover this?  
>> 
>> Progressbars are a subclass of scrollbars.
>> You can have horizontal and vertical scrollbars.
>> The rect determines which.
>> (not sure what happens with squares)
>> 
>> -- 
>> 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
> 
> 
> ___
> 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: Vertical progress bar

[Richmond]

I wonder how a 45 degree progress bar could be made?

R.

On 28.06.2016 21:44, Mark Wieder wrote:

Tore Nilsen  writes:


If the rect is square the scrollbar/progressbar will be vertical.

Thanks.
Laziness/procrastination FTW.




___
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: Vertical progress bar

[Mark Wieder]

Tore Nilsen  writes:

> If the rect is square the scrollbar/progressbar will be vertical.

Thanks.
Laziness/procrastination FTW.

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

Stopping a script

[Richmond]

I have a *button* which, when I click on it, sends a *graphic object* 
off on a mad journey all over

a *card* based on reading positions from a*listField*.

I have tried *STOP MOVING* to interrupt that script, but that does *NOT* 
work
because the graphic is executing a large number of very short movements 
in a cycling

*REPEAT UNTIL* structure.

Ideally (Ho, Ho, Ho.) I should like to be able to have something like this:

the mad movement script starts executing when triggered by a 
*mouseEnter* script

in the *graphic object* that moves,

and

some sort of *STOP SCRIPT* in a *mouseLeave* script in the same *graphic 
object*.


Now, I know that sounds a bit *bonkers*, but I am writing this on behalf 
of a very bright chap
who is attending my Summer classes, and I do understand what he is 
trying to achieve.


Richmond.
___
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: Vertical progress bar

[Tore Nilsen]

If the rect is square the scrollbar/progressbar will be vertical.

Tore
> 28. jun. 2016 kl. 19.34 skrev Mark Wieder :
> 
> Dar Scott  writes:
> 
>> 
>> Wow!  That is cool!  How did you even discover this?  
> 
> Progressbars are a subclass of scrollbars.
> You can have horizontal and vertical scrollbars.
> The rect determines which.
> (not sure what happens with squares)
> 
> -- 
> 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


___
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: Vertical progress bar

[Mark Wieder]

Dar Scott  writes:

> 
> Wow!  That is cool!  How did you even discover this?  

Progressbars are a subclass of scrollbars.
You can have horizontal and vertical scrollbars.
The rect determines which.
(not sure what happens with squares)

-- 
 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: Vertical progress bar

[Tore Nilsen]

I cannot remember when, but I guess it was pure and simple logic. All controls 
have a bounding rect, and if this bounding rect is higher than its width then… 
:-)

Tore


> 28. jun. 2016 kl. 19.26 skrev Dar Scott :
> 
> Wow!  That is cool!  How did you even discover this?  
> 
>> On Jun 28, 2016, at 10:55 AM, Tore Nilsen  wrote:
>> 
>> It is even easier, just make the height of the bounding rectangle higher 
>> than the width and you will have a vertical progress bar.
>> 
>> Tore
>>> 28. jun. 2016 kl. 18.50 skrev rjd318 :
>>> 
>>> Hi all - I guess it's not as easy as rotating the existing progress bar 
>>> control? Anyone know of a pre-existing technique to do this?
>>> 
>>> - Jose 
>>> ___
>>> 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


___
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: Vertical progress bar

[Dar Scott]

Wow!  That is cool!  How did you even discover this?  

> On Jun 28, 2016, at 10:55 AM, Tore Nilsen  wrote:
> 
> It is even easier, just make the height of the bounding rectangle higher than 
> the width and you will have a vertical progress bar.
> 
> Tore
>> 28. jun. 2016 kl. 18.50 skrev rjd318 :
>> 
>> Hi all - I guess it's not as easy as rotating the existing progress bar 
>> control? Anyone know of a pre-existing technique to do this?
>> 
>> - Jose 
>> ___
>> 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: Vertical progress bar

[Tore Nilsen]

It is even easier, just make the height of the bounding rectangle higher than 
the width and you will have a vertical progress bar.

Tore
> 28. jun. 2016 kl. 18.50 skrev rjd318 :
> 
> Hi all - I guess it's not as easy as rotating the existing progress bar 
> control? Anyone know of a pre-existing technique to do this?
> 
> - Jose 
> ___
> 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

Vertical progress bar

[rjd318]

Hi all - I guess it's not as easy as rotating the existing progress bar 
control? Anyone know of a pre-existing technique to do this?

- Jose 
___
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: WordPress LiveCode Webinar Today @ 1:00pm est

[** Clarence P Martin **]

I want to thank you for the Webinar Yesterday along with thanks for all of
the info that you provided on Github. I am looking forward to your next
session.

Sincerely,

Clarence Martin
Email: chi...@themartinz.com
Cell: 626 6965561

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Todd Fabacher
Sent: Monday, June 27, 2016 7:26 AM
To: Use-livecode Use-livecode 
Subject: WordPress LiveCode Webinar Today @ 1:00pm est

We will be on Google Hangout today for the first of two webinars. Here is
the link: https://www.youtube.com/watch?v=D_6b04AltTQ

I will give a one hour introduction today into WordPress and how to connect
and control it with LiveCode. We have uploaded the code to git hub:
https://github.com/digitalpomegranate/livecode-wp-restapi

See you online,

Todd Fabacher
___
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: LiveCode HTML5

[Richard Gaskin]

Todd Fabacher wrote:

> I was just checking, I don't see a way to make an HTTP post back to a
> web server.  Am I wrong? If it is not there...is it in the pipeline?
>
> I have a HUGE project that we are planning to do in Angular JS, but
> would love to do in LiveCode HTML5.

LiveCode's post command will handle this with beautiful ease on all 
platforms - except HTML5.


The current build of the HTML5 export is unfortunately an island at the 
moment.  It does a pretty good job of bringing a stack into a browser, 
but does not yet have connectivity with the outside world via sockets, 
such as would be needed for HTTP.


For LC-built native apps this isn't a problem, of course.  And I believe 
at least half of the use cases in which people think they need to 
constrain their app within the confines of a browser could be more than 
adequately handled with native app implementations, mobile and desktop 
alike.


That said, there are some use cases that do require running inside of a 
browser, and at the moment those have no means of using the browser's 
inherent connectivity.


I believe this is being worked on now, but I don't have a timeline for 
that delivery.


In the meantime, if the ever-growing ubiquity of native apps still 
doesn't make them compelling enough to consider, even with the 
increasingly popular hybrid model using an embedded browser within a 
native app, another option is to use LC's wonderful layout capabilities 
to generated HTML/CSS, though that still leaves interactivity to be 
hand-translated to JavaScript.


--
 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: LiveCode HTML5

[Peter TB Brett]

On 28/06/2016 16:01, Todd Fabacher wrote:

I was just checking, I don't see a way to make an HTTP post back to a web
server.  Am I wrong? If it is not there...is it in the pipeline?

I have a HUGE project that we are planning to do in Angular JS, but would
love to do in LiveCode HTML5. We are looking to use HighCharts on the web,
but would be open to coding it in LiveCode if I could pull the data from a
JSON feed.


At the moment URL syntax in HTML5 standalones is very much not working, 
unfortunately.  It's a known issue but the work to implement it is not 
currently under way.


  Peter

--
Dr Peter Brett 
LiveCode Technical Project Manager

LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/

___
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: LiveCode HTML5

[Colin Holgate]

It’s not in the LiveCode 8 dictionary that I can see, but it’s in the LIveCode 
7 one. Something like:

post variables to URL “http://somewhere.com/example.html 
”

where variables would be “name=Todd=NYC”, etc.

 
> On Jun 28, 2016, at 11:01 AM, Todd Fabacher  wrote:
> 
> I was just checking, I don't see a way to make an HTTP post back to a web
> server.  Am I wrong? If it is not there...is it in the pipeline?
> 
> I have a HUGE project that we are planning to do in Angular JS, but would
> love to do in LiveCode HTML5. We are looking to use HighCharts on the web,
> but would be open to coding it in LiveCode if I could pull the data from a
> JSON feed.
> 
> 
> WordPress + LiveCode
> 
> Any questions on the WP code, let put them in the forum:
> http://forums.livecode.com/viewtopic.php?f=16=27400=144110#p144110
> 
> We will follow us in a few weeks, once people have played with the code. We
> will focus more on development, yesterday was just the intro:
> https://www.youtube.com/watch?v=D_6b04AltTQ
> 
> --Todd
> ___
> 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

LiveCode HTML5

[Todd Fabacher]

I was just checking, I don't see a way to make an HTTP post back to a web
server.  Am I wrong? If it is not there...is it in the pipeline?

I have a HUGE project that we are planning to do in Angular JS, but would
love to do in LiveCode HTML5. We are looking to use HighCharts on the web,
but would be open to coding it in LiveCode if I could pull the data from a
JSON feed.


WordPress + LiveCode

Any questions on the WP code, let put them in the forum:
http://forums.livecode.com/viewtopic.php?f=16=27400=144110#p144110

We will follow us in a few weeks, once people have played with the code. We
will focus more on development, yesterday was just the intro:
https://www.youtube.com/watch?v=D_6b04AltTQ

--Todd
___
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: Controls on mobile apps - am I missing something?

[Mike Kerner]

Spend the money and buy tmControls from Scott Rossi.  Every app I have
written is skinned the way I want it, and when I want something a little
different, I'm able to customize them as I choose.

On Mon, Jun 27, 2016 at 2:41 PM, Richard Gaskin 
wrote:

> Ben Rubinstein wrote:
>
> > My previous mobile app dabbling had involved entirely custom
> > interfaces. Now I'm trying to create a more straightforward app
> > with a more conventional interface - and I'm getting a horrible
> > dichotomy between the widgets (header bar, navigation bar, switch
> > control, segmented control) and the traditional controls (radio
> > buttons, sliders, progress bars, etc).  The latter look fine
> > on Mac; but on iOS, they've gone back to Motif, which is to say
> > several decades.
>
> iOS does not contain the APIs to render Mac controls, so LC defaults to
> its built-in Motif emulation.
>
> Most desktop controls are unsuitable for use on mobile anyway, so using
> the types of mobile controls users are accustomed to is a better bet.
>
> Buttons are buttons, of course, and you can get very good appearances by
> just changing the style to rectangle or roundRect, with whatever background
> and hilite colors compliment your app's appearance.
>
> Radio control take up too much space on small devices.  More commonly pick
> lists are used, and LC provides commands to instantiate OS-native pick
> lists on mobile.
>
> The closest fit for a radio control on mobile might be an option control,
> which is what I use as the on-screen control the user clicks to bring up
> the pick list.
>
> For those, and editable fields and scrollers, it took me about 10 minutes
> to find the process of scripting the instantiation of their mobile-native
> counterparts tedious to the point of feeling silly.  So instead I wrote a
> backscript that catches preOpenCard to do my instantiation for me.
>
> My lib examines the controls on the card and then calls
> mobileControlCreate as needed, making editable text fields, scroll
> interaction overlays, etc. as needed.
>
> Once I figured out that scrollers for fields are actually MUCH simpler
> than the LC Lesson for that suggests, getting the basic functionality in
> place took just a couple hours.  In fact, given how liberating it is to be
> able to use LiveCode objects on the desktop and have a lib automatically
> take care of replacing them with their mobile-native counterparts, even
> mapping relevant messages between them so I don't need to write as much
> platform-forked code, I've been surprised this isn't included with LC
> itself.
>
> I'm still making lots of changes to my lib as I work toward deployment, so
> it's not yet in a sharable state.  When it is I mkay dual-license it, but I
> hope by then LC will just have something like this in the install; most
> devs I've talked to have already written their own variants of this, and
> like most things the code isn't the hard parts, it's designing how it
> should work.  Maybe one of the many others in our community is already
> shared and usable
>
> --
>  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
>



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