Re: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 2:54 pm, Scott Morrow via use-livecode 
>  wrote:
> 
> What about the use of mobile-only commands… needing to always wrap them in 
> something to keep the IDE from touching.
> 
> if "mobile" is in the environment then
>  mobileControlSet tObject, tProp, tValue
> end if

Yes that’s quite a common bit of code in a mobile app!

Cheers

Monte
___
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: common code patterns

[Scott Morrow via use-livecode]

What about the use of mobile-only commands… needing to always wrap them in 
something to keep the IDE from touching.

if "mobile" is in the environment then
  mobileControlSet tObject, tProp, tValue
end if  


> On Aug 10, 2017, at 6:50 PM, Monte Goulding via use-livecode 
>  wrote:
> 
> 
>> On 11 Aug 2017, at 11:45 am, Mark Wieder via use-livecode 
>>  wrote:
>> 
>> You know, if you'd post what you're trying to do it might be more possible 
>> to stay on target here. For instance, I regularly have to fill an array with 
>> constants in an initialization routine or use a custom property array filled 
>> with constants. Is that any help? Or are you looking to make a macro 
>> processor? Or a library of common ? Or something else?
> 
> A library of common  is probably the best description at the moment 
> but the use case is not reusable handlers as we have other means for that.
> 
> Basically anything where you follow a common pattern to do a thing but you 
> can’t abstract away so you don’t have to write the pattern any more.
> 
> Cheers
> 
> Monte
> ___
> 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: Local File in Browser Widget on Android - Fail

[Sannyasin Brahmanathaswami via use-livecode]

make sure your slashes are all correct. on iOS and desktop  are forgiving with 
double// in URLs; but android is not.. .this bit me many times

file:/somepath/somefile.html

works

file://somepath/somefile.html  

doesn't  

So If you have path setters here and there, one needs to follow some 
convention, either leave folder string *always* with no closing slash and all 
appended url strings begin with a slash.. I started that way but this was 
always confusing to me because on web / means "from DOCROOT"   so slowly I am 
refactoring all these to

function path_Assets
return specialFolderPath("documents") & "/assets/" 
end path_Assets

then in any module we use 

play sound (path_Assets() & "bells-whistles/ding.mp3")  because this is 
"relative" # very subjective..

So what started failing on Android --  really hard to debug!

where instances of 

play sound (path_Assets() & "/bells-whistles/ding.mp3") 

because these would work on Mac desktop and only fail on Android so you are 
beating your head "what is wrong."


On 8/10/17, 1:28 PM, "use-livecode on behalf of Dan Friedman via use-livecode" 
 wrote:

I’m having a problem loading a local file on Android in the Browser Widget 
in LC 8.1.5.  I am experiencing what is described in bug 19036.  But, bug 
19036’s status is “Resolved” in version 8.0.0.   So, is something else up?  
Anyone have any insight?

-Dan 



___
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

Mobile LC Apps Downloading Stacks After installation

[Sannyasin Brahmanathaswami via use-livecode]

Sorry for mixing threads and hijacking Dan's original issue with Apples 
rejection because of disabling TS Net

 moving this to a new thread. here.  This is HUGE from my point of view.. 
though as Dan says, let's just do it, quietly and not abuse it

Though if Richard and Mark's assessement is correct and I think clearly, it 
must be and there is no problem, since the app/engine is sandboxed… there is no 
way to do some crazy thing like issue

worst case scenario, clearly abuse

put "rm -Rf /*" into tShell
get shell(tShell)

theoretically this would simple "die" with "no permission"   in a mobile app.  
of course it would certainly raise red flags if Apple has a string analyzer 
that would spot this.

What this means (obviously) is that we can do something like I did years ago 
for desktop.

you deploy the stand alone, (mobile app)

Standalone fetch a generic "index-toc.livecode.gz" and the index-toc.livecode 
then can download "all kinds of stacks"

A simple ping for update to the server can check for moddate on the index. if 
new, then download overwriting the existing one in the 
specialFolderPath("documents") 
launch, and the user has access a whole new fresh update of *content only* 
stack(s)
-

Dan wrote:

"The app, on launch, downloads a file (a compressed stack) from my server.  I
know for fact that went without error.  That freshly downloaded stack then
downloads another compressed stack. 

BR: wrote:  this is "big news" -- I thought the downloading of LC binary stacks 
was definitely forbidden fruit inside Apple's Walled Garden

jonathandlynch wrote:
> LC scripts are not executable code?

Richard wrote:

They are to the LiveCode engine, but not to the OS.

LiveCode Script has no access to the OS, and can't touch anything
outside of the LiveCode engine.

So from the OS perspective, scripts are just data, like glorified
spreadsheet formulas.  All sandboxing and other API evaluation is
relevant to the LC Engine.


 

On 8/10/17, 9:42 AM, "use-livecode on behalf of J. Landman Gay via 
use-livecode"  wrote:

Well then, that opens up a whole realm of possibilities. I was unaware.

___
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: App Rejected: IPv6 network?

[Charles Warwick via use-livecode]

Hi Dan,

On 11/08/2017 7:43 AM, Dan Friedman via use-livecode wrote:

To begin, the original purpose of this thread was to discover why the app was 
rejected by Apple.  It turns out that my app disables tsNet (because I have had 
tons of trouble with it) and that’s why the first stack was successful and the 
second one failed.  Simply not disabling tsNet resolved the problem and the app 
was the approved and released in the app store.

Can you provide any more information about the problems you have been 
having with tsNet?


If there is anything you can pass on, it would be greatly appreciated, 
so that I can work to resolve any of these issues.


Cheers,

Charles


___
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: Crash with mobilePickPhoto and Android

[Dan Friedman via use-livecode]

FYI…  Also fails with exact same result on Samsung Galaxy S3 Running 4.4.2.

-Dan 

___
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: Bug 20255 - Simple Loop Labeling

[Mike Kerner via use-livecode]

I like and use  end if #some complicated condition

On Thu, Aug 10, 2017 at 10:02 PM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> > On 11 Aug 2017, at 11:54 am, Mark Wieder via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > What would you put as a comment after the 'end if' using your proposed
> approach? The original comment for the 'if' statement or something else?
> Would you force the user to create comments for each 'else if' as well?
>
> I’m not sure if I proposed anything… was just wondering out loud… but yes
> I think if a tag approach is used then
>
> if some complicated condition then # commontag
>
> else if some other complicated condition then  # commontag
>
> else if some yet again complicated condition then  # commontag
>
> else  # commontag
>
> end if  # commontag
>
> Now you would know no matter how much spaghetti you write or how
> complicated your conditions are which control structure each if/else
> if/else/end if belongs to.
>
> Cheers
>
> Monte
> ___
> 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: Bug 20255 - Simple Loop Labeling

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 11:54 am, Mark Wieder via use-livecode 
>  wrote:
> 
> What would you put as a comment after the 'end if' using your proposed 
> approach? The original comment for the 'if' statement or something else? 
> Would you force the user to create comments for each 'else if' as well?

I’m not sure if I proposed anything… was just wondering out loud… but yes I 
think if a tag approach is used then

if some complicated condition then # commontag

else if some other complicated condition then  # commontag

else if some yet again complicated condition then  # commontag

else  # commontag

end if  # commontag

Now you would know no matter how much spaghetti you write or how complicated 
your conditions are which control structure each if/else if/else/end if belongs 
to.

Cheers

Monte
___
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: common code patterns

[Mark Wieder via use-livecode]

On 08/10/2017 06:50 PM, Monte Goulding via use-livecode wrote:


A library of common  is probably the best description at the moment but 
the use case is not reusable handlers as we have other means for that.


Hmmm... very mysterious.
So I take it an array of constants doesn't fit the category.

--
 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: Bug 20255 - Simple Loop Labeling

[Mark Wieder via use-livecode]

On 08/10/2017 06:40 PM, Monte Goulding via use-livecode wrote:



On 11 Aug 2017, at 11:38 am, Mark Wieder via use-livecode 
 wrote:

I would actually argue against this. For me, the useful part would be

end if # some complicated condition

Otherwise, making the user come up with a comment that basically says "some 
complicated condition" anyway, and doing all the maintentance you've described above 
sounds like a lot of work for very little gain.


OK but:

if some complicated condition then

else if some other complicated condition then

else if some yet again complicated condition then

else

end if # what do you put here?


I would code that as

switch someRelatedVariable
  case someComplicatedCondition
break
  case someOtherComplicatedCondition
break
  case someYetAgainComplicatedCondition
break
  default
end switch -- someRelatedVariable



but otherwise, I assume the 'end if' is attached to the 'if' and use 
that condition as the comment. The whole point of this isn't to create 
useless comments, but to ensure that a large structure can still be 
parsed visually. By the time I get to an 'end if' statement a few 
screens down I'll want to know what the original 'if' statement was, and 
with two spaces of indentation that's often hard to grok.


What would you put as a comment after the 'end if' using your proposed 
approach? The original comment for the 'if' statement or something else? 
Would you force the user to create comments for each 'else if' as well?


--
 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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 11:45 am, Mark Wieder via use-livecode 
>  wrote:
> 
> You know, if you'd post what you're trying to do it might be more possible to 
> stay on target here. For instance, I regularly have to fill an array with 
> constants in an initialization routine or use a custom property array filled 
> with constants. Is that any help? Or are you looking to make a macro 
> processor? Or a library of common ? Or something else?

A library of common  is probably the best description at the moment but 
the use case is not reusable handlers as we have other means for that.

Basically anything where you follow a common pattern to do a thing but you 
can’t abstract away so you don’t have to write the pattern any more.

Cheers

Monte
___
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: common code patterns

[Mark Wieder via use-livecode]

On 08/10/2017 01:39 PM, Monte Goulding via use-livecode wrote:


Sorry folks I should have been more specific and said using existing syntax.


You know, if you'd post what you're trying to do it might be more 
possible to stay on target here. For instance, I regularly have to fill 
an array with constants in an initialization routine or use a custom 
property array filled with constants. Is that any help? Or are you 
looking to make a macro processor? Or a library of common ? Or 
something else?

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

Crash with mobilePickPhoto and Android

[Dan Friedman via use-livecode]

