Re: ?Make Docset? updated to 3.1, DASH docset for LC now at 1.7.1

2018-10-27 Thread James Hale via use-livecode
>From Mike
> First of all, thanks a lot for doing this.  Dash is now my default way to
> access the docs, on both my ipad and mac.  I love it.
> Second, I have auto-updates turned on for both platforms, but they both
> show the LC docs at 1.6.1

I am glad it is useful. I to really like the presentation of Dash, especially 
on my ipad.

It is now actually version 1.7.2

As for the update.
It would seem that updates to user contributions are not quite automatic.
(This could be as I leave one previous version in place.)

On the Mac go to Preferences.
Click on the "Check and Install Now" button at the bottom to jog an update OF 
THE LISTING.
Select the "User-Contributions" section in the lefthand pane.
In the search area above the list of user contributed docsets, type "livecode".
On the right of the entry for LivCode there is a popup menu which allows you to 
choose which docset to install.

On the iPad go to "Settings" and click on "User Contributed docsets" and then 
on the "Update" button at the top of the screen.
At least on the iPad it seems to grab the latest (one with the higher version 
number.)

I am still getting all the "Associations" links to work so there will be a 
1.7.3 in the near future.


James



___
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


tabbed windows

2018-10-27 Thread Neville Smythe via use-livecode
Extraordinary thanks, Paul, you have reduced my blood pressure by 30 points. I 
can’t think why I so obtuse as to not think of going to a different app and 
then sliding from the Development menu to the View menu! Simples!



___
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: Numbering lines

2018-10-27 Thread Geoff Canyon via use-livecode
And of course if retaining the order isn't critical you could just go with:

function numberText T,D
   split T by cr
   combine T by cr and D
   return T
end numberText

function unNumberText T,D
   split T by cr and D
   combine T by cr
   return T
end unNumberText

On Sat, Oct 27, 2018 at 5:29 PM Geoff Canyon  wrote:

> Sorry, missed a delimiter reference:
>
> function numberText T,D
>split T by return
>put "1" & D & T[1] into R
>repeat with K = 2 to item 2 of the extents of T
>   put cr & K & D & T[K] after R --> change separator here
>end repeat
>return R
> end numberText
>
> On Sat, Oct 27, 2018 at 5:27 PM Geoff Canyon  wrote:
>
>> Converted to functions with the text and delimiter as paramaters for ease
>> of use:
>>
>> -- Add "inline line numbers" [-hh fecit, 2014]
>> function numberText T,D
>>split T by return
>>put "1:" && T[1] into R
>>repeat with K = 2 to item 2 of the extents of T
>>   put cr & K & D & T[K] after R
>>end repeat
>>return R
>> end numberText
>>
>> -- Remove "inline line numbers" [-hh fecit, 2014]
>> function unNumberText T,D
>>split T by return and D
>>put the keys of T into K
>>sort K numeric
>>repeat for each line L in K
>>   put cr & T[L] after R
>>end repeat
>>return char 2 to -1 of R
>> end unNumberText
>>
>>
>>
>> On Sat, Oct 27, 2018 at 11:54 AM hh via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>
>>> 1. Besides removing scroll-update, which takes most of the time, you
>>> could
>>> try the following array-methods (which are essentially from my stack
>>> http://forums.livecode.com/viewtopic.php?p=101301#p101301 , see there
>>> card "LineNums, tab "Nb2").
>>>
>>> This needs here on a medium fast machine (Mac mini, 2.5GHz) in average
>>> with LC 9.0.1 (which is at about 30% faster than LC 8.1.10 with that):
>>>
>>> 680 ms for 1 lines to add the line numbers,
>>> 650 ms for 1 lines to remove the line numbers,
>>> both incl. the field update (a lot of long lines are to break).
>>>
>>> -- Add "inline line numbers" [-hh fecit, 2014]
>>> -- Uses separator ": " (In LC 6 use one single char, remove below needs
>>> that)
>>> on mouseUp
>>>   lock screen; lock messages
>>>   put the millisecs into m1
>>>   set cursor to watch
>>>   put fld "IN" into T
>>>   split T by return
>>>   put the keys of T into K
>>>   sort K numeric
>>>   repeat for each line L in K
>>> put cr & L & ": " & T[L] after S --> change separator here
>>>   end repeat
>>>   set text of fld "OUT" to char 2 to -1 of S
>>>   put -1+the num of lines of S & " lines: " & \
>>> the millisecs -m1 & " ms" into fld "timing"
>>> end mouseUp
>>>
>>> -- Remove "inline line numbers" [-hh fecit, 2014]
>>> -- Uses separator ": " (the above, in LC 6 you have to use one single
>>> char)
>>> on mouseUp
>>>   lock screen; lock messages
>>>   put the millisecs into m1
>>>   set cursor to watch
>>>   put the text of fld "OUT" into S
>>>   split S by return and ": " --> change separator here
>>>   put the keys of S into K
>>>   sort K numeric
>>>   repeat for each line L in K
>>> put cr & S[L] after T
>>>   end repeat
>>>   put char 2 to -1 of T into fld "IN2"
>>>   put -1+the num of lines of T & " lines: " & \
>>> the millisecs -m1 & " ms : " & (fld "IN2" is fld "IN") into fld
>>> "timing"
>>> end mouseUp
>>>
>>> 2. All "big" editors that show line numbers never update the whole long
>>> text
>>> ** but only a few lines more than the visible line range **. Using that,
>>> nearly
>>> every LCS method (that locks the screen (and messages)) will be fast
>>> enough.
>>>
>>> > JLG wrote:
>>> > Another issue may be the line that updates the scrollbar. Try
>>> commenting out
>>> > that line as a test just to see if that's the problem. If so, you
>>> might opt
>>> > for a spinner or progress bar instead.
>>> >
>>> > > David Glasgow wrote:
>>> > > your routine is about the same as mine - 3200 lines in 106 seconds
>>> (on my
>>> > > fairly old MacBook).
>>> > >> Mark Hsu wrote:
>>> > >>  wrote:
>>> > >>
>>> > >> I think your issue is where you say “put tcount & j into line
>>> tcount of it”
>>> > >> — The line X of … call is very slow as it has to count every line
>>> from 1 - X.
>>> > >> try this:
>>> > >>
>>> > >> local tBuffer
>>> > >> put 1 into tCount
>>> > >> repeat for each line j in pText
>>> > >> put tCount & j & lf after tBuffer
>>> > >> add 1 to tCount
>>> > >> set the thumbpos of scrollbar “filterprog” to tCount
>>> > >> end repeat
>>> > >> delete line -1 of tBuffer
>>> > >> put tBuffer into pText //If you want to update the initial variable
>>> with
>>> > >> the numbered lines
>>> > >> put tBuffer into field “numberedtext"
>>> > >>> David V Glasgow  wrote:
>>> > >>>
>>> > >>> Hello folks
>>> > >>>
>>> > >>> I am doing a content analysis of online chat and messaging.
>>> Sometimes very
>>> > >>> large files, thousands or even hundreds of thousands of messages.
>>> I am
>>> > >>> finding filter and find to be 

Re: Numbering lines

2018-10-27 Thread Geoff Canyon via use-livecode
Sorry, missed a delimiter reference:

function numberText T,D
   split T by return
   put "1" & D & T[1] into R
   repeat with K = 2 to item 2 of the extents of T
  put cr & K & D & T[K] after R --> change separator here
   end repeat
   return R
end numberText

On Sat, Oct 27, 2018 at 5:27 PM Geoff Canyon  wrote:

> Converted to functions with the text and delimiter as paramaters for ease
> of use:
>
> -- Add "inline line numbers" [-hh fecit, 2014]
> function numberText T,D
>split T by return
>put "1:" && T[1] into R
>repeat with K = 2 to item 2 of the extents of T
>   put cr & K & D & T[K] after R
>end repeat
>return R
> end numberText
>
> -- Remove "inline line numbers" [-hh fecit, 2014]
> function unNumberText T,D
>split T by return and D
>put the keys of T into K
>sort K numeric
>repeat for each line L in K
>   put cr & T[L] after R
>end repeat
>return char 2 to -1 of R
> end unNumberText
>
>
>
> On Sat, Oct 27, 2018 at 11:54 AM hh via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> 1. Besides removing scroll-update, which takes most of the time, you could
>> try the following array-methods (which are essentially from my stack
>> http://forums.livecode.com/viewtopic.php?p=101301#p101301 , see there
>> card "LineNums, tab "Nb2").
>>
>> This needs here on a medium fast machine (Mac mini, 2.5GHz) in average
>> with LC 9.0.1 (which is at about 30% faster than LC 8.1.10 with that):
>>
>> 680 ms for 1 lines to add the line numbers,
>> 650 ms for 1 lines to remove the line numbers,
>> both incl. the field update (a lot of long lines are to break).
>>
>> -- Add "inline line numbers" [-hh fecit, 2014]
>> -- Uses separator ": " (In LC 6 use one single char, remove below needs
>> that)
>> on mouseUp
>>   lock screen; lock messages
>>   put the millisecs into m1
>>   set cursor to watch
>>   put fld "IN" into T
>>   split T by return
>>   put the keys of T into K
>>   sort K numeric
>>   repeat for each line L in K
>> put cr & L & ": " & T[L] after S --> change separator here
>>   end repeat
>>   set text of fld "OUT" to char 2 to -1 of S
>>   put -1+the num of lines of S & " lines: " & \
>> the millisecs -m1 & " ms" into fld "timing"
>> end mouseUp
>>
>> -- Remove "inline line numbers" [-hh fecit, 2014]
>> -- Uses separator ": " (the above, in LC 6 you have to use one single
>> char)
>> on mouseUp
>>   lock screen; lock messages
>>   put the millisecs into m1
>>   set cursor to watch
>>   put the text of fld "OUT" into S
>>   split S by return and ": " --> change separator here
>>   put the keys of S into K
>>   sort K numeric
>>   repeat for each line L in K
>> put cr & S[L] after T
>>   end repeat
>>   put char 2 to -1 of T into fld "IN2"
>>   put -1+the num of lines of T & " lines: " & \
>> the millisecs -m1 & " ms : " & (fld "IN2" is fld "IN") into fld
>> "timing"
>> end mouseUp
>>
>> 2. All "big" editors that show line numbers never update the whole long
>> text
>> ** but only a few lines more than the visible line range **. Using that,
>> nearly
>> every LCS method (that locks the screen (and messages)) will be fast
>> enough.
>>
>> > JLG wrote:
>> > Another issue may be the line that updates the scrollbar. Try
>> commenting out
>> > that line as a test just to see if that's the problem. If so, you might
>> opt
>> > for a spinner or progress bar instead.
>> >
>> > > David Glasgow wrote:
>> > > your routine is about the same as mine - 3200 lines in 106 seconds
>> (on my
>> > > fairly old MacBook).
>> > >> Mark Hsu wrote:
>> > >>  wrote:
>> > >>
>> > >> I think your issue is where you say “put tcount & j into line tcount
>> of it”
>> > >> — The line X of … call is very slow as it has to count every line
>> from 1 - X.
>> > >> try this:
>> > >>
>> > >> local tBuffer
>> > >> put 1 into tCount
>> > >> repeat for each line j in pText
>> > >> put tCount & j & lf after tBuffer
>> > >> add 1 to tCount
>> > >> set the thumbpos of scrollbar “filterprog” to tCount
>> > >> end repeat
>> > >> delete line -1 of tBuffer
>> > >> put tBuffer into pText //If you want to update the initial variable
>> with
>> > >> the numbered lines
>> > >> put tBuffer into field “numberedtext"
>> > >>> David V Glasgow  wrote:
>> > >>>
>> > >>> Hello folks
>> > >>>
>> > >>> I am doing a content analysis of online chat and messaging.
>> Sometimes very
>> > >>> large files, thousands or even hundreds of thousands of messages. I
>> am
>> > >>> finding filter and find to be delightfully fast.
>> > >>>
>> > >>> However…. Sometimes I want to prefix each line with the line
>> number, and do
>> > >>> this:
>> > >>>
>> > >>> put 1 into tcount
>> > >>> repeat for each line j in it
>> > >>> put tcount & j into line tcount of it
>> > >>> put tcount + 1 into tcount
>> > >>> set the thumbpos of scrollbar "filterprog" to tcount
>> > >>> end repeat
>> > >>> put it into field “numberedtext”
>> > >>>
>> > >>> I use ‘it’ because of a dim memory (superstition? 

Re: Numbering lines

2018-10-27 Thread Geoff Canyon via use-livecode
Converted to functions with the text and delimiter as paramaters for ease
of use:

-- Add "inline line numbers" [-hh fecit, 2014]
function numberText T,D
   split T by return
   put "1:" && T[1] into R
   repeat with K = 2 to item 2 of the extents of T
  put cr & K & D & T[K] after R
   end repeat
   return R
end numberText

-- Remove "inline line numbers" [-hh fecit, 2014]
function unNumberText T,D
   split T by return and D
   put the keys of T into K
   sort K numeric
   repeat for each line L in K
  put cr & T[L] after R
   end repeat
   return char 2 to -1 of R
end unNumberText



On Sat, Oct 27, 2018 at 11:54 AM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 1. Besides removing scroll-update, which takes most of the time, you could
> try the following array-methods (which are essentially from my stack
> http://forums.livecode.com/viewtopic.php?p=101301#p101301 , see there
> card "LineNums, tab "Nb2").
>
> This needs here on a medium fast machine (Mac mini, 2.5GHz) in average
> with LC 9.0.1 (which is at about 30% faster than LC 8.1.10 with that):
>
> 680 ms for 1 lines to add the line numbers,
> 650 ms for 1 lines to remove the line numbers,
> both incl. the field update (a lot of long lines are to break).
>
> -- Add "inline line numbers" [-hh fecit, 2014]
> -- Uses separator ": " (In LC 6 use one single char, remove below needs
> that)
> on mouseUp
>   lock screen; lock messages
>   put the millisecs into m1
>   set cursor to watch
>   put fld "IN" into T
>   split T by return
>   put the keys of T into K
>   sort K numeric
>   repeat for each line L in K
> put cr & L & ": " & T[L] after S --> change separator here
>   end repeat
>   set text of fld "OUT" to char 2 to -1 of S
>   put -1+the num of lines of S & " lines: " & \
> the millisecs -m1 & " ms" into fld "timing"
> end mouseUp
>
> -- Remove "inline line numbers" [-hh fecit, 2014]
> -- Uses separator ": " (the above, in LC 6 you have to use one single char)
> on mouseUp
>   lock screen; lock messages
>   put the millisecs into m1
>   set cursor to watch
>   put the text of fld "OUT" into S
>   split S by return and ": " --> change separator here
>   put the keys of S into K
>   sort K numeric
>   repeat for each line L in K
> put cr & S[L] after T
>   end repeat
>   put char 2 to -1 of T into fld "IN2"
>   put -1+the num of lines of T & " lines: " & \
> the millisecs -m1 & " ms : " & (fld "IN2" is fld "IN") into fld
> "timing"
> end mouseUp
>
> 2. All "big" editors that show line numbers never update the whole long
> text
> ** but only a few lines more than the visible line range **. Using that,
> nearly
> every LCS method (that locks the screen (and messages)) will be fast
> enough.
>
> > JLG wrote:
> > Another issue may be the line that updates the scrollbar. Try commenting
> out
> > that line as a test just to see if that's the problem. If so, you might
> opt
> > for a spinner or progress bar instead.
> >
> > > David Glasgow wrote:
> > > your routine is about the same as mine - 3200 lines in 106 seconds (on
> my
> > > fairly old MacBook).
> > >> Mark Hsu wrote:
> > >>  wrote:
> > >>
> > >> I think your issue is where you say “put tcount & j into line tcount
> of it”
> > >> — The line X of … call is very slow as it has to count every line
> from 1 - X.
> > >> try this:
> > >>
> > >> local tBuffer
> > >> put 1 into tCount
> > >> repeat for each line j in pText
> > >> put tCount & j & lf after tBuffer
> > >> add 1 to tCount
> > >> set the thumbpos of scrollbar “filterprog” to tCount
> > >> end repeat
> > >> delete line -1 of tBuffer
> > >> put tBuffer into pText //If you want to update the initial variable
> with
> > >> the numbered lines
> > >> put tBuffer into field “numberedtext"
> > >>> David V Glasgow  wrote:
> > >>>
> > >>> Hello folks
> > >>>
> > >>> I am doing a content analysis of online chat and messaging.
> Sometimes very
> > >>> large files, thousands or even hundreds of thousands of messages. I
> am
> > >>> finding filter and find to be delightfully fast.
> > >>>
> > >>> However…. Sometimes I want to prefix each line with the line number,
> and do
> > >>> this:
> > >>>
> > >>> put 1 into tcount
> > >>> repeat for each line j in it
> > >>> put tcount & j into line tcount of it
> > >>> put tcount + 1 into tcount
> > >>> set the thumbpos of scrollbar "filterprog" to tcount
> > >>> end repeat
> > >>> put it into field “numberedtext”
> > >>>
> > >>> I use ‘it’ because of a dim memory (superstition? Myth?) from long
> ago that
> > >>> it is faster than an arbitrarily named variable. Still, the whole
> process
> > >>> is pretty darned slow. Any brilliant suggestions?
>
> ___
> 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: “Make Docset” updated to 3.1, DASH docset for LC now at 1.7.1

2018-10-27 Thread Mike Kerner via use-livecode
I should say that just worked on mac (as in I manually updated).  On ios,
it just prompted me that there was an update and auto-updated.

On Sat, Oct 27, 2018 at 8:12 PM Mike Kerner 
wrote:

> is it because of the versioning?  Anyway, thanks, that worked.
>
> On Sat, Oct 27, 2018 at 4:00 PM J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> And on Android it doesn't work at all, which is where I wanted to use
>> it. The Android build won't load user contributions. :(
>>
>> On 10/27/18 2:24 PM, Ron Metzker via use-livecode wrote:
>> > Hi Mike,
>> >
>> > You have to chose the user contributed docs and do a check for updates.
>> I did it yesterday. Mine is also set on auto update but it seems to only
>> work on the main docset.
>> >
>> > Best Regards,
>> > Ron
>> >
>> >> On Oct 27, 2018, at 6:45 AM, Mike Kerner via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> >>
>> >> First of all, thanks a lot for doing this.  Dash is now my default way
>> to
>> >> access the docs, on both my ipad and mac.  I love it.
>> >> Second, I have auto-updates turned on for both platforms, but they both
>> >> show the LC docs at 1.6.1
>> >> ___
>> >> 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
>> >
>>
>>
>> --
>> 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
>>
>
>
> --
> 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."
>


-- 
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: “Make Docset” updated to 3.1, DASH docset for LC now at 1.7.1

2018-10-27 Thread Mike Kerner via use-livecode
is it because of the versioning?  Anyway, thanks, that worked.

On Sat, Oct 27, 2018 at 4:00 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> And on Android it doesn't work at all, which is where I wanted to use
> it. The Android build won't load user contributions. :(
>
> On 10/27/18 2:24 PM, Ron Metzker via use-livecode wrote:
> > Hi Mike,
> >
> > You have to chose the user contributed docs and do a check for updates.
> I did it yesterday. Mine is also set on auto update but it seems to only
> work on the main docset.
> >
> > Best Regards,
> > Ron
> >
> >> On Oct 27, 2018, at 6:45 AM, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> First of all, thanks a lot for doing this.  Dash is now my default way
> to
> >> access the docs, on both my ipad and mac.  I love it.
> >> Second, I have auto-updates turned on for both platforms, but they both
> >> show the LC docs at 1.6.1
> >> ___
> >> 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
> >
>
>
> --
> 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
>


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


how to properly use the fullscreenmode and screen scaling

2018-10-27 Thread Mike for GDC via use-livecode
Hello,

 

I am new to LC and have learned much so far but I am having an issue with
the proper scaling of my app on different size screens.  I have created the
app with the dimensions of 913 w X 636 h.  All looks great on the desktop.

 

When I deploy it to my 8 inch Samsung Tab A (Android)  it is ok in the
Landscape mode, with one exception.  When I go to enter data, the keyboard
covers up some of the screen that I need to enter data.  It does not scroll
up to let me get

to the field of entry.  When it is in Portrait mode I can usually see the
field but the stack only takes up about half the screen so it is very small.
When I deploy it on the Samsung S8, it is even worse in that the entire
screen is not used and therefore

it is way too small to really use it.  I would hope there is a way to take
advantage of all the screen space so as the used has a larger screen to view
and enter data.It seems the keyboard is the same size and not scaled at
all.

 

Here are the script statements that I put in my "preopenstack" of my first
card:

 

set the fullscreenMode of this stack to "showAll"

put "portrait,portrait upside down,landscape left,landscape right" into
theallowed

-- Function Call

mobileSetAllowedOrientations theallowed

 

I have also used the "exactfit", "noborder" and "soScale" options but they 

any help with suggestions or example code of how it should work would be
greatly appreciated.

Thanks.

Mike

 

 

 

___
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: “Make Docset” updated to 3.1, DASH docset for LC now at 1.7.1

2018-10-27 Thread J. Landman Gay via use-livecode
And on Android it doesn't work at all, which is where I wanted to use 
it. The Android build won't load user contributions. :(


On 10/27/18 2:24 PM, Ron Metzker via use-livecode wrote:

Hi Mike,

You have to chose the user contributed docs and do a check for updates. I did 
it yesterday. Mine is also set on auto update but it seems to only work on the 
main docset.

Best Regards,
Ron


On Oct 27, 2018, at 6:45 AM, Mike Kerner via use-livecode 
 wrote:

First of all, thanks a lot for doing this.  Dash is now my default way to
access the docs, on both my ipad and mac.  I love it.
Second, I have auto-updates turned on for both platforms, but they both
show the LC docs at 1.6.1
___
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




--
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: Standalone issue ... was starting the Project Browser

2018-10-27 Thread J. Landman Gay via use-livecode

On 10/27/18 10:26 AM, Douglas Ruisaard via use-livecode wrote:

If that's true then there's (sigh!) one more reason to stay away from LC v9... but I 
really don't understand the reason why this is necessary in the first place.  I've never 
had a standalone fail with a "can't find stack" error:


If your builds are going smoothly you don't have to change anything. Try 
it in LC 9 and see. The problem only occurs if any "open" or "close" 
handlers do something that interferes or throws errors.



So, does this situation only occur for the first standalone build?  Not the 
second time?  What is implied should be done if one of the conditions in the 
function is false?  very confusing!!!


A "can't find stack" used to occur the first time you build during any 
one session. The updated handler check fixes this so you don't need to 
worry about it any more.




I guess I was looking for something more specific about where to put this "fix":

e.g.

In an openStack call, you'd put this ... where?  At the end of the code just before the 
"end openStack"? (that's where I put it):

  if isBuildingStandalone() then
   exit openstack
  end if


The idea is that this fix will prevent the handler from executing at 
all, so it needs to be at the very front of the handler, right after the 
"on " line.



My question, then, is do I have to have a similar "if isBuildingStandalone()" call in all the "opens" and 
"closes" you list (and others) and do I "exit" the call if isBuildingStandalone() returns "true"?

WOW! ... if THAT's needed then I can't imagine anyone editing all of their code 
to do this!!!


Yes, that's what the additional lines do -- exit the handler before it 
can run. And I agree that this is an issue for some apps. The problem it 
tries to solve is retention of script local variable values, as well as 
preventing unnecessary handlers from running. But I'd rather 
reinitialize things when necessary than to add extra lines to so many 
engine messages.


I'd be happy with a simple toggle that lets me turn on lockmessages 
before building. I've been accomodating that behavior for years.


--
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: “Make Docset” updated to 3.1, DASH docset for LC now at 1.7.1

2018-10-27 Thread Ron Metzker via use-livecode
Hi Mike,

You have to chose the user contributed docs and do a check for updates. I did 
it yesterday. Mine is also set on auto update but it seems to only work on the 
main docset.

Best Regards,
Ron

> On Oct 27, 2018, at 6:45 AM, Mike Kerner via use-livecode 
>  wrote:
> 
> First of all, thanks a lot for doing this.  Dash is now my default way to
> access the docs, on both my ipad and mac.  I love it.
> Second, I have auto-updates turned on for both platforms, but they both
> show the LC docs at 1.6.1
> ___
> 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: Numbering lines

2018-10-27 Thread hh via use-livecode
1. Besides removing scroll-update, which takes most of the time, you could
try the following array-methods (which are essentially from my stack
http://forums.livecode.com/viewtopic.php?p=101301#p101301 , see there
card "LineNums, tab "Nb2").

This needs here on a medium fast machine (Mac mini, 2.5GHz) in average
with LC 9.0.1 (which is at about 30% faster than LC 8.1.10 with that):

680 ms for 1 lines to add the line numbers,
650 ms for 1 lines to remove the line numbers,
both incl. the field update (a lot of long lines are to break).

-- Add "inline line numbers" [-hh fecit, 2014]
-- Uses separator ": " (In LC 6 use one single char, remove below needs that)
on mouseUp
  lock screen; lock messages
  put the millisecs into m1
  set cursor to watch
  put fld "IN" into T
  split T by return
  put the keys of T into K
  sort K numeric
  repeat for each line L in K
put cr & L & ": " & T[L] after S --> change separator here
  end repeat
  set text of fld "OUT" to char 2 to -1 of S
  put -1+the num of lines of S & " lines: " & \
the millisecs -m1 & " ms" into fld "timing"
end mouseUp

-- Remove "inline line numbers" [-hh fecit, 2014]
-- Uses separator ": " (the above, in LC 6 you have to use one single char)
on mouseUp
  lock screen; lock messages
  put the millisecs into m1
  set cursor to watch
  put the text of fld "OUT" into S
  split S by return and ": " --> change separator here
  put the keys of S into K
  sort K numeric
  repeat for each line L in K
put cr & S[L] after T
  end repeat
  put char 2 to -1 of T into fld "IN2"
  put -1+the num of lines of T & " lines: " & \
the millisecs -m1 & " ms : " & (fld "IN2" is fld "IN") into fld "timing"
end mouseUp

2. All "big" editors that show line numbers never update the whole long text
** but only a few lines more than the visible line range **. Using that, nearly
every LCS method (that locks the screen (and messages)) will be fast enough.

> JLG wrote:
> Another issue may be the line that updates the scrollbar. Try commenting out
> that line as a test just to see if that's the problem. If so, you might opt
> for a spinner or progress bar instead.
> 
> > David Glasgow wrote:
> > your routine is about the same as mine - 3200 lines in 106 seconds (on my 
> > fairly old MacBook). 
> >> Mark Hsu wrote: 
> >>  wrote: 
> >>
> >> I think your issue is where you say “put tcount & j into line tcount of 
> >> it” 
> >> — The line X of … call is very slow as it has to count every line from 1 - 
> >> X. 
> >> try this: 
> >>
> >> local tBuffer 
> >> put 1 into tCount 
> >> repeat for each line j in pText 
> >> put tCount & j & lf after tBuffer 
> >> add 1 to tCount 
> >> set the thumbpos of scrollbar “filterprog” to tCount 
> >> end repeat 
> >> delete line -1 of tBuffer 
> >> put tBuffer into pText //If you want to update the initial variable with 
> >> the numbered lines 
> >> put tBuffer into field “numberedtext" 
> >>> David V Glasgow  wrote: 
> >>>
> >>> Hello folks 
> >>>
> >>> I am doing a content analysis of online chat and messaging. Sometimes 
> >>> very 
> >>> large files, thousands or even hundreds of thousands of messages. I am 
> >>> finding filter and find to be delightfully fast. 
> >>>
> >>> However…. Sometimes I want to prefix each line with the line number, and 
> >>> do 
> >>> this: 
> >>>
> >>> put 1 into tcount 
> >>> repeat for each line j in it 
> >>> put tcount & j into line tcount of it 
> >>> put tcount + 1 into tcount 
> >>> set the thumbpos of scrollbar "filterprog" to tcount 
> >>> end repeat 
> >>> put it into field “numberedtext” 
> >>>
> >>> I use ‘it’ because of a dim memory (superstition? Myth?) from long ago 
> >>> that 
> >>> it is faster than an arbitrarily named variable. Still, the whole process 
> >>> is pretty darned slow. Any brilliant suggestions? 

___
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: is anyone able to use fileDSN for ODBC connections in LC?

2018-10-27 Thread Matthias Rebbe via use-livecode
I´ve filed a bug now. #21658 


If anyone has additional comments please add them to the bug.

Regards,


Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de
https://winsignhelper.dermattes.de

> Am 26.10.2018 um 00:33 schrieb Matthias Rebbe via use-livecode 
> :
> 
> As the same ODBC driver (Windows 10 SQL Server) works w/o a problem when 
> using a user or system DSN connection, the driver should not be the problem.
> 
> Regards,
> 
> 
> Matthias Rebbe
> 
> free tools for Livecoders:
> https://instamaker.dermattes.de
> https://winsignhelper.dermattes.de
> 
>> Am 26.10.2018 um 00:21 schrieb Bob Sneidar via use-livecode 
>> :
>> 
>> Re: [resolved] Microsoft - Driver Manager ODBC - Invalid string or buffer 
>> length
>> 
>> 
>> 
>> Hi,
>> Are you using 64 bit sql server 2014? Please take a look at an article 
>> about:http://stackoverflow.com/questions/26745417/invalid-string-or-buffer-length.
>> Best regards
>> Sabrina
>> --
>> Don't forget to give kudos when a reply is helpful and click Accept the 
>> solution when you think you're good with it.
>> 
>> 
>> 
>>> On Oct 25, 2018, at 15:04 , Matthias Rebbe via use-livecode 
>>>  wrote:
>>> 
>>> Thanks Mark,
>>> 
>>> isn´t the DBQ parameter used when you want to access a file based Database 
>>> like Access .mdb files?
>>> 
>>> I tried it anyway, but added a  before tAccessDBFilename, as it seems 
>>> that was missing in your example.
>>> Still getting the buffer error
>>> 
>>> [Microsoft][ODBC Driver Manager] Ungültige Zeichenfolgen- oder Pufferlänge
>>> In English something like this: Invalid string or buffer length
>>> 
>>> 
>>> Regards,
>>> 
>>> Matthias
>> 
>> ___
>> 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: Standalone issue ... was starting the Project Browser

2018-10-27 Thread Brian Milby via use-livecode
If your code does things that break when called as a part of the build process, 
then you need to check and exit the handler before the code executes. Putting 
it at the end of the handler is not needed. If needed, it probably needs to go 
toward the top of the handler.

When the IDE first launches, the revStandaloneProgress stack is not loaded. 
After you build any project, then it will remain in memory for the rest of the 
session.

Thanks,
Brian
On Oct 27, 2018, 10:26 AM -0500, Douglas Ruisaard via use-livecode 
, wrote:
> I've changed the subject line (from Re: starting the Project Browser) to 
> reflect this discussion more accurately.
>
> If that's true then there's (sigh!) one more reason to stay away from LC 
> v9... but I really don't understand the reason why this is necessary in the 
> first place. I've never had a standalone fail with a "can't find stack" error:
>
> from 
> http://runtime-revolution.278305.n4.nabble.com/Standalone-build-workaround-td4728140.html#a4728141
>
> "... when you open the stack for the first time (without having built a
> standalone before), the stack "revStandaloneProgress" is not loaded yet
> (thus the "can't find stack error)"
>
> So, does this situation only occur for the first standalone build? Not the 
> second time? What is implied should be done if one of the conditions in the 
> function is false?  very confusing!!!
>
> I guess I was looking for something more specific about where to put this 
> "fix":
>
> e.g.
>
> In an openStack call, you'd put this ... where? At the end of the code just 
> before the "end openStack"? (that's where I put it):
>
> if isBuildingStandalone() then
> exit openstack
> end if
>
> and have the following function call accessible to call cards (i.e. in the 
> stack)?
>
> function isBuildingStandalone
> return the environment is "development" AND \
> there is a stack "revStandaloneProgress" AND \
> the mode of stack "revStandaloneProgress" > 0
> end isBuildingStandalone
>
>
> My question, then, is do I have to have a similar "if isBuildingStandalone()" 
> call in all the "opens" and "closes" you list (and others) and do I "exit" 
> the call if isBuildingStandalone() returns "true"?
>
> WOW! ... if THAT's needed then I can't imagine anyone editing all of their 
> code to do this!!!
>
> Douglas Ruisaard
> Trilogy Software
> (250) 573-3935
>
>
> >
> > It's referring to all engine messages that contain either "open" or 
> > "close", so:
> >
> > preOpenStack
> > preOpenBackground
> > preOpenCard
> > ...etc
> > openStack
> > openBackground
> > openCard
> > ...etc
> > closeStack
> > closeBackground
> > closeCard
> > ...etc
> >
> > I understand why this is necessary now, but it is pretty instrusive, is 
> > going to bite a lot of people,
> > and clutters up scripts. I'd like to see some sort of toggle where we could 
> > use the older method if
> > there is no problem doing that.
> >
> > On 10/26/18 11:20 AM, Douglas Ruisaard via use-livecode wrote:
> > > Thanks, Jacqueline.
> > >
> > > I have not had any issues with using the StandAlone builder but then I am 
> > > using LC v8.1.9. on
> > Windows 7. I did put Panos's code into my app ... made no apparent 
> > difference but good to have there
> > anyway.
> > >
> > > I'm a bit confused about the reference to "Similar in all other 
> > > (pre)open*/close* messages." ...
> > what is being recommended here (I get the "preOpen" bit) .. but the 
> > reference to the "close" I don't
> > get ... some other function call??
> >
> >
> > --
> > 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: Numbering lines

2018-10-27 Thread J. Landman Gay via use-livecode
Another issue may be the line that updates the scrollbar. Try commenting 
out that line as a test just to see if that's the problem. If so, you might 
opt for a spinner or progress bar instead.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On October 27, 2018 10:49:30 AM David V Glasgow via use-livecode 
 wrote:


Thanks Mark.  What you said makes sense, but when I actually  tested it, 
your routine is about the same as  mine - 3200 lines in 106 seconds (on my 
fairly old MacBook).


Cheers,

David G

On 26 Oct 2018, at 6:41 pm, Mark Hsu via use-livecode 
 wrote:


I think your issue is where you say “put tcount & j into line tcount of it” 
— The line X of … call is very slow as it has to count every line from 1 - X.

try this:

local tBuffer
put 1 into tCount
repeat for each line j in pText
 put tCount & j & lf after tBuffer
 add 1 to tCount
 set the thumbpos of scrollbar “filterprog” to tCount
end repeat
delete line -1 of tBuffer
put tBuffer into pText //If you want to update the initial variable with 
the numbered lines

put tBuffer into field “numberedtext"

- Mark Hsu



On Oct 26, 2018, at 10:27 AM, David V Glasgow via use-livecode 
 wrote:


Hello folks

I am doing a content analysis of online chat and messaging.  Sometimes very 
large files, thousands or even hundreds of thousands of messages.  I am 
finding filter and find to be delightfully fast.


However…. Sometimes I want to prefix each line with the line number, and do 
this:


put  1 into tcount
repeat for each line j in it
put tcount &  j into line tcount of it
put tcount + 1 into tcount
set the thumbpos of scrollbar "filterprog" to tcount
 end repeat
 put it into field  “numberedtext”

I use ‘it’ because of a dim memory (superstition? Myth?) from long ago that 
it is faster than an arbitrarily named variable.  Still, the whole process 
is pretty darned  slow.  Any brilliant suggestions?



Best Wishes,
David Glasgow


 

 

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

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



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

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



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

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





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

Re: Numbering lines

2018-10-27 Thread David V Glasgow via use-livecode
Thanks Mark.  What you said makes sense, but when I actually  tested it, your 
routine is about the same as  mine - 3200 lines in 106 seconds (on my fairly 
old MacBook).

Cheers,

David G

> On 26 Oct 2018, at 6:41 pm, Mark Hsu via use-livecode 
>  wrote:
> 
> I think your issue is where you say “put tcount & j into line tcount of it” — 
> The line X of … call is very slow as it has to count every line from 1 - X.
> try this:
> 
> local tBuffer
> put 1 into tCount
> repeat for each line j in pText
>  put tCount & j & lf after tBuffer
>  add 1 to tCount
>  set the thumbpos of scrollbar “filterprog” to tCount
> end repeat
> delete line -1 of tBuffer
> put tBuffer into pText //If you want to update the initial variable with the 
> numbered lines
> put tBuffer into field “numberedtext"
> 
> - Mark Hsu
> 
> 
> 
>> On Oct 26, 2018, at 10:27 AM, David V Glasgow via use-livecode 
>>  wrote:
>> 
>> Hello folks
>> 
>> I am doing a content analysis of online chat and messaging.  Sometimes very 
>> large files, thousands or even hundreds of thousands of messages.  I am 
>> finding filter and find to be delightfully fast.
>> 
>> However…. Sometimes I want to prefix each line with the line number, and do 
>> this:
>> 
>> put  1 into tcount
>> repeat for each line j in it 
>> put tcount &  j into line tcount of it
>> put tcount + 1 into tcount
>> set the thumbpos of scrollbar "filterprog" to tcount
>>  end repeat
>>  put it into field  “numberedtext”
>> 
>> I use ‘it’ because of a dim memory (superstition? Myth?) from long ago that 
>> it is faster than an arbitrarily named variable.  Still, the whole process 
>> is pretty darned  slow.  Any brilliant suggestions?
>> 
>> 
>> Best Wishes,
>> David Glasgow
>> 
>> 
>>  
>> 
>>  
>> 
>> ___
>> 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

Auth token + Firebase

2018-10-27 Thread Jose Enrique Montero via use-livecode
Hi, I am starting a project of an IOS / android app, and I want to use
firebase for the database, but  can't authenticate the users because there
is no SDK for LIVECODE.

I have created an OAUTH2 server that generates a token and I can validate
the  email / password  pair through API and receive an access token.

Now the problem is that I want the app to connect directly to Firebase
REST, but using the token generated on the server.

Someone could help me a little in clarifying this mess I have.

https://firebase.google.com/docs/database/rest/auth

I would appreciate any idea,
Best Regards

Jose Montero
___
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: [ANN] IPA Build Tool for iOS

2018-10-27 Thread Randy Hengst via use-livecode
Sean,

Thank you, thank you, thank you for making this plugin available. 

I’ve been working the past month to update my apps to iOS12… your plugin has 
been a LIFE SAVER!

be well,
randy
www.classroomFocusedSoftware.com


> On Sep 27, 2017, at 9:43 AM, Sean Cole (Pi) via use-livecode 
>  wrote:
> 
> Hi LC Community,
> 
> I needed to create IPAs of my iOS software so that I could upload them to
> my website for Enterprise distribution but all the old tools for doing this
> have been deprecated by Apple. So I've created this simple one to meet
> Apple's new standard way to produce them. Simply extract it into your
> LiveCode plugins folder and you will be able to open it from the LC menu,
> Development>Plugins>IPA_Builder. Let me know if you have any problems with
> it.
> 
> https://livecode.pidigital.co.uk/IPA_Builder.zip
> 
> Sean Cole
> *Pi Digital Productions Ltd*
> www.pidigital.co.uk
> 'Don't try to think outside the box. Just remember the truth: There is no
> box!'
> 'For then you realise it is not the box you are trying to look outside of,
> but it is yourself!'
> 
> eMail Ts & Cs    Pi Digital
> Productions Ltd is a UK registered limited company, no. 5255609
> ___
> 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

Standalone issue ... was starting the Project Browser

2018-10-27 Thread Douglas Ruisaard via use-livecode
I've changed the subject line (from Re: starting the Project Browser) to 
reflect this discussion more accurately.

If that's true then there's (sigh!) one more reason to stay away from LC v9... 
but I really don't understand the reason why this is necessary in the first 
place.  I've never had a standalone fail with a "can't find stack" error:

from 
http://runtime-revolution.278305.n4.nabble.com/Standalone-build-workaround-td4728140.html#a4728141

"... when you open the stack for the first time (without having built a 
standalone before), the stack "revStandaloneProgress" is not loaded yet 
(thus the "can't find stack error)"

So, does this situation only occur for the first standalone build?  Not the 
second time?  What is implied should be done if one of the conditions in the 
function is false?  very confusing!!!

I guess I was looking for something more specific about where to put this "fix":

e.g.

In an openStack call, you'd put this ... where?  At the end of the code just 
before the "end openStack"? (that's where I put it):

 if isBuildingStandalone() then 
  exit openstack 
 end if

and have the following function call accessible to call cards (i.e. in the 
stack)?

function isBuildingStandalone 
 return the environment is "development" AND \
   there is a stack "revStandaloneProgress" AND \
 the mode of stack "revStandaloneProgress" > 0 
end isBuildingStandalone 


My question, then, is do I have to have a similar "if isBuildingStandalone()" 
call in all the "opens" and "closes" you list (and others) and do I "exit" the 
call if isBuildingStandalone() returns "true"?

WOW! ... if THAT's needed then I can't imagine anyone editing all of their code 
to do this!!!

Douglas Ruisaard
Trilogy Software
(250) 573-3935


> 
> It's referring to all engine messages that contain either "open" or "close", 
> so:
> 
> preOpenStack
> preOpenBackground
> preOpenCard
> ...etc
> openStack
> openBackground
> openCard
> ...etc
> closeStack
> closeBackground
> closeCard
> ...etc
> 
> I understand why this is necessary now, but it is pretty instrusive, is going 
> to bite a lot of people,
> and clutters up scripts. I'd like to see some sort of toggle where we could 
> use the older method if
> there is no problem doing that.
> 
> On 10/26/18 11:20 AM, Douglas Ruisaard via use-livecode wrote:
> > Thanks, Jacqueline.
> >
> > I have not had any issues with using the StandAlone builder but then I am 
> > using LC v8.1.9. on
> Windows 7.  I did put Panos's code into my app ... made no apparent 
> difference but good to have there
> anyway.
> >
> > I'm a bit confused about the reference to "Similar in all other 
> > (pre)open*/close* messages." ...
> what is being recommended here (I get the "preOpen" bit) .. but the reference 
> to the "close" I don't
> get ... some other function call??
> 
> 
> --
> 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: tabbed windows in Mac - as setProp

2018-10-27 Thread Paul Hibbert via use-livecode
The menu item “View > Show Tab Bar” does show up occasionally, there does seem 
to be a trick to getting it to show up if it’s not there right now. 

I find that switching apps will sometimes return the menu item occasionally, 
but I seem to be able to force it to show up by switching to an app that does 
have tabs, such as Mail, then click on the LC window that is showing a Tab Bar 
(to switch back to LC), now click and hold on the “Development” Menu then slide 
across to the “View” menu, now you have one opportunity to turn off the 
offending Tab bar before it magically disappears again.

Hope I explained well enough and it works for you, good luck.

Paul

> On Oct 25, 2018, at 20:49, Neville Smythe via use-livecode 
>  wrote:
> 
> Well it seems the feature is “tabbed” windows. It is a feature of High 
> Sierra. However for non-Apple apps it has to be implemented by the third 
> party, and in this case I think the LC implementation is faulty.  I can add 
> windows to the tabs, but not remove the last tab.There is supposed to be a 
> menu item in the Windows menu to turn the feature on and off, but it’s not 
> there. I can’t turn it off and I have no idea how it got turned on, 
> presumably a combination of option keys while the cat was walking across the 
> keyboard. Yesterday upon the stair I met a man who wasn’t there … I wish, I 
> wish he’d go away.
> ___
> 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: “Make Docset” updated to 3.1, DASH docset for LC now at 1.7.1

2018-10-27 Thread Mike Kerner via use-livecode
First of all, thanks a lot for doing this.  Dash is now my default way to
access the docs, on both my ipad and mac.  I love it.
Second, I have auto-updates turned on for both platforms, but they both
show the LC docs at 1.6.1
___
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