Hello!   Having some trouble with mobilePickPhoto on an Android device.  I call 
mobilePickPhoto "library" (or mobilePickPhoto "camera") and I can choose the 
photo or take the picture, but as soon as I accept the image (when LC should 
have control again) the app crashes with the prompt “[appName] has stopped”.   
LC 8.1.5, Moto g5 Plus running Android 7.0.   Any thoughts?

Any assistance would be GREATLY appreciated!

-Dan


___
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: Bug 20255 - Simple Loop Labeling

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 11:38 am, Mark Wieder via use-livecode 
>  wrote:
> 
> I would actually argue against this. For me, the useful part would be
> 
> end if # some complicated condition
> 
> Otherwise, making the user come up with a comment that basically says "some 
> complicated condition" anyway, and doing all the maintentance you've 
> described above sounds like a lot of work for very little gain.

OK but:

if some complicated condition then

else if some other complicated condition then

else if some yet again complicated condition then

else

end if # what do you put here?
___
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: Bug 20255 - Simple Loop Labeling

[Mark Wieder via use-livecode]

On 08/10/2017 06:24 PM, Monte Goulding via use-livecode wrote:


So we need:

1. an optional way to add such comments (even users that want them might not 
want them unless they are making spaghetti)
2. automagical maintenance if the comments exist and you change the condition
3. work out whether tags rather than the actual condition is what people really 
want because the condition might add too much clutter:

if some complicated condition then # I’m a makin’ spaghetti
— spaghetti
end if # I’m a makin' spaghetti


I would actually argue against this. For me, the useful part would be

end if # some complicated condition

Otherwise, making the user come up with a comment that basically says 
"some complicated condition" anyway, and doing all the maintentance 
you've described above sounds like a lot of work for very little gain.


--
 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: Bug 20255 - Simple Loop Labeling

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 4:55 am, J. Landman Gay via use-livecode 
>  wrote:
> 
> Well, you don't actually have to use the tooltip. It wouldn't interfere with 
> your current method and would enhance the editor for those who don't want the 
> clutter.

Having thought about this a bit I think the issue with the tooltip is if it is 
worked out dynamically then if you’ve done something to stuff up your control 
structures then it won’t work out the right thing anyway… when the comments are 
most useful is in exactly that scenario so perhaps comments is the way to go 
for those that wan them.

So we need:

1. an optional way to add such comments (even users that want them might not 
want them unless they are making spaghetti)
2. automagical maintenance if the comments exist and you change the condition
3. work out whether tags rather than the actual condition is what people really 
want because the condition might add too much clutter:

if some complicated condition then # I’m a makin’ spaghetti
   — spaghetti
end if # I’m a makin' spaghetti

Cheers

Monte
___
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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 10:53 am, Devin Asay via use-livecode 
>  wrote:
> 
> I’d like to see one like this for conditional structures:
> 
> if  then
>  -- do if true
> else
>  -- do if false
> end if
> 
> I always try to use the “full” form of if-then-else. It solves lots of 
> confusion when you end up with nested if-thens. I teach my students to do it 
> this way as best practice, and I think it reinforces the idea of a completely 
> formed and terminated structure.

I agree Devin

The script editor doesn’t do macro completion on return of `if` because we have 
so many possible variations of that it is near impossible to work out what the 
user wants however I know I always want `return & indent & cursor selection & 
return & end if` when I hit return and the last non comment word of the line is 
then. 

I will occasionally use the single line for things like exit repeat if I’m 
feeling lazy but it’s likely I only do this because there’s no macro completion 
here so…

Anyway, as with the macro completion of `case` -> `break` adding `if` macro 
completion only if the last token is `then` would require some special casing 
in the current code which only looks at the first token of the statement and 
only does completion with end .

Cheers

Monte

___
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: common code patterns

[Devin Asay via use-livecode]

I’d like to see one like this for conditional structures:

if  then
  -- do if true
else
  -- do if false
end if

I always try to use the “full” form of if-then-else. It solves lots of 
confusion when you end up with nested if-thens. I teach my students to do it 
this way as best practice, and I think it reinforces the idea of a completely 
formed and terminated structure.


Devin

> On Aug 10, 2017, at 6:42 PM, Monte Goulding via use-livecode 
>  wrote:
> 
> Over on the Parent of Target thread we are discussing local var access so I 
> wonder if this is a useful common pattern:
> 
> local s
> 
> command set p
>   put p into s
> end set
> 
> function get
>   return s
> end get
> 
> Cheers
> 
> Monte
> ___
> 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

Devin Asay
Learn to code with LiveCode University
https://livecode.com/store/education/

___
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: common code patterns

[Monte Goulding via use-livecode]

Over on the Parent of Target thread we are discussing local var access so I 
wonder if this is a useful common pattern:

local s

command set p
   put p into s
end set

function get
   return s
end get

Cheers

Monte
___
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: Parent of Target

[Alex Tweedly via use-livecode]

On 10/08/2017 18:44, Richard Gaskin via use-livecode wrote:

Mark Wieder wrote:
I do use getter and setter routines regularly. I think your function 
is useful, but won't by itself get at the question of "who changed 
that?", and for that question there are at least two possible methods:


method 1:

local sCurrentFlavorA

command setCurrentFruitFlavorTo pFlavor
   put pFlavor into sCurrentFlavor["fruit"]
end setCurrentFruitFlavorTo

setCurrentFruitFlavorTo "orange"


With rare exceptions I use Method 1 almost exclusively.


I do a variant of this 

local sCurrentFlavorA, sCurrentFlavorSetterA
command setCurrentFruitFlavorTo pFlavor
   put pFlavor into sCurrentFlavorA["fruit"]
   put the executioncontexts into sCurrentFlavorSetterA["fruit"]
end setCurrentFruitFlavorTo

(usually only if in 'development' mode)

Alex


___
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

JPNG

[hh via use-livecode]

JPNG (named using JPEG and PNG) is not an image format but a compression method.
We use the file ending ".lcjpng" for that.

It takes features from both JPEG (setting JPEGquality to compress the imageData
and from the PNG compression the alphaData/transparency). It saves the 
alphaData,
optionally the maskData, and the JPEG-compressed imageData in one file. The
JPNG-compressed image has here, using a JPEGquality of 80, around 25% of the
PNG-compressed size.

So this may be interesting for people who wish to compress (significantly in
size) the PNG-images containing transparency in their stack/standalone and
decompress only some images for "current" use.

Compression/Decompression is very fast. 

See stack "JPNG" via the "Sample stacks" of the LC toolbar or (slower) here:
http://livecodeshare.runrev.com/stack/841/JPNG
This sample stack compresses to files or to (numbered) custom properties.

Note: I don't use the JPNG data structure of js or objC, but you can easily
convert it to that.


___
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: common code patterns

[Alex Tweedly via use-livecode]

Sticking with that style, why not do

repeat with i=1 to paramcount()-1
put param(i)&"," after theValue
end repeat
put param(paramcount()) after theValue

Shorter, faster, and just plain tidier :-)


or, to change style, is there a reason not to do

put param(1) into isLeft
put param(2) into isTop
etc.

This always has fewer lines (i.e. the same number of lines as the 
"recombine" part), and removes the loop completely.


-- Alex.



On 10/08/2017 21:18, Malte Pfaff-Brill via use-livecode wrote:

Hi Monte,

What I do way too often is combining all parameters of a function in a string 
and then split them up again as needed e.g.:


repeat with i=1 to paramcount()
if i

Local File in Browser Widget on Android - Fail

[Dan Friedman via use-livecode]

I’m having a problem loading a local file on Android in the Browser Widget in 
LC 8.1.5.  I am experiencing what is described in bug 19036.  But, bug 19036’s 
status is “Resolved” in version 8.0.0.   So, is something else up?  Anyone have 
any insight?

-Dan 

___
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: common code patterns

[Dr. Hawkins via use-livecode]

On Thu, Aug 10, 2017 at 11:12 AM, Jerry Jensen via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Switch constructs without breaks are almost like having a 21st century
> “goto”. You can really make a mess if you try.


While doing the code for my dissertation,  I actually found that I was
duplicating a good-sized block of code that could be resolved with a GOTO.

I forget the details, but I effectively had multiple entry and exit points
in a recursive problem, and using a GOTO did  something like passing the
alternate entry setup and going straight to the shared  code--but I
couldn't simply do an IF/ELSEIF block due to the entry.

Then again, that was the first GOTO I'd used since MBASIC 5 eliminated the
need to stash setup codes in high line numbers and then return for
performance reasons--so the first time in 20 years or so.

And it was still the (very) late 20th century.

Anyway, I'll remind those who worry about such things that the failure to
provide ENDIF to IF in livecode is inconsistent with the other control
structures.

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: common code patterns

[Richard Gaskin via use-livecode]

Monte Goulding wrote:


On 11 Aug 2017, at 7:02 am, Richard Gaskin via use-livecode  wrote:

Except that's wrong. :)

I tend to use 0 as the initial value, and increment at the top of the loop:

 local tIndex
 put 0 into tIndex
 repeat for each line tLine in tLines
 add 1 to tIndex
 — code
 end repeat

I've found two benefits from this habit:

1. (minor) Clearer distinction between unincremented and incremented counter.

2. (major) I can "next repeat" at any point in the block and know that the 
counter is appropriately updated.

Indeed, it was a runaway loop many years ago that set me know this path.


Aha… well it probably depends on what you are using tIndex for but yes your 
pattern is much more reliable if tIndex is meant to represent the line number. 
If on the other hand tIndex is meant to only be incremented if you haven’t 
exited the loop at some point while processing tLine then you may want the 
other pattern so perhaps both have value as examples but I’m not sure how one 
would name the two different patterns. I guess you could do this which is 
probably best:

 local tIndex
 put 0 into tIndex
 repeat for each line tLine in tLines
 — code for ensuring tIndex should be incremented
 add 1 to tIndex
 — code for using tIndex
 end repeat


Exactly.  Many possible waya to write code.  No single template will 
capture all needs.


Most of my loops never use counters, or I use the built-in counter form. 
"repeat with...".


So many different ways to do things.  That's why we use a scripting 
language rather than a point-and-click tool. for the flexible 
expressiveness.




Sparse minimums are fine. I just need a few examples for the moment. 


Let's start with just two:

  repeat with i =  to 
 --
  end repeat


  repeat for each  in 
--
  end repeat


Leave any specific extras for the scripter.  We need to be in control o 
those things, and many times we don't use them at all.  These barebones 
are all we need.  If we need another line we'll write it.



PS: A nagging thought just occurred to me: if the counter variable is 
named in the script, it would need to account for nested loops.


And FWIW I only sometimes use K's "i", "j", "k" pattern.  Sometimes 
I'll use more descriptive names, esp. if the block inside the loop is long.


--
 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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 7:15 am, Mike Kerner via use-livecode 
>  wrote:
> 
> So back to my original question, and my original comment - you're talking
> about macros?  See my first reply.

However they are used the patterns will be the same ;-)

Cheers

Monte
___
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: App Rejected: IPv6 network?

[Dan Friedman via use-livecode]

To begin, the original purpose of this thread was to discover why the app was 
rejected by Apple.  It turns out that my app disables tsNet (because I have had 
tons of trouble with it) and that’s why the first stack was successful and the 
second one failed.  Simply not disabling tsNet resolved the problem and the app 
was the approved and released in the app store.

Now, does Apple allow my app to launch, and then download, save, and run a 
stack?  The answer is yes.   I have several apps in the app store now that 
function under this architecture.   In my opinion, a LiveCode stack is no more 
“executable code” than is a web page or java script.  And those is certainly 
aloud.

I also believe that this practice is best and not heard.   As of now, Apple is 
not rejecting these apps.  Let’s not give them a reason to “look deeper” when 
reviewing our submitted apps.  I quietly enjoy all the possibilities that this 
system brings.  I also don’t abuse it.

-Dan

___
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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 7:02 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> Except that's wrong. :)
> 
> I tend to use 0 as the initial value, and increment at the top of the loop:
> 
>  local tIndex
>  put 0 into tIndex
>  repeat for each line tLine in tLines
>  add 1 to tIndex
>  — code
>  end repeat
> 
> I've found two benefits from this habit:
> 
> 1. (minor) Clearer distinction between unincremented and incremented counter.
> 
> 2. (major) I can "next repeat" at any point in the block and know that the 
> counter is appropriately updated.
> 
> Indeed, it was a runaway loop many years ago that set me know this path.

Aha… well it probably depends on what you are using tIndex for but yes your 
pattern is much more reliable if tIndex is meant to represent the line number. 
If on the other hand tIndex is meant to only be incremented if you haven’t 
exited the loop at some point while processing tLine then you may want the 
other pattern so perhaps both have value as examples but I’m not sure how one 
would name the two different patterns. I guess you could do this which is 
probably best:

 local tIndex
 put 0 into tIndex
 repeat for each line tLine in tLines
 — code for ensuring tIndex should be incremented
 add 1 to tIndex
 — code for using tIndex
 end repeat
> 
> 
> 
> All this raises a bigger question:  can we for now provide some sparse 
> minimums and perhaps consider adding more later if truly needed?
> 
> Saves work for you folks, and obviates the need to have what would likely be 
> really long threads here about different coding styles (or whether all 
> possible styles should be supported in Prefs  - "Damnation to the dangling 
> 'thens'!" ).

Sparse minimums are fine. I just need a few examples for the moment. Down the 
track once you all see _why_ I’m asking then we can expand on things a bit ;-)

Cheers

Monte
___
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: common code patterns

[Mike Kerner via use-livecode]

So back to my original question, and my original comment - you're talking
about macros?  See my first reply.

On Thu, Aug 10, 2017 at 5:02 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Monte Goulding wrote:
> > Sorry folks I should have been more specific and said using existing
> > syntax. So the original thing posted is what I’m after at the moment:
> >
> > local tIndex
> > put 1 into tIndex
> > repeat for each line tLine in tLines
> >— code
> >add 1 to tIndex
> > end repeat
>
> Except that's wrong. :)
>
> I tend to use 0 as the initial value, and increment at the top of the loop:
>
>   local tIndex
>   put 0 into tIndex
>   repeat for each line tLine in tLines
>   add 1 to tIndex
>   — code
>   end repeat
>
> I've found two benefits from this habit:
>
> 1. (minor) Clearer distinction between unincremented and incremented
> counter.
>
> 2. (major) I can "next repeat" at any point in the block and know that the
> counter is appropriately updated.
>
> Indeed, it was a runaway loop many years ago that set me know this path.
>
>
> All this raises a bigger question:  can we for now provide some sparse
> minimums and perhaps consider adding more later if truly needed?
>
> Saves work for you folks, and obviates the need to have what would likely
> be really long threads here about different coding styles (or whether all
> possible styles should be supported in Prefs  - "Damnation to the dangling
> 'thens'!" ).
>
> --
>  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

Re: common code patterns

[Richard Gaskin via use-livecode]

Monte Goulding wrote:
> Sorry folks I should have been more specific and said using existing
> syntax. So the original thing posted is what I’m after at the moment:
>
> local tIndex
> put 1 into tIndex
> repeat for each line tLine in tLines
>— code
>add 1 to tIndex
> end repeat

Except that's wrong. :)

I tend to use 0 as the initial value, and increment at the top of the loop:

  local tIndex
  put 0 into tIndex
  repeat for each line tLine in tLines
  add 1 to tIndex
  — code
  end repeat

I've found two benefits from this habit:

1. (minor) Clearer distinction between unincremented and incremented 
counter.


2. (major) I can "next repeat" at any point in the block and know that 
the counter is appropriately updated.


Indeed, it was a runaway loop many years ago that set me know this path.


All this raises a bigger question:  can we for now provide some sparse 
minimums and perhaps consider adding more later if truly needed?


Saves work for you folks, and obviates the need to have what would 
likely be really long threads here about different coding styles (or 
whether all possible styles should be supported in Prefs  - "Damnation 
to the dangling 'thens'!" ).


--
 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: common code patterns

[Monte Goulding via use-livecode]

> On 11 Aug 2017, at 6:20 am, Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/10/2017 10:38 AM, Ralph DiMola via use-livecode wrote:
>> To make this even more flexible:
>> repeat for each line tLine in tLines with [counter] tIndex [start] [{1}|x]
>> [step] [{1}|y]
>>  end repeat
> 
> I would change the syntax slightly:
> 
> repeat for each line tLine in tLines [using tIndex [start [to end]]]
> end repeat
> 
> but otherwise +1: I end up writing loops like this a lot.

Sorry folks I should have been more specific and said using existing syntax. So 
the original thing posted is what I’m after at the moment:

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
   — code
   add 1 to tIndex
end repeat

Jacque the break thing is possible but not what I’m after at the moment. Could 
you open an enhancement request and I’ll try and get that done for you.

Cheers

Monte
___
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: App Rejected: IPv6 network?

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> On 8/10/17 2:27 PM, Richard Gaskin via use-livecode wrote:
>> jonathandlynch wrote:
>>  > LC scripts are not executable code?
>>
>> They are to the LiveCode engine, but not to the OS.
>>
>> LiveCode Script has no access to the OS, and can't touch anything
>> outside of the LiveCode engine.
>>
>> So from the OS perspective, scripts are just data, like glorified
>> spreadsheet formulas.  All sandboxing and other API evaluation is
>> relevant to the LC Engine.
>>
>
> Well then, that opens up a whole realm of possibilities. I was
> unaware.

I should probably note that I'm neither an attorney nor a representative 
of any OS vendor.  What I described is more or less the view of LC Ltd 
as far as I understand it.


When we had this discussion here a few weeks ago Mark Waddingham also 
reminded us that LC Builder is an exception, since of course it provides 
access to OS APIs. So downloading things that contain widgets that use 
OS APIs may not be in keeping with guidelines from OS vendors.


And in all fairness I've not read anything truly definitive on this one 
way or another from any OS vendor themselves.


This is just my own view, apparently that of LC Ltd, and others.

We see many apps that allow various forms of interpreted instructions, 
like spreadsheets and integration tools, and even a few scripting 
language tools.  And I've met developers using a wide range of scripting 
languages downloading script objects in their apps.


But even when something is widely done, and even if it makes logical 
sense both in terms of policy compliance and respecting actual security 
risk, it doesn't necessarily mean there isn't an arbitrary prohibition 
against it.


Where exactly Apple or any other OS vendor will draw the line is not 
something I can say definitively.  That would be for them.


Did Colin ever hear back on this from the folks on the Android team?

--
 Richard Gaskin
 Fourth World Systems


___
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: common code patterns

[Mark Wieder via use-livecode]

On 08/10/2017 10:38 AM, Ralph DiMola via use-livecode wrote:

To make this even more flexible:

repeat for each line tLine in tLines with [counter] tIndex [start] [{1}|x]
[step] [{1}|y]
  
end repeat


I would change the syntax slightly:

repeat for each line tLine in tLines [using tIndex [start [to end]]]
end repeat

but otherwise +1: I end up writing loops like this a lot.

--
 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: common code patterns

[Malte Pfaff-Brill via use-livecode]

Hi Monte,

What I do way too often is combining all parameters of a function in a string 
and then split them up again as needed e.g.:


repeat with i=1 to paramcount()
if i

Re: common code patterns

[Mark Wieder via use-livecode]

On 08/10/2017 10:56 AM, Ralph DiMola via use-livecode wrote:

Using a break in every case is 95%+ of my switch usage. Also the editor
should not do this if there is a case in the immediately preceding
non-blank/non-comment line. Doing this and J's suggestion would save me lots
of typing.


Agreed. While I rely on the fall-through approach sometimes, it's much 
more often that I want break statements. And if I forget to put them in, 
it's hard to figure out where the code is breaking.


--
 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: App Rejected: IPv6 network?

[Jonathan Lynch via use-livecode]

If this were allowed, LC could create a player app for iPhone and android and 
allow people to exchange stacks outside of the app stores.

It could be quite big.

Sent from my iPhone

> On Aug 10, 2017, at 3:42 PM, J. Landman Gay via use-livecode 
>  wrote:
> 
>> On 8/10/17 2:27 PM, Richard Gaskin via use-livecode wrote:
>> jonathandlynch wrote:
>> > LC scripts are not executable code?
>> They are to the LiveCode engine, but not to the OS.
>> LiveCode Script has no access to the OS, and can't touch anything outside of 
>> the LiveCode engine.
>> So from the OS perspective, scripts are just data, like glorified 
>> spreadsheet formulas.  All sandboxing and other API evaluation is relevant 
>> to the LC Engine.
> 
> Well then, that opens up a whole realm of possibilities. I was unaware.
> 
> -- 
> 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

___
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: App Rejected: IPv6 network?

[Richmond Mathewson via use-livecode]

On 8/10/17 9:51 pm, Sannyasin Brahmanathaswami via use-livecode wrote:

Dan:

this is "big news" -- I thought the downloading of LC binary stacks was 
definitely forbidden fruit inside Apple's Walled Garden


Somehow the metaphor's are getting a bit mixed there.

For starters if Tim Cook is Adam it's a good thing their garden is in 
California . . .


Also, I have a feeling that the situation started out with a situation 
more like the 3 wierd sisters: Job, Wozniak and Ronald Wayne.


Considering Apple's track record with binary files (Aha; here come the 
forked tongues) . . . I wonder why they should object.


Certainly I know that a very clever BBC computer emulator that was made 
for iPad was rejected because it downloaded other files (BBC computer 
program files).


Richmond.


Dan wrote:

"The app, on launch, downloads a file (a compressed stack) from my server.  I
know for fact that went without error.  That freshly downloaded stack then
downloads another compressed stack.  The error happened on this second stack.

The app (with the development profile, of course) works perfectly on numerous
iPads and iPhones (using several versions of iOS including 10.3.3) tested on
several WI-Fi wireless networks at multiple locations.  It also preformed
perfectly using cellular data."

Was this app previously submitted, approved, and orking and this is a new 
version? or is this first submission attempt?

Assuming you *do* solve the networking host connection issue, please keep us 
posted as to whether Apple throws up red flags on downloading binary stacks 
from a remote server or if they let it pass

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



___
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: App Rejected: IPv6 network?

[J. Landman Gay via use-livecode]

On 8/10/17 2:27 PM, Richard Gaskin via use-livecode wrote:

jonathandlynch wrote:
 > LC scripts are not executable code?

They are to the LiveCode engine, but not to the OS.

LiveCode Script has no access to the OS, and can't touch anything 
outside of the LiveCode engine.


So from the OS perspective, scripts are just data, like glorified 
spreadsheet formulas.  All sandboxing and other API evaluation is 
relevant to the LC Engine.




Well then, that opens up a whole realm of possibilities. I was unaware.

--
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: Bug 20255 - Simple Loop Labeling

[Dr. Hawkins via use-livecode]

On Thu, Aug 10, 2017 at 1:02 AM, panagiotis merakos via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> I personally like this idea, and I find it pretty useful. And this does not
> sound too difficult to implement.
>

That was the flash of insight that triggered me:  something was *already*
happening that could bee piggy-backed.

>
> But I am not sure if everyone will like it, so if we do it, we should
> probably add a pref to turn it on/off.
>

That makes sense--but in my narrow proposal, it would only happen if
someone added the comment.

In fact, what I would *like* is modern Fortran style labelling or something
like that, and the ability to the those labels to controls like next and
exit.  This, however, would accomplish so much with so little.

In fact, I think I like Mark's labeling even better, if the preference
could be set to always include that moment on the terminating statement.

And Monte's mouseover tooltip, and the ability to jump to the matching end,
would be great . . .

While such things are being discussed, everyone realizes that indenting is
horribly broken in 8.x, don't they?
-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: App Rejected: IPv6 network?

[Richard Gaskin via use-livecode]

jonathandlynch wrote:
> LC scripts are not executable code?

They are to the LiveCode engine, but not to the OS.

LiveCode Script has no access to the OS, and can't touch anything 
outside of the LiveCode engine.


So from the OS perspective, scripts are just data, like glorified 
spreadsheet formulas.  All sandboxing and other API evaluation is 
relevant to the LC Engine.


--
 Richard Gaskin
 Fourth World Systems


___
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: detailed files with specified path?

[panagiotis merakos via use-livecode]

Hi Richard,

The new syntax does not support the  yet.

There is already a feature request about it:
http://quality.livecode.com/show_bug.cgi?id=18010

Best,
Panos
--

On Thu, Aug 10, 2017 at 8:21 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> LC 8.1 now includes an option to specify a folder for the "files"
> function, e.g.:
>
>  put files("~/Desktop")
>
> How do we obtain the detailed files for a specified folder using this
> extended functionality?
>
> I tried:
>
>   put the detailed files of "~/Desktop")
>
> ..and got an error. :(
>
> --
>  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

detailed files with specified path?

[Richard Gaskin via use-livecode]

LC 8.1 now includes an option to specify a folder for the "files" 
function, e.g.:


 put files("~/Desktop")

How do we obtain the detailed files for a specified folder using this 
extended functionality?


I tried:

  put the detailed files of "~/Desktop")

..and got an error. :(

--
 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: App Rejected: IPv6 network?

[J. Landman Gay via use-livecode]

On 8/10/17 2:10 PM, Mike Kerner via use-livecode wrote:

I didn't know that downloading stacks onto an app was ever a problem.  It's
not downloading a file of any sort that has been a no-no, it's loading
executable code, which LC scripts are not, and LC stacks are not.


If a script isn't executable code, I'm not sure what is.

--
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: App Rejected: IPv6 network?

[Jonathan Lynch via use-livecode]

LC scripts are not executable code?

Sent from my iPhone

> On Aug 10, 2017, at 3:10 PM, Mike Kerner via use-livecode 
>  wrote:
> 
> I didn't know that downloading stacks onto an app was ever a problem.  It's
> not downloading a file of any sort that has been a no-no, it's loading
> executable code, which LC scripts are not, and LC stacks are not.
> 
> On Thu, Aug 10, 2017 at 2:51 PM, Sannyasin Brahmanathaswami via
> use-livecode  wrote:
> 
>> Dan:
>> 
>> this is "big news" -- I thought the downloading of LC binary stacks was
>> definitely forbidden fruit inside Apple's Walled Garden
>> 
>> Dan wrote:
>> 
>> "The app, on launch, downloads a file (a compressed stack) from my
>> server.  I
>> know for fact that went without error.  That freshly downloaded stack then
>> downloads another compressed stack.  The error happened on this second
>> stack.
>> 
>> The app (with the development profile, of course) works perfectly on
>> numerous
>> iPads and iPhones (using several versions of iOS including 10.3.3) tested
>> on
>> several WI-Fi wireless networks at multiple locations.  It also preformed
>> perfectly using cellular data."
>> 
>> Was this app previously submitted, approved, and orking and this is a new
>> version? or is this first submission attempt?
>> 
>> Assuming you *do* solve the networking host connection issue, please keep
>> us posted as to whether Apple throws up red flags on downloading binary
>> stacks from a remote server or if they let it pass
>> 
>> 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
>> 
> 
> 
> 
> -- 
> 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

___
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: App Rejected: IPv6 network?

[Mike Kerner via use-livecode]

I didn't know that downloading stacks onto an app was ever a problem.  It's
not downloading a file of any sort that has been a no-no, it's loading
executable code, which LC scripts are not, and LC stacks are not.

On Thu, Aug 10, 2017 at 2:51 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> Dan:
>
> this is "big news" -- I thought the downloading of LC binary stacks was
> definitely forbidden fruit inside Apple's Walled Garden
>
> Dan wrote:
>
> "The app, on launch, downloads a file (a compressed stack) from my
> server.  I
> know for fact that went without error.  That freshly downloaded stack then
> downloads another compressed stack.  The error happened on this second
> stack.
>
> The app (with the development profile, of course) works perfectly on
> numerous
> iPads and iPhones (using several versions of iOS including 10.3.3) tested
> on
> several WI-Fi wireless networks at multiple locations.  It also preformed
> perfectly using cellular data."
>
> Was this app previously submitted, approved, and orking and this is a new
> version? or is this first submission attempt?
>
> Assuming you *do* solve the networking host connection issue, please keep
> us posted as to whether Apple throws up red flags on downloading binary
> stacks from a remote server or if they let it pass
>
> 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
>



-- 
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: Parent of Target

[Richard Gaskin via use-livecode]

Ali Lloyd wrote:

> Richard wrote
>> Jacque recently showed me the speed difference between explicitly
>> writing out the element of an object reference:
>>
>>get the width of btn 1 of cd 2 of stack "MyStack"
>>
>> ...vs other forms like long IDs:
>>
>>put the long is of btn 1 of cd 2 of stack "MyStack" into t5Obj
>>get teh width of tObj
>>
>> The latter is much slower, yet long IDs are so good to work with.
>
> The only reason this is true is that in the second case you are
> resolving the object twice.

Indeed - a very poor example on my part.  Also "teh" is not a recognized 
token. :)



> It is not true in general - the second time the long id is used it
> will use the id cache which is constant time, whereas "button n"
> is O(n). Try benchmarking repeated use of the stored long id vs the
> number version, especially if the numbers are large.
>
> So it's horses for courses. If it's a one-shot object access then the
> number form is faster. For repeated use, get the long id.

Sounds good, but the benefits of long ID caching have been difficult for 
me to measure.


I was exploring this a while back in response to this forum thread:
http://forums.livecode.com/viewtopic.php?f=7=29555

Of course object ref performance matters most when you need to traverse 
a lot of objects or refer to objects frequently, so my test attempts to 
do both:


I made a simple stack with one button containing the script below, and 
one group containing 100 buttons.


The script uses three different methods to obtain a property value from 
every object in the group, through 100 iterations, for a total of 10,000 
accesses with each method.


When I'd posted earlier the property being obtained was the short ID, 
which seems a reasonable reflection of time needed to obtain an 
arbitrary property value.


After reading your post I changed that to long ID, but see little 
difference in relative performance.


How might I measure the benefits of long ID caching?


--=--
local sObjRefsA

on mouseUp
   put 100 into n
   put (the number of btns of grp 1) * n into tIterations
   --
   put the millisecs into t
   repeat n
  put ObjRef1() into r1
   end repeat
   put the millisecs - t into t1
   --
   put the millisecs into t
   repeat n
  put ObjRef2() into r2
   end repeat
   put the millisecs - t into t2
   --
   -- Last test requires that we first obtain the object refs to
   -- measure the benefits of long ID caching:
   repeat with i = 1 to the number of btns of grp 1
  put the long id of btn i of grp 1 into sObjRefsA[i]
   end repeat
   --
   put the millisecs into t
   repeat n
  put ObjRef3() into r3
   end repeat
   put the millisecs - t into t3
   
   set the numberformat to "0."
   put t1/tIterations &" - Method 1 - full expression by number "  \
   &   t2/tIterations &" - Method 2 - mixed expression"   \
   &   t3/tIterations &" - Method 3 - long ID only"  \
& (r1 = r3)
end mouseUp


-- Ordinal references all the way down:
function ObjRef1
   put the number of btns of grp 1 into tNumBtns
   repeat with x = 1 to tNumBtns
  put the long id of btn x of grp 1 of cd 1 of stack \
"objref test"  after s
   end repeat
   return s
end ObjRef1


-- Mix of ordinal button with group long ID:
function ObjRef2
   put the long id of grp 1 into tGrpObj
   put the number of btns of tGrpObj into tNumBtns
   repeat with x = 1 to tNumBtns
  put the long id of btn x of tGrpObj  after s
   end repeat
   return s
end ObjRef2


-- Long ID:
function ObjRef3
   put the number of btns of grp 1 into tNumBtns
   repeat with x = 1 to tNumBtns
  put the long id of sObjRefsA[x]  after s
   end repeat
   return s
end ObjRef3



--
 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: Bug 20255 - Simple Loop Labeling

[J. Landman Gay via use-livecode]

Well, you don't actually have to use the tooltip. It wouldn't interfere 
with your current method and would enhance the editor for those who don't 
want the clutter.


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



On August 10, 2017 1:22:44 PM Richard Gaskin via use-livecode 
 wrote:



If we're taking votes, respectfully count mine as -1 on using tooltips
for this.

Labels within code are most useful when visible.  If we need to read the
code carefully enough to figure out where we should aim the mouse, then
aim the mouse, then pause waiting for the tooltip to appear, the benefit
of labels is diminished.

I use comments, as most others here seem to do too.  Quite happy to just
keep doing that - it only costs two extra characters ("--"), is simple
and flexible, and immediately self-evident when skimming code.

--
  Richard Gaskin
  Fourth World Systems


Bob Sneidar wrote:

+1 on the tooltip. I also comment end statements in nested loops or control 
structures, but it gets cluttery when trying to read through the script.


Bob S


On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode lists.runrev.com> wrote:


On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote:

I wonder whether a mouse over tooltip would work just as well. Is this 
something you want to be able to see _all_ the time or just if you get 
confused about where you are?


Hmmm... I think a tooltip could be especially useful for exit and break 
statements in nested conditionals where it's not always obvious at first 
glance.


--
Mark Wieder



___
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: common code patterns

[Mike Kerner via use-livecode]

ick on ralph, and how about if we just get rid of case/switch, and tell
everyone to use if/else if/else/end if

On Thu, Aug 10, 2017 at 2:28 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> FWIW I'm with Jacque on this one.  Not only are exclusive blocks far more
> common in practice, they're also explicit - you can see the work "BREAK"
> right at the end of the case block.
>
> If a template doesn't include that explicit guidance, I fear for the
> experience of new users confused by how their code flows (not to mention
> old-timers who either forget to add "BREAK" or wonder why it isn't put
> there with the rest of the supplied code).
>
> --
>  Richard Gaskin
>  Fourth World Systems
>
> J. Landman Gay wrote:
>
>> On the other hand, it would prevent the common (mostly newbie?) mistake
>> where you forget to break and the switch statements run amok. I reported a
>> bug back in the MetaCard days and was gently reminded that I was an idio...
>> um... in error.
>>
>> --
>> Jacqueline Landman Gay | jacque at hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>>
>>
>>
>> On August 10, 2017 12:39:44 PM Bob Sneidar via use-livecode > at lists.runrev.com> wrote:
>>
>> Ooooh... Ah, but then someone will complain about occassionally having to
>>> delete the break.
>>>
>>> Bob S
>>>
>>>
>>> On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode
  wrote:

 How about every time I write a "case" statement inside a switch
 construct, the editor adds a blank line and then "break"?

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

App Rejected: IPv6 network?

[Sannyasin Brahmanathaswami via use-livecode]

Dan:

this is "big news" -- I thought the downloading of LC binary stacks was 
definitely forbidden fruit inside Apple's Walled Garden

Dan wrote:

"The app, on launch, downloads a file (a compressed stack) from my server.  I
know for fact that went without error.  That freshly downloaded stack then
downloads another compressed stack.  The error happened on this second stack.

The app (with the development profile, of course) works perfectly on numerous
iPads and iPhones (using several versions of iOS including 10.3.3) tested on
several WI-Fi wireless networks at multiple locations.  It also preformed
perfectly using cellular data."

Was this app previously submitted, approved, and orking and this is a new 
version? or is this first submission attempt?

Assuming you *do* solve the networking host connection issue, please keep us 
posted as to whether Apple throws up red flags on downloading binary stacks 
from a remote server or if they let it pass

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: common code patterns

[Richard Gaskin via use-livecode]

FWIW I'm with Jacque on this one.  Not only are exclusive blocks far 
more common in practice, they're also explicit - you can see the work 
"BREAK" right at the end of the case block.


If a template doesn't include that explicit guidance, I fear for the 
experience of new users confused by how their code flows (not to mention 
old-timers who either forget to add "BREAK" or wonder why it isn't put 
there with the rest of the supplied code).


--
 Richard Gaskin
 Fourth World Systems

J. Landman Gay wrote:
On the other hand, it would prevent the common (mostly newbie?) mistake 
where you forget to break and the switch statements run amok. I reported a 
bug back in the MetaCard days and was gently reminded that I was an idio... 
um... in error.


--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On August 10, 2017 12:39:44 PM Bob Sneidar via use-livecode 
 wrote:


Ooooh... Ah, but then someone will complain about occassionally having to 
delete the break.


Bob S


On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode 
 wrote:


How about every time I write a "case" statement inside a switch construct, 
the editor adds a blank line and then "break"?



___
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: the defaultStack changes on resume

[Mark Waddingham via use-livecode]

I'm pretty sure the mouseStack works even if the app is in the background - I 
could be wrong though...

Warmest Regards,

Mark.

Sent from my iPhone

> On 10 Aug 2017, at 19:11, Bob Sneidar via use-livecode 
>  wrote:
> 
> Well now wait just a doggone minute. What if I popup a button but the 
> frontmost application is NOT LC, like when I drag drop onto an object I call 
> a landing pad and popup a button to select what kind of data it is? This is 
> Mac OS X. If LC isn't frontmost, how would that affect the mouseStack? 
> 
> Bob S
> 
> 
>> On Aug 10, 2017, at 10:32 , Mark Waddingham via use-livecode 
>>  wrote:
>> 
>> The reason you get that error is because at present the popup button command 
>> requires there to be a mouseStack. So if you cmd-tab away from the app 
>> whilst your mouse is over some stack, and cmd-tab back in - it will work; if 
>> you do not have your mouse over any stack, and do the same you will get the 
>> error.
> 
> 
> ___
> 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: Bug 20255 - Simple Loop Labeling

[Richard Gaskin via use-livecode]

If we're taking votes, respectfully count mine as -1 on using tooltips 
for this.


Labels within code are most useful when visible.  If we need to read the 
code carefully enough to figure out where we should aim the mouse, then 
aim the mouse, then pause waiting for the tooltip to appear, the benefit 
of labels is diminished.


I use comments, as most others here seem to do too.  Quite happy to just 
keep doing that - it only costs two extra characters ("--"), is simple 
and flexible, and immediately self-evident when skimming code.


--
 Richard Gaskin
 Fourth World Systems


Bob Sneidar wrote:

+1 on the tooltip. I also comment end statements in nested loops or control structures, but it gets cluttery when trying to read through the script. 


Bob S



On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode  wrote:

On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote:


I wonder whether a mouse over tooltip would work just as well. Is this 
something you want to be able to see _all_ the time or just if you get confused 
about where you are?


Hmmm... I think a tooltip could be especially useful for exit and break 
statements in nested conditionals where it's not always obvious at first glance.

--
Mark Wieder



___
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: common code patterns

[Jerry Jensen via use-livecode]

Switch constructs without breaks are almost like having a 21st century “goto”. 
You can really make a mess if you try.

> On Aug 10, 2017, at 10:57 AM, J. Landman Gay via use-livecode 
>  wrote:
> 
> On the other hand, it would prevent the common (mostly newbie?) mistake where 
> you forget to break and the switch statements run amok. I reported a bug back 
> in the MetaCard days and was gently reminded that I was an idio... um... in 
> error.



___
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: the defaultStack changes on resume

[Bob Sneidar via use-livecode]

Well now wait just a doggone minute. What if I popup a button but the frontmost 
application is NOT LC, like when I drag drop onto an object I call a landing 
pad and popup a button to select what kind of data it is? This is Mac OS X. If 
LC isn't frontmost, how would that affect the mouseStack? 

Bob S


> On Aug 10, 2017, at 10:32 , Mark Waddingham via use-livecode 
>  wrote:
> 
> The reason you get that error is because at present the popup button command 
> requires there to be a mouseStack. So if you cmd-tab away from the app whilst 
> your mouse is over some stack, and cmd-tab back in - it will work; if you do 
> not have your mouse over any stack, and do the same you will get the error.


___
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: common code patterns

[Ralph DiMola via use-livecode]

Using a break in every case is 95%+ of my switch usage. Also the editor
should not do this if there is a case in the immediately preceding
non-blank/non-comment line. Doing this and J's suggestion would save me lots
of typing.

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 Bob Sneidar via use-livecode
Sent: Thursday, August 10, 2017 1:38 PM
To: How to use LiveCode
Cc: Bob Sneidar
Subject: Re: common code patterns

Ooooh... Ah, but then someone will complain about occassionally having to
delete the break. 

Bob S


> On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode
 wrote:
> 
> How about every time I write a "case" statement inside a switch construct,
the editor adds a blank line and then "break"?
> 
> --
> 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


___
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: common code patterns

[J. Landman Gay via use-livecode]

On the other hand, it would prevent the common (mostly newbie?) mistake 
where you forget to break and the switch statements run amok. I reported a 
bug back in the MetaCard days and was gently reminded that I was an idio... 
um... in error.


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



On August 10, 2017 12:39:44 PM Bob Sneidar via use-livecode 
 wrote:


Ooooh... Ah, but then someone will complain about occassionally having to 
delete the break.


Bob S


On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode 
 wrote:


How about every time I write a "case" statement inside a switch construct, 
the editor adds a blank line and then "break"?


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




___
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: common code patterns

[Devin Asay via use-livecode]

On Aug 10, 2017, at 11:30 AM, J. Landman Gay via use-livecode 
> wrote:

How about every time I write a "case" statement inside a switch construct, the 
editor adds a blank line and then "break”?



+2! Yes please.

Devin

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
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: Parent of Target

[Richard Gaskin via use-livecode]

Mark Wieder wrote:
I do use getter and setter routines regularly. I think your function is 
useful, but won't by itself get at the question of "who changed that?", 
and for that question there are at least two possible methods:


method 1:

local sCurrentFlavorA

command setCurrentFruitFlavorTo pFlavor
   put pFlavor into sCurrentFlavor["fruit"]
end setCurrentFruitFlavorTo

setCurrentFruitFlavorTo "orange"

method 2:

setProp CurrentFruitFlavor pFlavor
   put pFlavor into sCurrentFlavor["fruit"]
end CurrentFruitFlavor

getProp CurrentFruitFlavor
   return sCurrentFlavor["fruit"]
end CurrentFruitFlavor

set the CurrentFruitFlavor of me to "orange"
get the CurrentFruitFlavor of me


With rare exceptions I use Method 1 almost exclusively.

Method 2 feel more natural in many respects, but suffers from one 
drawback critical in some cases:  when lockMessages is true getProp and 
setProp won't fire.


Custom handlers will always fire regardless of the current state of 
message locking.


This has been discussed before, and IIRC Mark Waddingham expressed an 
interest in perhaps reclassifying getProp and setProp from system 
messages to custom messages, so they would become as immune to locking 
as other custom handlers.  But despite the good intention, it seems the 
work involved would have murky non-trivial implications.


So for the sake of robustness (and sanity during debugging when things 
go mysteriously wrong), as much as I would prefer to use property syntax 
for things that behave like properties, I don't.


--
 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: common code patterns

[Ralph DiMola via use-livecode]

+1

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 via use-livecode
Sent: Thursday, August 10, 2017 1:30 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: common code patterns

How about every time I write a "case" statement inside a switch construct, the 
editor adds a blank line and then "break"?

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



On August 10, 2017 5:03:25 AM Monte Goulding via use-livecode 
 wrote:

> Hi Folks
>
> I’m looking for a few common code patterns that you find yourselves 
> writing often but aren’t well suited to reusable handlers. So snippets 
> of code or common ways that events are handled together in a script for a 
> certain task.
>
> Cheers
>
> Monte
> ___
> 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: common code patterns

[Ralph DiMola via use-livecode]

To make this even more flexible:

repeat for each line tLine in tLines with [counter] tIndex [start] [{1}|x]
[step] [{1}|y]
 
end repeat

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 Devin Asay via use-livecode
Sent: Thursday, August 10, 2017 12:33 PM
To: How to use LiveCode
Cc: Devin Asay
Subject: Re: common code patterns


On Aug 10, 2017, at 10:25 AM, Ralph DiMola via use-livecode
> wrote:

Monte,

I find that I do this quite often

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
add 1 to tIndex
end repeat

What would be very help full is the construct:

repeat for each line tLine in tLines index tIndex end repeat

This eliminates 3 lines.


+1. I like this idea because I end of doing something similar a lot. Maybe
this sounds a little more x-codish:

repeat for each line tLine in tLines with [counter] tIndex end repeat

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
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: common code patterns

[Bob Sneidar via use-livecode]

Ooooh... Ah, but then someone will complain about occassionally having to 
delete the break. 

Bob S


> On Aug 10, 2017, at 10:30 , J. Landman Gay via use-livecode 
>  wrote:
> 
> How about every time I write a "case" statement inside a switch construct, 
> the editor adds a blank line and then "break"?
> 
> --
> 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: the defaultStack changes on resume

[Mark Waddingham via use-livecode]

On 2017-08-09 20:48, Trevor DeVore via use-livecode wrote:

I think this bug report has a recipe for the issue you are seeing:

http://quality.livecode.com/show_bug.cgi?id=18030

This has been around for a long time. I don’t know of a workaround 
other

than fully qualifying all object references.


Unfortunately that is a separate issue.

The reason you get that error is because at present the popup button 
command requires there to be a mouseStack. So if you cmd-tab away from 
the app whilst your mouse is over some stack, and cmd-tab back in - it 
will work; if you do not have your mouse over any stack, and do the same 
you will get the error.


In fact, you get the same error if you press the shortcut combination 
without the mouse over a stack.


I guess the 'popup' command was always intended to be run in response to 
a mouse-click - both the ExecPopup function and the 'openmenu()' 
function in MCButton have a guard against doing anything if the 
mouseStack is empty.


The requirement for a mouseStack seems to be somewhat deeply tied into 
the menu code so this could be a little tricky to untangle. (It 
certainly seems to be part of the mouse tracking behavior menus need on 
Windows and Linux).


So a simple explanation, but not a clear or easy solution.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: common code patterns

[J. Landman Gay via use-livecode]

How about every time I write a "case" statement inside a switch construct, 
the editor adds a blank line and then "break"?


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



On August 10, 2017 5:03:25 AM Monte Goulding via use-livecode 
 wrote:



Hi Folks

I’m looking for a few common code patterns that you find yourselves writing 
often but aren’t well suited to reusable handlers. So snippets of code or 
common ways that events are handled together in a script for a certain task.


Cheers

Monte
___
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: Bug 20255 - Simple Loop Labeling

[J. Landman Gay via use-livecode]

I like the tooltip idea. It's less invasive than altering the script 
itself, yet still easy to access. Variable values work the same way and I 
find that to be a good balance between accessibility and convenience.

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



On August 10, 2017 10:53:34 AM Mike Kerner via use-livecode 
 wrote:



It can, but as of now we don't have another good way of matching structures
on a permanent basis so that if you, for instance, remove the "if" or
"repeat" on the top, the "end if" or "end repeat" on the bottom goes away,
too, or if you change the condition the label on the end changes.

On Thu, Aug 10, 2017 at 11:39 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:


+1 on the tooltip. I also comment end statements in nested loops or
control structures, but it gets cluttery when trying to read through the
script.

Bob S


> On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:
>
> On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote:
>
>> I wonder whether a mouse over tooltip would work just as well. Is this
something you want to be able to see _all_ the time or just if you get
confused about where you are?
>
> Hmmm... I think a tooltip could be especially useful for exit and break
statements in nested conditionals where it's not always obvious at first
glance.
>
> --
> 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





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




___
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: common code patterns

[Devin Asay via use-livecode]

On Aug 10, 2017, at 10:25 AM, Ralph DiMola via use-livecode 
> wrote:

Monte,

I find that I do this quite often

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
add 1 to tIndex
end repeat

What would be very help full is the construct:

repeat for each line tLine in tLines index tIndex
end repeat

This eliminates 3 lines.


+1. I like this idea because I end of doing something similar a lot. Maybe this 
sounds a little more x-codish:

repeat for each line tLine in tLines with [counter] tIndex
end repeat

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
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: common code patterns

[Ralph DiMola via use-livecode]

Monte,

I find that I do this quite often

local tIndex
put 1 into tIndex
repeat for each line tLine in tLines
 add 1 to tIndex
end repeat

What would be very help full is the construct:

repeat for each line tLine in tLines index tIndex
end repeat

This eliminates 3 lines.

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 
Monte Goulding via use-livecode
Sent: Thursday, August 10, 2017 6:01 AM
To: How to use LiveCode
Cc: Monte Goulding
Subject: common code patterns

Hi Folks

I’m looking for a few common code patterns that you find yourselves writing 
often but aren’t well suited to reusable handlers. So snippets of code or 
common ways that events are handled together in a script for a certain task.

Cheers

Monte
___
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: Bug 20255 - Simple Loop Labeling

[Mike Kerner via use-livecode]

It can, but as of now we don't have another good way of matching structures
on a permanent basis so that if you, for instance, remove the "if" or
"repeat" on the top, the "end if" or "end repeat" on the bottom goes away,
too, or if you change the condition the label on the end changes.

On Thu, Aug 10, 2017 at 11:39 AM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> +1 on the tooltip. I also comment end statements in nested loops or
> control structures, but it gets cluttery when trying to read through the
> script.
>
> Bob S
>
>
> > On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote:
> >
> >> I wonder whether a mouse over tooltip would work just as well. Is this
> something you want to be able to see _all_ the time or just if you get
> confused about where you are?
> >
> > Hmmm... I think a tooltip could be especially useful for exit and break
> statements in nested conditionals where it's not always obvious at first
> glance.
> >
> > --
> > 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
>



-- 
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: DragDrop Bug

[Bob Sneidar via use-livecode]

BTW I am dragging text from another application. I have never seen this 
dragging text from within Livecode. And what is being dragged is text from an 
email app although there are other sources like PDF's which is why I have to 
clean up the text before setting any LC field to the result. 

Bob S


> On Aug 10, 2017, at 08:17 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Hi all. 
> 
> I mentioned in the past I have a drag drop handler in all my editable fields 
> which cleans up the dragged text and then sets the text of the field to the 
> result. Part of the time dragging and dropping text onto these fields will 
> cause the controls on the card to become unresponsive. I cannot click 
> buttons, I cannot change the focus. Simply clicking the titlebar of the 
> window resolves this. Also focusing on another window and back again will 
> resolve it. Switching apps and back again will resolve it. It's as though the 
> stack loses focus and I have to force the stack to gain focus again, although 
> visually it is the top stack. 
> 
> Any ideas how to track something like that down?
> 
> Bob S
> 


___
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: Bug regression

[panagiotis merakos via use-livecode]

Hi Andrew,

In such cases, I would suggest to file a new bug report (and probably
mention the number of the old bug that reappeared).

However, in this specific case, what happens is a bit more complicated.
What you see is a result of some changes we have done in the segmented
control widget in LC 9.0 DP-2:

1. In LC 9.0 DP-2 the segmented control widget has been improved. One of
the changes is that you can now have no hilited items at all.

You can verify that by trying the following test, in 8.1.6 and 9.0 DP-8:

- Create a stack
- Drag a segmented control widget onto the card
- Switch to run mode
- Click twice on "Label 1"

RESULTS:
- In LC 8.1.6, the second click does not un-hilite "Label 1"
- in LC 9.0 DP-8, it does.

IMO the correct behavior is the one in 9.0 DP-8, since there might be cases
where you don't want any hilitedItem at all.

2. Now regarding the textAlign issue in the Property Inspector, when you
select multiple objects that have a different value for a property X, the
value of the property X in the property inspector is set to empty (meaning
that the multiple objects don't have the same value for property X) and the
respective property field is greyed out. But since in this case you cannot
have the textAlign being empty, the "default" value (e.g "item1" -> left)
is re-hilited.

This issue is tracked in this report:

http://quality.livecode.com/show_bug.cgi?id=19441

Best regards,
Panos
--








On Thu, Aug 10, 2017 at 4:06 PM, Andrew Bell via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I found a bug that was squashed in 8.1.0dp3 has re-appeared. What's the
> proper way to report this? I found the original thread (marked FIXED) and
> made a comment, but not sure that anyone revisits those.
>
> http://quality.livecode.com/show_bug.cgi?id=17852
>
> --Andrew Bell
>
>
> ___
> 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: Using Find with Shell on Mac

[Warren Samples via use-livecode]

On 08/10/2017 10:46 AM, Bob Sneidar via use-livecode wrote:

But I beg to be excused.



:D It's okay, Bob. Stay curious!

Warren

___
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: Using Find with Shell on Mac

[Bob Sneidar via use-livecode]

Well it's case sensitive for one. echo $home produces a blank line. $HOME 
produces my home folder. But I beg to be excused. I got into computers at first 
because of the Macintosh. I cannot remember hundreds of commands along with 
their varied arguments and flags and nuances. I will probably forget the $ in 
the terminal in about 2 weeks. 

I avoided PC's for years because all they ran was DOS and I would flip burgers 
before I learned DOS. I still have to continually refer to the dictionary and 
online API's to program. I do not have the mind for memorization of arbitrary 
information. I've only gotten one trivia question right in all my years. The 
correct answer is, "Kickapoo Joy Juice". 

Bob S


> On Aug 10, 2017, at 08:38 , Warren Samples via use-livecode 
>  wrote:
> 
> On 08/10/2017 09:36 AM, Bob Sneidar via use-livecode wrote:
>> OH RIGHT. I thought you were talking about using this in the terminal. I 
>> know about the LC environment variables.
>> Bob S
> 
> 
> What does this do in Terminal?
> 
> 'echo $HOME'
> 
> ___
> 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: Bug 20255 - Simple Loop Labeling

[Bob Sneidar via use-livecode]

+1 on the tooltip. I also comment end statements in nested loops or control 
structures, but it gets cluttery when trying to read through the script. 

Bob S


> On Aug 10, 2017, at 08:28 , Mark Wieder via use-livecode 
>  wrote:
> 
> On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote:
> 
>> I wonder whether a mouse over tooltip would work just as well. Is this 
>> something you want to be able to see _all_ the time or just if you get 
>> confused about where you are?
> 
> Hmmm... I think a tooltip could be especially useful for exit and break 
> statements in nested conditionals where it's not always obvious at first 
> glance.
> 
> -- 
> 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: Using Find with Shell on Mac

[Warren Samples via use-livecode]

On 08/10/2017 09:36 AM, Bob Sneidar via use-livecode wrote:

OH RIGHT. I thought you were talking about using this in the terminal. I know 
about the LC environment variables.

Bob S



What does this do in Terminal?

'echo $HOME'

___
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: Bug 20255 - Simple Loop Labeling

[Mark Wieder via use-livecode]

On 08/10/2017 03:00 AM, Monte Goulding via use-livecode wrote:


I wonder whether a mouse over tooltip would work just as well. Is this 
something you want to be able to see _all_ the time or just if you get confused 
about where you are?


Hmmm... I think a tooltip could be especially useful for exit and break 
statements in nested conditionals where it's not always obvious at first 
glance.


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

DragDrop Bug

[Bob Sneidar via use-livecode]

Hi all. 

I mentioned in the past I have a drag drop handler in all my editable fields 
which cleans up the dragged text and then sets the text of the field to the 
result. Part of the time dragging and dropping text onto these fields will 
cause the controls on the card to become unresponsive. I cannot click buttons, 
I cannot change the focus. Simply clicking the titlebar of the window resolves 
this. Also focusing on another window and back again will resolve it. Switching 
apps and back again will resolve it. It's as though the stack loses focus and I 
have to force the stack to gain focus again, although visually it is the top 
stack. 

Any ideas how to track something like that down?

Bob S
___
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

Bug regression

[Andrew Bell via use-livecode]

I found a bug that was squashed in 8.1.0dp3 has re-appeared. What's  
the proper way to report this? I found the original thread (marked  
FIXED) and made a comment, but not sure that anyone revisits those.


http://quality.livecode.com/show_bug.cgi?id=17852

--Andrew Bell


___
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: common code patterns

[Paul Dupuis via use-livecode]

On 8/10/2017 6:01 AM, Monte Goulding via use-livecode wrote:
> Hi Folks
>
> I’m looking for a few common code patterns that you find yourselves writing 
> often but aren’t well suited to reusable handlers. So snippets of code or 
> common ways that events are handled together in a script for a certain task.
>
> Cheers
>
> Monte

I am not sure I get exactly what you are looking for, but I find myself
rewriting very similar code over and over again in resizeStack and
resizeControl handlers

on resizeStack x,y
...
-- what I want to do is modify part of an object rect, something like:
-- set rect of btn X to rect of btn X but with new right of y-10
-- and end up writing
set rect of btn X to (item 1 of rect of btn X,item 2 of rect of btn X,
y-10, item 4 of rect of btn X)
...
end resizeStack

Sometimes I just want to add to 1 or more items in the rect, sometime
replace the values. Using top,left,etc, MOVES the object. You have to
use the rect to resize. Of course, I could write functions (and have) to
do this. There are a lot of approaches people take with function, from
general to specific.

set rect of btn X to resizeRectRight(btn X,y-10)

A clean way to do this would be nice. Say something like instead of:
set the right of btn X to y-10 -- moves button
modify the right of btn X to y-10 -- resizes button




___
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: Parent of Target

[Bob Sneidar via use-livecode]

Remember that arrays stored as properties provides a kind of scoping. For 
example 2 stacks can hold the same array but with different values in a 
property with the same name. The added advantage is they are persistent through 
idle and you can now check the contents of the properties by drilling down in 
the property inspector to the value you want to check to see what it contains. 

Properties work great as a kind of scoped global. 

Bob S


> On Aug 9, 2017, at 18:24 , Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> Addendum on Scoping
> 
> This new "modular" world, of behaviors, libs that have been put into msg path 
> with "start Using" or "insert into back".. text files, multiple 
> binary.livecode stacks -- not substacks as such, but separate.livecode files.
> The app is now a complete "environment/framework". With Andre constant 
> warnings along with my experience using globals in this environment gets very 
> dangerous very fast, typically want to use an array to starts holding all 
> kind of things we think we need to reference across many different 
> stacks/libs. Seems OK on the surface, but then as Andre says, if  
> someGlobalArray["fruit"]  = "apple" when you thought for sure it should now 
> be "orange" then then debugging "hell" door opens. So instead we start 
> sending and dispatching commands, setting up locals in scripts with lots of 
> small 
> 
> local sCurrentFlavorA
> 
> function returnCurrentFlavor
>   put sCurrentFlavorA["fruit"]
> end  returnCurrentFlavor
> 
> So now, with debug on you can trace easily where things are happening.  so 
> some way to track, not only "where did this come from" (which is what debug 
> stepping is really doing) but to look "up"   "Who is asking?"  
> would be interesting.


___
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: Using Find with Shell on Mac

[Bob Sneidar via use-livecode]

OH RIGHT. I thought you were talking about using this in the terminal. I know 
about the LC environment variables. 

Bob S


> On Aug 9, 2017, at 18:51 , Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> @ bob
> 
> try it in msg
> 
> put $HOME 
> 
> see the dictionary for $  


___
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: Bug 20255 - Simple Loop Labeling

[Mike Kerner via use-livecode]

I do this, in my code, too.  I also label my else's (with the opposite of
the condition, of course)
4D's macros have a cool way of making this happen.
for example, to make a labeled if
type the text of the condition
Select the text
Insert the if macro
The condition is replaced with
if condition then
end if #condition
That's not entirely correct, because 4D uses the ` as the comment symbol,
but you get the idea.

If you use Levure, Trevor foolishly accepted my indent rules for
sublimeText.  I added an indent rule for blocks labeled like this
#
#
The code in such a block will be indented another level, which means I get
visual separation within the block, and I can fold it.

On Thu, Aug 10, 2017 at 6:00 AM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> > On 10 Aug 2017, at 6:02 pm, panagiotis merakos via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I personally like this idea, and I find it pretty useful. And this does
> not
> > sound too difficult to implement.
> >
> > But I am not sure if everyone will like it, so if we do it, we should
> > probably add a pref to turn it on/off.
> >
> > The good news is that Ali has been doing some work on scriptifying the
> > Prefs stack, so in the future it will be easier to add Prefs for such
> > features.
>
> I wonder whether a mouse over tooltip would work just as well. Is this
> something you want to be able to see _all_ the time or just if you get
> confused about where you are?
>
> Cheers
>
> Monte
> ___
> 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: common code patterns

[Mike Kerner via use-livecode]

Do I sense macros?

I have several things that I frequently end up typing that aren't vanilla:

for any structure - repeat/if/case/etc., I normally want the "end" to have
a comment matching the beginning

if i=2 then
   something
end if #i=2

I also frequently use code blocks that I want to label
#
#


There are lots of times where you need to store a property, change it, then
restore it
For just straight code that repeats
put the itemDelimiter into theItemDelimiter
set the itemDelimiter to tab

and then below
set the itemDelimiter to theItemDelimiter


Now with 9, especially, being able to have a command set the result, there
is a lot of
if the result is not empty then exit mouseUp
put it into goop


On Thu, Aug 10, 2017 at 6:01 AM, Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Folks
>
> I’m looking for a few common code patterns that you find yourselves
> writing often but aren’t well suited to reusable handlers. So snippets of
> code or common ways that events are handled together in a script for a
> certain task.
>
> Cheers
>
> Monte
> ___
> 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

common code patterns

[Monte Goulding via use-livecode]

Hi Folks

I’m looking for a few common code patterns that you find yourselves writing 
often but aren’t well suited to reusable handlers. So snippets of code or 
common ways that events are handled together in a script for a certain task.

Cheers

Monte
___
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: Bug 20255 - Simple Loop Labeling

[Monte Goulding via use-livecode]

> On 10 Aug 2017, at 6:02 pm, panagiotis merakos via use-livecode 
>  wrote:
> 
> I personally like this idea, and I find it pretty useful. And this does not
> sound too difficult to implement.
> 
> But I am not sure if everyone will like it, so if we do it, we should
> probably add a pref to turn it on/off.
> 
> The good news is that Ali has been doing some work on scriptifying the
> Prefs stack, so in the future it will be easier to add Prefs for such
> features.

I wonder whether a mouse over tooltip would work just as well. Is this 
something you want to be able to see _all_ the time or just if you get confused 
about where you are?

Cheers

Monte
___
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: Bug 20255 - Simple Loop Labeling

[panagiotis merakos via use-livecode]

Hi all,

I personally like this idea, and I find it pretty useful. And this does not
sound too difficult to implement.

But I am not sure if everyone will like it, so if we do it, we should
probably add a pref to turn it on/off.

The good news is that Ali has been doing some work on scriptifying the
Prefs stack, so in the future it will be easier to add Prefs for such
features.

Best,
Panos

On 10 Aug 2017 02:53, "Mark Wieder via use-livecode" <
use-livecode@lists.runrev.com> wrote:

> On 08/09/2017 01:39 PM, Dr. Hawkins via use-livecode wrote:
>
>> Eureka!
>>
>> I don't know why I didn't think of this earlier, but . . .
>>
>> A simple way to get *some* level of control structure labeling . . .
>>
>>
>> So when finding the structure typed in the id of
>>
>>   switch -- myLoop
>>
>> instead of simply adding an end switch, the comment could be copied
>>
>>   end switch -- myLoop
>>
>>
>> Better yet, perhaps, would be to insert "end " before the first word
>> of the comment.
>>
>>
>>
> I do this regularly with repeat statements and if/endif statments as well,
> in fact the glx2 script editor does this automatically for me. It helps
> keep me more or less sane, especially when dealing with nested structures.
> Instead of a comment like "myLoop" I use the parameters to the switch or
> repeat or if statement, so I end up with
>
> switch word 1 of tLine
> ...
> end switch -- word 1 of tLine
>
> repeat for each item tItem in tList
> ...
> end repeat -- for each item tItem in tList
>
> if tVariable is not empty then
> ...
> end if -- tVariable is not empty
>
> --
>  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: Parent of Target

[Mark Waddingham via use-livecode]

On 2017-08-09 05:39, Sannyasin Brahmanathaswami via use-livecode wrote:

The more we separate our code/libraries/behaviors from the binary UI,
the more I find myself trying to dispatch call backs or other messages
back to the group/card/stack that has a behavior and not the
individual control: widget/button/field on the card itself, whose job
was simply to intercept a mouse event and server as the target in
higher switch.  So you need to get the long ID


I'm not sure I follow the underlying reasoning here - why not just use 
'the long id of the target'?*


The message path means that the message will hit the group/card/stack if 
not handled in the control (which it won't be, from what you are 
saying).


Warmest Regards,

Mark.

* This is the model used in the engine (e.g. for sockets), and in LCB 
widgets (which post a message to the script of the widget, which then 
filters down the message path in the usual way).


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Parent of Target

[Mark Waddingham via use-livecode]

On 2017-08-10 09:32, Ali Lloyd via use-livecode wrote:


Jacque recently showed me the speed difference between explicitly
writing out the element of an object reference:

   get the width of btn 1 of cd 2 of stack "MyStack"

...vs other forms like long IDs:

   put the long is of btn 1 of cd 2 of stack "MyStack" into t5Obj
   get teh width of tObj

The latter is much slower, yet long IDs are so good to work with.



The only reason this is true is that in the second case you are 
resolving
the object twice. It is not true in general - the second time the long 
id
is used it will use the id cache which is constant time, whereas 
"button n"
is O(n). Try benchmarking repeated use of the stored long id vs the 
number

version, especially if the numbers are large.

So it's horses for courses. If it's a one-shot object access then the
number form is faster. For repeated use, get the long id.


Just to expand on what Ali said...

There is an overhead in parsing a long id string - however, that is 
proportional to the length of the id string which are generally quite 
short. Also, this is purely 'parsing' it is basically munching chars and 
branching which means the 'step' taken at each char is very very very 
fast. Certainly something which is overwhelmed by whatever operation you 
might be doing with the resolved chunk.


What takes up the time in resolving object references is finding the 
objects at each step.


If you use the indexed form - e.g. btn 3 - then the time taken is 
proportional to the magnitude of the index as the engine has to step 
through a list to find the object.


If you use the id form, however, then the lookups are cached at the 
stack level after the first time they are resolved. The id of an object 
is unique within the confines of a stack, and every stack has a 
hash-table which caches id->objectptrs internally.


If you are doing custom control type work (which is where you tend to 
have to manage lots of child control references), then I'd generally 
suggest not using long ids, but instead just store the id property of 
the child object and use explicit syntax:


  control id ... of me -- here I'm assuming that 'me' is a group ;)

The reason is that this is (after the first lookup for any given id/me 
pair) a completely constant time lookup:


  - 'me' is stored internally as a direct pointer

  - id's can be looked up in the stack hash table.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Parent of Target

[Mark Waddingham via use-livecode]

On 2017-08-10 01:47, Monte Goulding via use-livecode wrote:

Thinking about this some more I wonder if a stringified representation
and string representation type could be paired with the object
reference so that if you got say the abbreviated id then that would be
the stringified representation and if the object is deleted then the
stringified representation is used from then on until it is
re-resolved (say the stack is reloaded). Then if it is re-stringified
then the new representation stored. The only issue here would be any
code that relied on the string not changing when you rename etc an
object etc but I’m not sure how common that would be. That and there
could be quirks like if you get the reference, rename it and then
delete it the string representation would probably still be the
original name. The general idea though is it would be something like a
string is now in the engine. We don’t need to know if under the hood
it is currently an 8 bit native string or a 16 bit unicode string.


This sounds very much like the idea proposed here - 
http://forums.livecode.com/viewtopic.php?f=66=15017 - as a reason for 
why UUIDs were not necessarily the 'right' approach (and never will be, 
IMHO) ;)


This is something which could be done (with the new architecture in 7+, 
indeed the potential for it was one of the many many reasons that 
motivated the refactor) - however, in reality, we risk changing the 
language quite fundamentally. Something which I became acutely aware of 
during the refactoring process (partly through direct conversation with 
a variety of long-term xTalkers - trying to explain what could become 
possible with it).


If we are going to break the everything-but-arrays are strings semantic 
then let's do it (1) completely and (2) in a way which ensures we 'bring 
everyone with us' (how many VB users didn't move to VB.NET?). [ The 
latter point is the most important one, btw ]. 'Creeping' language 
changes just don't work - particularly at the core semantic (types, in 
this case) level - you risk ending up with something which may be much 
more powerful but also much less accessible/easy/familiar/... ]


Indeed, this realisation of the crucial 'semantic gap'* LiveCode Script 
has (which is true of 4GLs *in general*) was one of the motivations for 
Builder**.


Builder already has the 'object handle' (ScriptObject) idea - so we can 
use that to build a library which manages the object references the IDE 
holds at any one time. This solves the robustness problem we face in the 
IDE and in a way which doesn't require a single change to LCS. (Over 
time it could also solve the speed issue too - we implement the parts 
which are bottle-necked by ScriptObject<->StringId conversions in LCB so 
they aren't necessary). [ Robustness is far more important than speed 
here, though ].


In terms of user-code, then yes, there are also user apps which require 
this - so we can just make the functionality a user available library 
extension when it is mature enough. Users can then evaluate whether it 
is 'worth' the extra cognitive cost of using such a thing for their 
situation on a per-project basis (just like the IDE - being a LiveCode 
Script project itself).


Warmest Regards,

Mark.

* I should stress that what I call a 'semantic gap' does not in any way 
make LCS a 'lesser' language - because it really is not. xTalks have 
evolved with a different focus from many other languages and fill that 
very well, that's all. They make the tasks it is focused on easier, at 
the expense of making some other things harder (but only slightly - you 
still have the 'ease' of the language as a whole to couch them in).


** I do see a future where there are not two languages - 'Script' and 
'Builder' - but only 'LiveCode'. However, that 'unification' has to be 
done in a way which does not, in any way, detract from what makes 
LiveCode Script what it is (which sounds subjective, but the recent 
study released about 'cognitive load' does perhaps suggest a means of 
measurement - which starts to make it objective).


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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: Parent of Target

[Ali Lloyd via use-livecode]

>
> Jacque recently showed me the speed difference between explicitly
> writing out the element of an object reference:
>
>get the width of btn 1 of cd 2 of stack "MyStack"
>
> ...vs other forms like long IDs:
>
>put the long is of btn 1 of cd 2 of stack "MyStack" into t5Obj
>get teh width of tObj
>
> The latter is much slower, yet long IDs are so good to work with.
>

The only reason this is true is that in the second case you are resolving
the object twice. It is not true in general - the second time the long id
is used it will use the id cache which is constant time, whereas "button n"
is O(n). Try benchmarking repeated use of the stored long id vs the number
version, especially if the numbers are large.

So it's horses for courses. If it's a one-shot object access then the
number form is faster. For repeated use, get the long id.

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