Re: Layers in PBrowser

2020-09-02 Thread Geoff Canyon via use-livecode
Hi Bob,

Goes to show how important user research is. For me personally, I want to
get Navigator out of the way entirely when I minimize it. It's trivial to
have a preference to make it minimize in place. But also: I went to some
length to have it avoid minimizing behind/on top of (don't remember which
way it went) the menu bar. I think I could easily both:

1. Offer a preference to minimize where it is
2. Automatically avoid overlapping the GLX2 bar. Can you send me the name
of any stacks involved to avoid? I haven't looked, but I think it would be
as simple as adding a stack name to a list.

On Mon, Aug 31, 2020 at 10:09 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Sean. I concur with Geoff. There were quite a while ago issues, but
> Geoff got on them and now I use Navigator all the time. The only thing I
> will say Geoff is that when I drag the window to a location, I would like
> it to remain there, even when minimized. It always reverts to a default
> location when first opened, which happens to overlap the GLX2 bar.
>
> Bob S
>
>
> On Aug 29, 2020, at 12:54 AM, Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>>
> wrote:
>
> Hey Sean,
>
> Late to the conversation because Navigator is a hobby, but: I've worked
> *really* hard to make drag-and-drop relayering work properly.
>
> I've implemented it almost from scratch something like five times over the
> years, each time because I reached a dead end with the previous method (or
> sometimes because I'd reached a dead end with the previous method of
> implementing drag and drop.
>
> Which is to say: drag and drop has a large number of special cases, and is
> very hard to get right. Anyone attempting it has my sympathies.
>
> *That* said, there are only a very small number of problematic use cases in
> Navigator that I know of. If the latest (which has been out for some time
> now) update of Navigator doesn't relayer the way you think it should, email
> me directly and let me know.
>
> gc
>
> ___
> 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: Layers in PBrowser

2020-08-29 Thread Geoff Canyon via use-livecode
Hey Sean,

Late to the conversation because Navigator is a hobby, but: I've worked
*really* hard to make drag-and-drop relayering work properly.

I've implemented it almost from scratch something like five times over the
years, each time because I reached a dead end with the previous method (or
sometimes because I'd reached a dead end with the previous method of
implementing drag and drop.

Which is to say: drag and drop has a large number of special cases, and is
very hard to get right. Anyone attempting it has my sympathies.

*That* said, there are only a very small number of problematic use cases in
Navigator that I know of. If the latest (which has been out for some time
now) update of Navigator doesn't relayer the way you think it should, email
me directly and let me know.

gc

On Thu, Aug 13, 2020 at 1:56 AM Sean Cole (Pi) via use-livecode <
use-livecode@lists.runrev.com> wrote:

> @Matthias Rebbe 
>
> Were are just replacing issues with new issues. Just looked at the github
> for 'Navigator' only to see a heap of unresolved issues there too!
> https://github.com/gcanyon/navigator/issues
>
> This seriously sucks!
>
> Sean Cole
> *Pi Digital*
>
> On Wed, 12 Aug 2020 at 18:45, matthias rebbe via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Sean,
> >
> > my answer will not solve your problems with the Project Browser...
> > but did you already try Geoff Canyons Navigator
> >
> > https://gcanyon.wixsite.com/navigator <
> >
> https://bowtie.mailbutler.io/tracking/hit/5524ddd4-763e-47f2-b835-0050b8a7fe6f/693e8792-fedc-482a-9940-e98f47b6ee1a
> > >
> > https://www.dropbox.com/s/kz3zqi4botzglgq/navigator.zip?dl=1 <
> >
> https://bowtie.mailbutler.io/tracking/hit/5524ddd4-763e-47f2-b835-0050b8a7fe6f/9596c7b6-a84d-40ae-96c9-b3578d222b9f
> > >
> >
> > Navigator allows also to "relayer" objects by dragging and there it even
> > works.
> >
> > HTH
> >
> > Regards,
> >
> > -
> > Matthias Rebbe
> > Life Is Too Short For Boring Code
> >
> > > Am 12.08.2020 um 19:42 schrieb Sean Cole (Pi) via use-livecode <
> > use-livecode@lists.runrev.com>:
> > >
> > > And when you are in a group editing mode, the layers in the Project
> > Browser
> > > are messed up beyond use. HOW?? Why has this STILL not been fixed since
> > > v6 I'm just tired of asking. I'm stressed! Up against a deadline
> > > (Again). No budget to pay the ridiculous fees LC ask. And absolutely no
> > way
> > > out... again! It blows my mind how I keep putting myself in this
> > situation
> > > for LC to KEEP letting me down because of stupid dumb ass issues that
> > don't
> > > get fixed!
> > >
> > > Frustrated.
> > >
> > > Sean
> > >
> > > On Wed, 12 Aug 2020 at 18:29, Sean Cole (Pi) 
> > wrote:
> > >
> > >> Hi all,
> > >>
> > >> Why is this still an issue? I find it so hard putting layers in the
> > right
> > >> order. It just gets me down when I have fast turnaround jobs that are
> > held
> > >> up because of STUPID frikin issues like this. Over and over again
> > >>
> > >> https://www.dropbox.com/s/qakyg8bu8bdamhn/LayerControl.mov?dl=0
> > >>
> > >> LC would be brilliant if it wasn't so crap all the time.
> > >>
> > >> Sean Cole
> > >>
> > >> *Pi Digital Productions Ltd*
> > >>
> > > ___
> > > 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: Navigator won't go away!

2020-06-28 Thread Geoff Canyon via use-livecode
Just came across this -- sorry for the frustration. I'll reach out to the
LC crew about either updating or removing Navigator.

gc

On Fri, Mar 27, 2020 at 12:51 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> OK Sorry for the noise. I see now that the Files & Memory/User Extensions
> setting in preferences needs to be pointed at /Users/ profile>/Documents/Livecode/ and NOT the plugins folder. Now all the
> plugins are loading properly.
>
> Bob S
>
>
> > On Mar 26, 2020, at 10:45 AM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Whoopsie, NO plugins are loading from the /Users/ profile>/Documents/Livecode/PlugIns/ folder! Wha???
> >
> > Bob S
> >
> >
> >> On Mar 26, 2020, at 10:41 AM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> FOUND IT! It was in the actual MacOS APPLICATION BUNDLE!!!
> >>
> >> Hey LC, I appreciate the freebies, but a beta of 2.5?? Seriously? Geoff
> is up to v6 now, and it’s open source, not honor-ware. If putting the newer
> version in the Plugins folder is supposed to override the embedded one, it
> doesn’t work.
> >>
> >> Bob S
> >>
> >>
> >>> On Mar 26, 2020, at 10:33 AM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>>
> >>> I have removed every instance of Navigator from my hard drive (I
> searched for them and deleted them) in preparation of installing the latest
> version. I did this because on my home Mac, I keep getting a 2.5 beta
> version of the plug-in every time I launch!
> >>>
> >>> I verified my plugin folder is set to /Users/ profile/Documents/Livecode/PlugIns/
> >>>
> >>> I quit Livecode, then relaunch it. I still see revNavigator in the
> Development/Plugins menu, and when I select it, the 2.5 beta version
> loads!!! What the actual eff???
> >>>
> >>> Where else would Livecode be getting these plugins from??
> >>>
> >>> 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
> >>
> >> ___
> >> 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: 9.5 on Windows seems terribly unable to deal with fields full of text?

2019-09-09 Thread Geoff Canyon via use-livecode
I’ve now modified my stacks to include a closecard handler to clear the large 
field’s content when exiting. 

Stack is now much faster to work with and save — far out of proportion to the 
size savings. 
___
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: 9.5 on Windows seems terribly unable to deal with fields full of text?

2019-09-08 Thread Geoff Canyon via use-livecode
Just running a script with large variables, no viewers open, and setting a 
breakpoint took 20 seconds. 
___
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


9.5 on Windows seems terribly unable to deal with fields full of text?

2019-09-08 Thread Geoff Canyon via use-livecode
The ide seems slow in general, but put the contents of a 1 mb 80k line file, 
and the message box disables the IDE, with multi-second delays. Examine that 
value as a variable, and similarly but to a lesser extent things slow down. I 
remember having no trouble doing things like this in 8, maybe even 9 on my 
6-year-old MacBook, which is in the shop getting a new battery. 

Anyone else? Any 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


Browser widget cookies?

2019-08-27 Thread Geoff Canyon via use-livecode
If I set the url for the browser widget to a url, and the server sets a cookie, 
can I read/modify/delete that cookie?

gc
___
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: LC904rc2 Project Browser error?

2019-05-23 Thread Geoff Canyon via use-livecode
I installed 9.0.4 on a Mac, and it looks like there are several bugs still
with drag and drop of groups. Did you file a bug for this issue?

On Sat, Apr 27, 2019 at 12:17 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Not to slight to any 3rd party tools, but I personalty would rather
> identify bugs in LiveCode and report them to the LiveCode Quality
> Center. My experience has been that a bug, properly reported, with a
> repeatable recipe and test stack is fixed pretty rapidly these days.
>
> One of the first steps though is to determine whether the issue is
> repeatable - can other people on other computer reproduce the observed
> issue - which is why I was asking if anyone else has seen or can
> reproduce this issue I observed.
>
> I am not sure from your reply whether that means you can also see this
> specific issue (not relayering groups by drag and drop in the IDE
> project browser) in LC9.0.4rc2.
>
> On 4/26/2019 12:26 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
> > It may be "many moons" before they fix the PB.
> >
> > I hardly use any more.
> >
> > Get Geoff's Navigator!
> >
> > BR
> >
> > Paul Dupuis wrote:
> >
> >  I find that in the project browser under LC904rc2 (Windows 10), I
> can
> >  not relayer groups. Button, fields, etc, all relayer fine by drag
> and
> >  drop within the hierarchical list of the project browser, but not
> groups.
> >
> > ___
> > 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


Carving out stacks (or even just scripts) from a standalone

2019-03-25 Thread Geoff Canyon via use-livecode
Has anyone tried doing this lately? I shouldn't really say lately, since
the standalone in question was likely built with something like the 4.5
engine, maybe even earlier. I don't think it was encrypted, it's on a Mac,
but I also have access to a PC-built version if that makes a difference.

Anyone have guidance on salvaging anything?

gc
___
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: Script Editor Refactoring Support

2019-03-20 Thread Geoff Canyon via use-livecode
This sounds awesome!

gc

> On Mar 20, 2019, at 10:45 AM, Mark Wieder via use-livecode 
>  wrote:
> 
> Announcing (60 days until the San Jose conference):
> 
> 


___
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: get an overview of all scripts (e.g total lines of all scripts) of a stack

2019-03-18 Thread Geoff Canyon via use-livecode
Late to the party, but the contextual menu in Navigator has a scripts
sub-menu:

Scripts
Count
Count with Behaviors
Count Enclosed
Count Enclosed with Behaviors
-
Copy
Copy with Behaviors
Copy Enclosed
Copy Enclosed with Behaviors

The counting options report looks like this:

The size of the scripts is:
10438 characters in
249 lines in
3 scripts in
6 objects.


stack "/Users/gcanyon/Documents/My
Livecode/Plugins/Navigator_Behaviors/rev_b_whichTarget.livecodescript"
stack "rev_b_whichTarget"
Script Line Count: 26 Script Length: 963

stack "/Users/gcanyon/Documents/My
Livecode/Plugins/Navigator_Behaviors/rev_b_whichCard.livecodescript"
stack "rev_b_whichCard"
Script Line Count: 42 Script Length: 1785

stack "/Users/gcanyon/Documents/My
Livecode/Plugins/Navigator_Behaviors/rev_b_pophandlers.livecodescript"
stack "rev_b_pophandlers"
Script Line Count: 181 Script Length: 7690


On Fri, Mar 15, 2019 at 7:38 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I can think of one use case. A developer might charge for lines of code
> instead of hours spent.
>
> Bob S
>
>
> > On Mar 14, 2019, at 08:10 , Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > So dear readers, please understand that I'm rather eager to produce
> exactly what you're looking for, if I can learn more specifically what it
> is you want and how it helps your development process.
> >
> > Consider this an open invitation to discuss the business case for
> project metrics, and which ones are especially valuable to your work and
> which one's aren't.
>
>
> ___
> 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: [off]sublimeText update

2019-03-18 Thread Geoff Canyon via use-livecode
Don't forget that you can iterate over the keys if you need them:

repeat for each key tStack in tStacks

or over the elements if you don't need the keys:

repeat for each element V in tStacks

On Mon, Mar 18, 2019 at 4:10 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 3/18/19 3:50 PM, Bob Sneidar via use-livecode wrote:
> > Nice little shortcut. I usually put the keys into a variable first so I
> can see what they are when debugging.
>
> I do too, but this was just a one-off proof of concept.
>
> --
>   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: [off]sublimeText update

2019-03-16 Thread Geoff Canyon via use-livecode
On Sat, Mar 16, 2019 at 9:33 AM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 3/16/19 7:43 AM, AndyP via use-livecode wrote:
> >
> >> But I agree that Navigator having a crap-ton of script-only behaviors is
> >> cumbersome in the IDE if you're showing IDE stacks.
> >
> > At the moment we can hide plugins but only by prefixing the stack name
> with
> > rev. It would be great if we could have another prefix for plugins so
> that
> > they do not get shown in the project browser as standard.
>
> It should be pretty easy to hack the PB to hide plugins when desired...
> If the stack name is among the keys of revIDEPlugins(), ignore it.
>
> Unfortunately, that won't help the Navigator problem.
> Maybe "if the mainstack of stack  is among"...
>

A more general solution would be to have an option to hide SoS in the PB.

As an aside -- why is the scriptonly of stack "revMenuBar" true?? That just
cost me fifteen minutes of debugging Navigator when the only issue was that
Nav was set to not show SoS.
___
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: [off]sublimeText update

2019-03-15 Thread Geoff Canyon via use-livecode
One of the reasons (the only reason?) I don't do something like this with
Navigator is that there are at least a few people that clone the Navigator
repo directly. I'd rather have everyone (Except Brian!) using the same
exact form of Navigator rather than some using the version with script-only
stacks and the rest using binary.

But I agree that Navigator having a crap-ton of script-only behaviors is
cumbersome in the IDE if you're showing IDE stacks.

gc

On Thu, Mar 14, 2019 at 5:32 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 3/14/19 9:53 AM, Brian Milby via use-livecode wrote:
>
> > I noticed that the plugin was a single file and wondered how you did
> that.  When I convert Navigator, I create a single sub stack and map each
> behavior to a new button with the same name as the script only stack name.
> I’ll need to read your script a little more closely to see what is
> happening.
>
> Yeah... if only we could treat script-only stacks as substacks, eh?
>
> --
>   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: Relayering Madness

2019-03-15 Thread Geoff Canyon via use-livecode
On Thu, Mar 14, 2019 at 3:09 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Jacque, I did that of course, same result. I forgot that there is a
> way of doing this using Navigator, by starting a drag on the group in
> Navigator, THEN pressing the option key, and dropping it where you want it.
> If you start with the option key it clones it instead. DOH!
>

I don't know what version of Navigator you have, but you shouldn't have to
use the option key except when you want to clone something. If you're using
the latest version and pressing the option key after you start dragging
*doesn't* clone, let me know what you're doing; that's a bug. I just tried
it and I can't replicate it.

gc
___
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: Relayering Madness

2019-03-15 Thread Geoff Canyon via use-livecode
On Thu, Mar 14, 2019 at 4:24 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I guess I'm not sure what the problem was, I relayer groups all the
> time. I change the layer number in the group's property inspector
> though, since I don't use the Project Browser. Maybe it's different there.
>

The Project Browser allows you to drag anything to any layer, in a group or
out, and will make it happen. I believe (although I have not looked at the
code lately) that it does this by setting relayerGroupedControls to true.
Evidence for this is the fact that dragging a control to the layer just
above a group -- just below the group in the Project Browser -- will place
the control into the group.



This is how Navigator used to work as well. Several updates ago I changed
Navigator to use a sequence of steps involving editing groups, and setting
relayerGroupedControls to true only if necessary, so that:

1. Dragging to the layer just above a group does *not* place the control
into the group; just to the appropriate layer.
2. Dragging to a layer *in* a group moves the control into the group, at
that layer.
3. The above works even with nested groups (just checked, and I'm very
happy with my past self!) Meaning that if you have this:

stack "Untitled 1"
card id 1002
|  group id 1011 (1011)
|  |  group id 1006 (1006)
|  |  |  button "Button" (1003)
|  |  |  button "Button" (1007)
|  |  |  button "Button" (1004)
|  |  |  button "Button" (1005)
|  |  |  button "Button" (1009)
|  |  button "Button" (1010)
|  |  button "Button" (1008)
|  button "Button" (1012)
|  button "Button" (1013)

And you drag button id 1013 just under button id 1009, you get this:

stack "Untitled 1"
card id 1002
|  group id 1011 (1011)
|  |  group id 1006 (1006)
|  |  |  button "Button" (1003)
|  |  |  button "Button" (1007)
|  |  |  button "Button" (1004)
|  |  |  button "Button" (1005)
|  |  |  button "Button" (1009)
|  |  button "Button" (1013)
|  |  button "Button" (1010)
|  |  button "Button" (1008)
|  button "Button" (1012)

Note that button id 1013 is now in group id 1011, but it is *not* in group
id 1006.

Holding the option/alt key is not needed for any of this.
___
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: [off]sublimeText update

2019-03-13 Thread Geoff Canyon via use-livecode
I wrote an XML exporter about fifteen years ago. I don't think I have a
copy of it anywhere, and of course it probably would break with all the
changes since then. But it wasn't *that* complex; Navigator has built-in
code to return a list of all the controls within a given group/card/stack,
and separately all the properties/custom properties etc.

gc

On Wed, Mar 13, 2019 at 10:30 AM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> My stack is a different take on the problem.  It allows the benefit of
> tracking the scripts in a VCS while retaining the convenience of a binary
> stack file.  It also allows easy editing of scripts outside of the IDE
> without moving to SOS.  I’m still not convinced that SOS use makes sense
> all of the time (why put a single level of indirect reference in every
> object if the script isn’t shared for example).  Even though I name them
> and format them like a valid SOS, I do not convert them to actual behaviors.
>
> One area where I prefer binary stacks is plugins.  It seems cleaner to
> keep the code self contained inside the IDE.  I actually consolidate
> Navigator to a single binary file on my systems and do not notice anything
> different in operation.
>
> Monte had another project that did export an entire stack into a
> collection of text files compatible with VCS.  His solution allowed
> multiple developers to work on a stack using the VCS processes to merge
> work.  That is much more ambitious than my goal.  My solution would only
> facilitate distributed work on the scripts of a stack with someone being
> the gatekeeper of the binary stack file.
>
> Exporting properties of each object would not be that difficult to add,
> but doing so in a way compatible with VCS would take a bit of thought.
> Monte would encode binary stuff into an ASCII friendly format.  [I do
> include a few items as comments at the top of each script (behavior, long
> name/ID).]  Format could be XML, JSON, YAML, some new TLA format to appear
> this year...
>
> Thanks,
> Brian
> On Mar 13, 2019, 10:59 AM -0400, Mike Kerner via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
> > Navigator also has an exporter, and Monte wrote "Scriptifier", which is
> > included in the LC bundle, for exporting scripts to SOS's. Once they're
> in
> > SOS's, there's no reason to put them back in the stack, since you can
> edit
> > them using the LC SE or in an external editor. I thought about writing
> > something to export the properties of objects in a stack into text files,
> > and then at startup using that information to build the stack, but that's
> > as far as it's gotten is thinking about it.
> >
> > On Wed, Mar 13, 2019 at 10:28 AM Brian Milby via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > I have a tool that exports the scripts of a stack and can facilitate
> > > editing in any external editor. I want to hook it up in Atom like ST,
> but
> > > have not figured out how to rewrite the module in JS. ScriptTracker
> works
> > > by watching a directory for changes to the files. The ST plugin works
> by
> > > sending messages to a server process running in the IDE.
> > >
> > > forums.livecode.com/viewtopic.php?f=77=31079
> > > github.com/bwmilby/lc-misc/tree/master/ScriptTracker
> > > github.com/bwmilby/lc-misc/blob/master/ScriptTracker/ScriptTracker.md
> > >
> > > Thanks,
> > > Brian
> > > On Mar 13, 2019, 10:18 AM -0400, Mike Kerner via use-livecode <
> > > use-livecode@lists.runrev.com>, wrote:
> > > > The new sublimeText update dropped this morning, and it's pretty
> sweet.
> > > > It now has things like git status integration, which is very cool.
> > > > It would be really cool if we could get better integration between
> > > external
> > > > text editors and ST. The ST kluge works great for updating scripts
> live
> > > in
> > > > LC, except when it doesn't, and I don't think we have a way to do it
> with
> > > > Atom, yet.
> > > > It would also be cool if we had a better way to have stack files be
> > > > represented as text files instead of binary files for easier version
> > > > control and editing.
> > > > Anyway,
> > > > https://www.sublimetext.com/blog/articles/sublime-text-3-point-2
> > > >
> > > > --
> > > > 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
> > > 

Re: Weird LiveCode Plugins Prefs writing problems

2019-02-08 Thread Geoff Canyon via use-livecode
On Fri, Feb 8, 2019 at 2:55 PM William Prothero via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Folks:
> Livecode 9.0.2 business Mac OSX 10.14.2
>

I'm also on 10.14.2 and I'm not seeing this with Navigator. (or other
plugins) Sorry I don't have something better to offer.
___
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: How to tell if a field is "closed"?

2019-02-05 Thread Geoff Canyon via use-livecode
I'm sure someone else will come up with something better, but at the least,
don't set a custom property for each field; instead, in the openField set
one custom property for the card or group that the fields are in, something
like "isOpen", with the long id of the open field; then empty that property
on exitField. That way when you import you just have to check that one
property, and if it contains a long id, validate that field.

On Tue, Feb 5, 2019 at 11:25 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I have a problem for which I should probably redesign the user
> interface, but would rather not do so for many reasons.
>
> The problem is this:
>
> 1) There are some fields on a card. Each field has a "closeField"
> handler that checks the fields content for validity and presents
> appropriate error messages (via a standard 'answer" command).
> 2) There is an "Import" button that collects the field values and lots
> of other data and does a task in my application.
> 3) If a user edits a fields and enters an invalid value and does not
> click, tab, or press the return key to "close" the field and trigger the
> "closeField" message, but immediately clicks on the "import" button, my
> import script starts using the invalid value from the open field while
> at the same time a closeField message does get send and an answer dialog
> appears telling what is invalid about the entry.
>
> However, my import routine is off and and running with bad data. I need
> a way at the start of the import routine to ensure all fields are closed
> - i.e. that their closeField handlers have ensured the field values are
> correct.
>
> In a worst case, I could solve this by a custom property for each field
> - say valueOK - and set it to false on openField and true on closeFIeld
> or exitFIeld if the edited value valid. The import button would then
> check for any instances where the custom property 'vaueOK' is false, and
> if there are any, exit without running and with an appropriate message.
>
> However, I am wondering if anyone in the LiveCode brain trust has
> figured out a better way to handle something like this?
>
> ___
> 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: Navigator 7.3rc1 is available

2019-01-30 Thread Geoff Canyon via use-livecode
Most (almost all) of Navigator has nothing to do with the actual selection
of controls in Livecode. So the second window is working fine -- just
select whatever controls you want to work with in the list, and then
everything Navigator does, you can do -- change their properties in
Navigator, edit their script (or behavior script) etc. You can also do
things like open Livecode's property palette for a control or set of
controls -- just select them in the list, and then select Single Object
Inspector or Individual Object Inspectors on the Properties ("P") menu.

If that's not clear, what are you looking to do?

gc

On Wed, Jan 30, 2019 at 12:26 PM Clarence Martin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Will the update allow you to use Navigator to work in the Group Edit
> Window?
>
> Sincerely,
>
> Clarence Martin
> Email: chi...@themartinz.com
> Cell: 626 696-5561
>
> -Original Message-----
> From: use-livecode  On Behalf Of
> Geoff Canyon via use-livecode
> Sent: Wednesday, January 30, 2019 11:38 AM
> To: How to use LiveCode 
> Cc: Geoff Canyon 
> Subject: Re: Navigator 7.3rc1 is available
>
> Yep, that's exactly what I said -- when you open in a new Navigator, the
> target is a specific container (a group in this case). Under those
> circumstances Navigator doesn't try to select controls in Livecode, or
> mimic
> Livecode's selections, because the group might not be visible or
> selectable.
> Like I said in the bug, I'll add a setting and protection for Navigator to
> try to mimic anyway
>
>
> On Wed, Jan 30, 2019 at 10:40 AM Clarence Martin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I created a video for you to see but it is being check by the LiveCode
> > list admin for content because of its size.
> > Here is a link to my OneDrive folder containing the video:
> > https://1drv.ms/v/s!AmMnOdWPxdzK6jkkp3Kn8m7HIwm_
> > You can download and view it from there. I hoe this explains my comments.
> >
> > Sincerely,
> >
> > Clarence Martin
> > Email: chi...@themartinz.com
> > Cell: 626 696-5561
> >
> > -Original Message-
> > From: use-livecode  On Behalf
> > Of Geoff Canyon via use-livecode
> > Sent: Wednesday, January 30, 2019 9:31 AM
> > To: How to use LiveCode 
> > Cc: Geoff Canyon 
> > Subject: Re: Navigator 7.3rc1 is available
> >
> > On Wed, Jan 30, 2019 at 5:09 AM Clarence Martin via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > Ji Geoff,
> > > I am responding to you 7.3rc1 and this is probably true about the
> > > other releases too.
> > > I noticed that if I open a group in a New Navigator window, the
> > > first Navigator window has lost control over the group that
> precipitated
> it.
> > > The new Navigator Window Group items don't respond to any items that
> > > are clicked or highlighted.
> > > Also, if I open a group for editing, the Navigator window does not
> > > respond to any items that are clicked or highlighted in the Group
> > > Edit
> > window.
> > > I can live with this now that I know  about this behavior, but I
> > > don't know if anyone has pointed this out to you.
> > >
> >
> > I'm not sure what you mean by "lost control". I followed these steps:
> >
> > 1. Created a Livecode window, added three buttons, and grouped them.
> > 2. Opened Navigator. It shows the stack, the card, the group, and the
> > three buttons.
> > 3. Right-click on the group in Navigator, and select "Browse Controls"
> > on the popup menu. Navigator shows the stack, the group, and the buttons.
> > 4. Right-click the first button in Navigator and select Rename... on
> > the popup menu. Navigator opens the dialog and I successfully rename
> > the button.
> > 5. Right-click the group in Navigator and select Open in New Navigator
> > on the popup menu. Navigator opens a new window showing the same
> controls.
> > 6. In the new Navigator, right-click the second button and select
> Rename...
> > on the popup menu. Navigator opens the dialog and I successfully
> > rename the button.
> > 7. In the original Navigator, right-click the third button and select
> > Rename... on the popup menu. Navigator opens the dialog and I
> > successfully rename the button.
> >
> > So Navigator still knows what controls it's supposed to display,
> > displays them, and works with them.
> >
> > Wait -- do you mean highlighting? As in, select controls in Navigator,
> > and they become selected in Livecode, and vice v

Re: Navigator 7.3rc1 is available

2019-01-30 Thread Geoff Canyon via use-livecode
Yep, that's exactly what I said -- when you open in a new Navigator, the
target is a specific container (a group in this case). Under those
circumstances Navigator doesn't try to select controls in Livecode, or
mimic Livecode's selections, because the group might not be visible or
selectable. Like I said in the bug, I'll add a setting and protection for
Navigator to try to mimic anyway


On Wed, Jan 30, 2019 at 10:40 AM Clarence Martin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I created a video for you to see but it is being check by the LiveCode list
> admin for content because of its size.
> Here is a link to my OneDrive folder containing the video:
> https://1drv.ms/v/s!AmMnOdWPxdzK6jkkp3Kn8m7HIwm_
> You can download and view it from there. I hoe this explains my comments.
>
> Sincerely,
>
> Clarence Martin
> Email: chi...@themartinz.com
> Cell: 626 696-5561
>
> -Original Message-----
> From: use-livecode  On Behalf Of
> Geoff Canyon via use-livecode
> Sent: Wednesday, January 30, 2019 9:31 AM
> To: How to use LiveCode 
> Cc: Geoff Canyon 
> Subject: Re: Navigator 7.3rc1 is available
>
> On Wed, Jan 30, 2019 at 5:09 AM Clarence Martin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > Ji Geoff,
> > I am responding to you 7.3rc1 and this is probably true about the
> > other releases too.
> > I noticed that if I open a group in a New Navigator window, the first
> > Navigator window has lost control over the group that precipitated it.
> > The new Navigator Window Group items don't respond to any items that
> > are clicked or highlighted.
> > Also, if I open a group for editing, the Navigator window does not
> > respond to any items that are clicked or highlighted in the Group Edit
> window.
> > I can live with this now that I know  about this behavior, but I don't
> > know if anyone has pointed this out to you.
> >
>
> I'm not sure what you mean by "lost control". I followed these steps:
>
> 1. Created a Livecode window, added three buttons, and grouped them.
> 2. Opened Navigator. It shows the stack, the card, the group, and the three
> buttons.
> 3. Right-click on the group in Navigator, and select "Browse Controls" on
> the popup menu. Navigator shows the stack, the group, and the buttons.
> 4. Right-click the first button in Navigator and select Rename... on the
> popup menu. Navigator opens the dialog and I successfully rename the
> button.
> 5. Right-click the group in Navigator and select Open in New Navigator on
> the popup menu. Navigator opens a new window showing the same controls.
> 6. In the new Navigator, right-click the second button and select Rename...
> on the popup menu. Navigator opens the dialog and I successfully rename the
> button.
> 7. In the original Navigator, right-click the third button and select
> Rename... on the popup menu. Navigator opens the dialog and I successfully
> rename the button.
>
> So Navigator still knows what controls it's supposed to display, displays
> them, and works with them.
>
> Wait -- do you mean highlighting? As in, select controls in Navigator, and
> they become selected in Livecode, and vice versa? If so, that was
> originally
> a function of Navigator displaying "this card of the topstack"
> because it's impossible to select controls in a card that isn't being
> displayed. At some point there was a bug in Navigator where the code was
> trying to match highlights for anything displayed in Navigator. Any time
> the
> highlighting failed, Navigator's code would die silently because it's
> considered and IDE stack by the IDE. It didn't throw visible errors, but it
> means that any code after that doesn't get executed, so I fixed it to the
> way it was originally: if you select "the topstack" on the Target
> (crosshair) menu, Navigator will display whatever is frontmost in Livecode,
> and match highlights.
>
> I added this, in case you are talking about highlights:
> https://github.com/gcanyon/navigator/issues/32
>
> If that's not what you're talking about, let me know.
>
> thanks,
>
> gc
> ___
> 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: Navigator 7.3rc1 is available

2019-01-30 Thread Geoff Canyon via use-livecode
On Wed, Jan 30, 2019 at 5:09 AM Clarence Martin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Ji Geoff,
> I am responding to you 7.3rc1 and this is probably true about the other
> releases too.
> I noticed that if I open a group in a New Navigator window, the first
> Navigator window has lost control over the group that precipitated it.
> The new Navigator Window Group items don't respond to any items that are
> clicked or highlighted.
> Also, if I open a group for editing, the Navigator window does not respond
> to any items that are clicked or highlighted in the Group Edit window.
> I can live with this now that I know  about this behavior, but I don't know
> if anyone has pointed this out to you.
>

I'm not sure what you mean by "lost control". I followed these steps:

1. Created a Livecode window, added three buttons, and grouped them.
2. Opened Navigator. It shows the stack, the card, the group, and the three
buttons.
3. Right-click on the group in Navigator, and select "Browse Controls" on
the popup menu. Navigator shows the stack, the group, and the buttons.
4. Right-click the first button in Navigator and select Rename... on the
popup menu. Navigator opens the dialog and I successfully rename the button.
5. Right-click the group in Navigator and select Open in New Navigator on
the popup menu. Navigator opens a new window showing the same controls.
6. In the new Navigator, right-click the second button and select Rename...
on the popup menu. Navigator opens the dialog and I successfully rename the
button.
7. In the original Navigator, right-click the third button and select
Rename... on the popup menu. Navigator opens the dialog and I successfully
rename the button.

So Navigator still knows what controls it's supposed to display, displays
them, and works with them.

Wait -- do you mean highlighting? As in, select controls in Navigator, and
they become selected in Livecode, and vice versa? If so, that was
originally a function of Navigator displaying "this card of the topstack"
because it's impossible to select controls in a card that isn't being
displayed. At some point there was a bug in Navigator where the code was
trying to match highlights for anything displayed in Navigator. Any time
the highlighting failed, Navigator's code would die silently because it's
considered and IDE stack by the IDE. It didn't throw visible errors, but it
means that any code after that doesn't get executed, so I fixed it to the
way it was originally: if you select "the topstack" on the Target
(crosshair) menu, Navigator will display whatever is frontmost in Livecode,
and match highlights.

I added this, in case you are talking about highlights:
https://github.com/gcanyon/navigator/issues/32

If that's not what you're talking about, let me know.

thanks,

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


Navigator 7.3rc1 is available

2019-01-30 Thread Geoff Canyon via use-livecode
As usual, you can get Navigator here
. Or grab it
from GitHub .

Briefly this fixes an issue with folding when multiple targets are
displayed, and adds alignment and conformity tools to the Size/Location
editor. In particular, you can select any group of controls, and then
select any of those controls as the template to align the others to. So you
can right-align a bunch of controls to one of them that *isn't* the
right-most of them (if that's what you want to do). You can see it in
action in this video .

Fixes:
https://github.com/gcanyon/navigator/issues/29
https://github.com/gcanyon/navigator/issues/28
https://github.com/gcanyon/navigator/issues/30
https://github.com/gcanyon/navigator/issues/31

Addresses somewhat:
https://github.com/gcanyon/navigator/issues/23
___
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: Never, ever use the name of a built-in property as a custom property

2019-01-28 Thread Geoff Canyon via use-livecode
On Mon, Jan 28, 2019 at 11:49 AM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Yet even there you did a great job of rethinking the thing that handles
> the data, leaving the data free to be as free as data often is.
>

Thanks! It was a pain to format, but my recent-acquired awareness of the
merge command helped keep it from being a complete disaster.
___
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: Never, ever use the name of a built-in property as a custom property

2019-01-27 Thread Geoff Canyon via use-livecode
Sure, I'm not arguing for custom property sets -- just saying that if you
*are* going to use them, don't bork the naming convention.
___
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: Navigator 7.2rc1 is available

2019-01-27 Thread Geoff Canyon via use-livecode
7.2.1rc1 is available

There is now a checkbox in the prefs to fold dataGrids by default. Also, I
fixed the custom property editor to work even if custom properties have the
same name as built-in properties, updated the display of folded controls,
and updated Navigator's property editor to do a soft display update when
setting values, so changing the name of controls will be reflected when the
editor is closed.

Fixes:
https://github.com/gcanyon/navigator/issues/27
https://github.com/gcanyon/navigator/issues/26
https://github.com/gcanyon/navigator/issues/24

Updates:
https://github.com/gcanyon/navigator/issues/19

On Fri, Jan 25, 2019 at 9:13 PM Geoff Canyon  wrote:

> The fold control bar uses this stack as its behavior: stack
> "rev_g_groupFoldBar"
>
> That script is:
>
> on mouseUp
>put getID(barClickLine()) into CL
>if the number of lines of CL > 1 or word 1 of CL is not "group" then
> exit mouseUp
>setFolded CL
>doUpdateDisplay true
> end mouseUp
>
> So it's pretty much down to three things:
>
> 1.a. Does barClickLine() return the proper line?
> 1.b. Does getID() return the right ID? And is it the long ID?
> 2. Does setFolded work?
> 3. Does doUpdateDisplay do something to reset the folds before displaying?
> (This is what was wrong the last time).
>
> One thing to try would be this:
>
> dispatch "setFolded" to stack "revNavigator" with (the long id of  group navigator is displaying>),true
>
> Navigator won't immediately update its display, but clicking in
> Navigator's list or selecting Update List Now on the Action menu should do
> it, and then that group should be displayed folded. I just did this and it
> worked for me. If this works for you then we've narrowed the problem down
> to 1. If it doesn't work, then 2 or 3.
>
> gc
>
> On Fri, Jan 25, 2019 at 3:11 PM Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Nope. Running LC 9.0.2 Community, MacOS 10.14.2, Navigator 7.2 RC1. If
>> you point me to where the folding code actually happens, I can turn on rev
>> development and trace it.
>>
>> Bob S
>>
>>
>> > On Jan 25, 2019, at 14:16 , Geoff Canyon via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> >
>> > I'm not seeing this? I tried both with a specific stack and (what I
>> > remember from the last time) "this card of the topstack". Folding is
>> > working for me, both by clicking in the margin, and by selecting a fold
>> > level on the popup menu for a card or group.
>> >
>> > Any specific recipe?
>> >
>> > gc
>>
>>
>> ___
>> 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


Never, ever use the name of a built-in property as a custom property

2019-01-26 Thread Geoff Canyon via use-livecode
https://github.com/gcanyon/navigator/issues/27

I just found that Navigator breaks when editing the custom properties of
datagrids, because of the custom property dgProps["style"]. When I
originally added custom properties to the property editor in Navigator it
was simple: I pretty much had to add one line here and there, and I was
done. Namely:

  if the cCustomProperties of me is true
  then set the customPropertySet of tID to (the cCustomPropertySet of
me)

And then set the properties as usual. So easy. But setting the property
breaks if the custom property is "style", with the error that the object
doesn't have that property.

So now I'm spending time going through Navigator and replacing the above
with code like this:

 put value(merge("the [[pCustomPropertySet]][
[[quote]][[P]][[quote]]] of [[pID]]")) into pIDP

(if anyone has a cleaner solution, I'd love to hear it)

So: use unique names for your custom properties. Prefix them all with a "u"
as some people do, for example.

Or don't. Navigator's next update will accommodate you anyway.


___
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: Navigator 7.2rc1 is available

2019-01-25 Thread Geoff Canyon via use-livecode
The fold control bar uses this stack as its behavior: stack
"rev_g_groupFoldBar"

That script is:

on mouseUp
   put getID(barClickLine()) into CL
   if the number of lines of CL > 1 or word 1 of CL is not "group" then
exit mouseUp
   setFolded CL
   doUpdateDisplay true
end mouseUp

So it's pretty much down to three things:

1.a. Does barClickLine() return the proper line?
1.b. Does getID() return the right ID? And is it the long ID?
2. Does setFolded work?
3. Does doUpdateDisplay do something to reset the folds before displaying?
(This is what was wrong the last time).

One thing to try would be this:

dispatch "setFolded" to stack "revNavigator" with (the long id of ),true

Navigator won't immediately update its display, but clicking in Navigator's
list or selecting Update List Now on the Action menu should do it, and then
that group should be displayed folded. I just did this and it worked for
me. If this works for you then we've narrowed the problem down to 1. If it
doesn't work, then 2 or 3.

gc

On Fri, Jan 25, 2019 at 3:11 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Nope. Running LC 9.0.2 Community, MacOS 10.14.2, Navigator 7.2 RC1. If you
> point me to where the folding code actually happens, I can turn on rev
> development and trace it.
>
> Bob S
>
>
> > On Jan 25, 2019, at 14:16 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I'm not seeing this? I tried both with a specific stack and (what I
> > remember from the last time) "this card of the topstack". Folding is
> > working for me, both by clicking in the margin, and by selecting a fold
> > level on the popup menu for a card or group.
> >
> > Any specific recipe?
> >
> > gc
>
>
> ___
> 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: Navigator 7.2rc1 is available

2019-01-25 Thread Geoff Canyon via use-livecode
I'm not seeing this? I tried both with a specific stack and (what I
remember from the last time) "this card of the topstack". Folding is
working for me, both by clicking in the margin, and by selecting a fold
level on the popup menu for a card or group.

Any specific recipe?

gc

On Fri, Jan 25, 2019 at 1:32 PM Geoff Canyon  wrote:

> Bah, I’ll take a look later today.
>
> gc
>
> > On Jan 25, 2019, at 1:19 PM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Hate to do this to you Geoff but the groups are not folding again.
> >
> > I click in the shaded area nothing. I right click on the name of the
> group and select fold level 1, nothing.
> >
> > 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
>
___
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: Navigator 7.2rc1 is available

2019-01-25 Thread Geoff Canyon via use-livecode
Bah, I’ll take a look later today. 

gc

> On Jan 25, 2019, at 1:19 PM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Hate to do this to you Geoff but the groups are not folding again. 
> 
> I click in the shaded area nothing. I right click on the name of the group 
> and select fold level 1, nothing. 
> 
> 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

___
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

Navigator 7.2rc1 is available

2019-01-24 Thread Geoff Canyon via use-livecode
As usual, you can get Navigator here
. Or grab it
from GitHub .

For details read the release notes
, but briefly
this:

-- fixes the color sets being borked by an earlier release.
-- significantly improves the relayering code -- again.
-- -- It was a minor thing, but it should now be possible to have a group
be the topmost object, and drag a control below it in Navigator's list, and
have the control *not* placed into the group, which is now consistent with
the behavior in any other circumstance.
-- -- Also, there were circumstances where Navigator would start editing a
group to place a control into the group, and then fail, leaving the group
in edit mode. This should now be fixed.
-- -- Finally, the relayering code has again been simplified. Details below
if anyone is curious -- it's weird.

If you find any bugs, file them here
.



To achieve uniform behavior with the simplest code, here are (most of) the
relayering steps in pseudo LC:

set relayergroupedcontrols to true
set layer to 1 -- this gets the control out of any groups it is in
set relayergroupedcontrols to false
set layer to 999 -- the control is now at the highest level
if target is group then
   set relayergroupedcontrols to true
   set the layer to 1 + the layer of the target group -- the control is now
in the group
   set relayergroupedcontrols to false
   start editing group
   set layer to 999 -- the control is now at the highest level of the
group
end if
if targetobject is not empty -- the object to place the control just under
-- if empty, the control should remain at the top
then set the layer to the layer of the targetobject -- works whether
editing a group or not
if target is group
then stop editing group -- need to make sure to use a "background"
reference

This doesn't include the logic for using the option key to move/copy if the
control is from another card, or duplicate/move if from the same card.

Also important to use simple references that don't include the full
hierarchy of groups, since that will fail while editing a group.
___
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: Us and them? [was Re: Livecode Dictionary]

2019-01-24 Thread Geoff Canyon via use-livecode
On Thu, Jan 24, 2019 at 12:36 AM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> When I forked it I returned to a
> editor separate from a debugger, each purpose-built for the task they do
>

YES. If I had a nickel for every time I expand the variable list while in
the debugger, then shrink back that section while editing a script. If
there is an easy recipe for automating this, anyone, please share. Or how
hard is it to set up to edit scripts with an external editor, and maybe
just debug with the built-in?
___
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: Can a substack become the mainstack and the mainstack become its substack?

2019-01-20 Thread Geoff Canyon via use-livecode
If your goal is GitHub, then you definitely want script-only stack
behaviors, and you should check out either Brian's ScriptTracker
 or my
Navigator  (nearly up-to-date
documentation specific to converting to script-only stack behaviors with
Navigator is here
).

On Sun, Jan 20, 2019 at 7:00 PM Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Geoff, doing the sub-stacks first did the trick.  All seems to work
> well.
>
> Thanks Brian for the suggestion, I will check it out.
>
> The point of this was to be able to put my project on github and view code
> as text. I was just unable to set the script of my main stack which has all
> the code on it. The splash screen/stack does the job, enables me to load
> scripts and apply them from external files before the other stacks open and
> run.
>
> Cheers & thank you.
>
>
>
>
>
> On Sun, Jan 20, 2019 at 9:12 PM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > You should be able to use Navigator to scriptify if that is what you
> > want.  I’m not sure that a splash would be needed.
> >
> > If you just want the scripts as text files for version control, you could
> > also try my ScriptTracker.
> >
> > Thanks,
> > Brian
> > On Jan 20, 2019, 7:25 PM -0600, Tom Glod via use-livecode <
> > use-livecode@lists.runrev.com>, wrote:
> > > Hi Geniuses,
> > >
> > > I have a rather complicated application which I put on a mainstack with
> > > many cards etc.
> > >
> > > I now realize I need a splash stack so that I can set the script of my
> > > application stack and its cards (for version control purposes).
> > >
> > > Is there a way to turn my mainstack into a substack? so that the first
> > > stack that loads is not my main application stack?
> > >
> > > Is there another way of accomplishing the same thing? I want to load
> > > scripts on startup from text files.
> > >
> > > Thanks,
> > >
> > > Tom
> > > ___
> > > 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: Can a substack become the mainstack and the mainstack become its substack?

2019-01-20 Thread Geoff Canyon via use-livecode
Sure, just create the stack you want to use as the splash screen, and then
set the mainstack of the current mainstack to the splash screen stack. I
think this will fail if the mainstack has substacks of its own. So first
change the substacks, then the mainstack. And if you are depending on the
substacks being able to reference handlers/functions in the (current)
mainstack, either move the handlers and functions to the new mainstack, or
convert to a behavior stack and use that for everything.

gc

On Sun, Jan 20, 2019 at 5:25 PM Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Geniuses,
>
> I have a rather complicated application which I put on a mainstack with
> many cards etc.
>
> I now realize I need a splash stack so that I can set the script of my
> application stack and its cards (for version control purposes).
>
> Is there a way to turn my mainstack into a substack? so that the first
> stack that loads is not my main application stack?
>
> Is there another way of accomplishing the same thing? I want to load
> scripts on startup from text files.
>
> Thanks,
>
> Tom
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Livecode Dictionary

2019-01-20 Thread Geoff Canyon via use-livecode
On Sun, Jan 20, 2019 at 12:07 PM Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> The permissions are over the top, but not intentional I am sure.
>

Agreed. I'm just waiting to see if:

1. My changes go in with the current state of affairs.
2. Someone from LC re-ups their cert, and hopefully with more reasonable
requirements.
3. Nothing happens.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Livecode Dictionary

2019-01-20 Thread Geoff Canyon via use-livecode
On Sun, Jan 20, 2019 at 6:47 AM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> LiveCode can’t use your contribution without the CLA.  Someone from LC May
> need to clarify the details.  Since they release code as GPL and
> Commercial, we need to assign copyright to them for any changes we make and
> also assert that we are not introducing code where we are not able to
> assign said copyright.
>
> As long as GitHub can’t verify the CLA, I don’t think the PR can move
> forward.
>
> Thanks,
> Brian
>

Again, not that I actually ascribe bad motives to the LC crew, but it seems
excessive to want write access to my profile.

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

Re: Livecode Dictionary

2019-01-20 Thread Geoff Canyon via use-livecode
On Sun, Jan 20, 2019 at 6:10 AM Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> The newsletter also lists documentation bugs which need fixing. Here is a
> link to the latest edition:
>
>
> https://livecode.github.io/this-week-in-livecode/issue/2019/01/14/this-week-in-livecode-163.html


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


Re: Livecode Dictionary

2019-01-19 Thread Geoff Canyon via use-livecode
On Sat, Jan 19, 2019 at 8:22 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I agree that the dictionary isn’t the easiest to update without a GutHib
> client, but dictionary updates can be done completely in a browser.


Yep, I figured that out after I spent several minutes looking for the
dictionary data and poking through the dictionary stack. I already cloned
LiveCode some time ago, and GitHub was smart enough to realize that even
though my clone is substantially out of date, the merge entry hasn't
changed. So all i had to do was find it, edit (my copy of) it, save, and
issue a pull request.

And then notice a few minutes later that LC was asking me to sign the
waiver and tie my accounts together. I've done everything but that last
bit, so we'll see what happens.

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

Re: Livecode Dictionary

2019-01-19 Thread Geoff Canyon via use-livecode
On Sat, Jan 19, 2019 at 8:11 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Interesting.  I just checked on GitHub and the oauth token for LiveCode
> was recently revoked automatically since it was not used.  It’s been quite
> a while since I did it and I can’t recall about having write access.  There
> are several apps that I still have linked (Hacktoberfest...).
>
> Thanks,
> Brian
>

If the token has been revoked, I wonder if the process would have failed if
I had said yes? Now I'm tempted to say yes just to find out -- I said no
more on principle than on any concern that LC would actually do anything
harmful on my behalf.

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

Re: Livecode Dictionary

2019-01-19 Thread Geoff Canyon via use-livecode
So I have to sign an agreement -- I thought I had, but I have now.

And I have to link my LiveCode account and my GitHub account, meaning LC
can read and write all user data, including private email addresses,
private profile information, and followers. Is that really necessary?

gc


On Sat, Jan 19, 2019 at 6:59 PM Geoff Canyon  wrote:

> 1. Not everyone (very few people?) understand how git/GitHub works.
> 2. Even if you have a reasonable grasp of how to use git it's not obvious
> how to contribute to the dictionary using git. I've maintained Navigator in
> git/GitHub for about a year, and I'm sure I don't know the detailed steps
> -- just the general sense of "clone the repository, make changes to the
> dictionary, do a pull request." I just gave this a shot (pull request
> ) for the
> thinly-documented merge function. We'll see if I did it right.
>
> As an aside, I just checked, and the dictionary is now just two widgets?
> It seems counterproductive and unnecessary to convert the dictionary to
> widgets. There's no special functionality needed(?). And the dictionary
> functionality is now expressly beyond the ability of a large portion of the
> community to contribute to.
>
> gc
>
> On Sat, Jan 19, 2019 at 8:55 AM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> We have an even better option now.  Contributions to the actual
>> dictionary can be submitted via GitHub.
>>
>> Thanks,
>> Brian
>> On Jan 19, 2019, 9:48 AM -0600, Richmond via use-livecode <
>> use-livecode@lists.runrev.com>, wrote:
>> > Some of those user entries were extremely useful.
>> >
>> > It would be good if user entries could be restored to the dictionary
>> > once again.
>> >
>> > Richmond.
>> >
>> > On 19.01.19 9:49, Simon Knight via use-livecode wrote:
>> > > Hi all,
>> > >
>> > > I have just read about two “issues” and both would be resolved or at
>> least helped with a more detailed dictionary entry. Now in the dim distant
>> past the RunRev dictionary use to allow humble users to add comments and
>> examples which I for one found useful. Does anyone know why this useful
>> feature was removed? Security ?
>> > >
>> > >
>> > >
>> > > Simon Knight
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > ___
>> > > 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: Livecode Dictionary

2019-01-19 Thread Geoff Canyon via use-livecode
1. Not everyone (very few people?) understand how git/GitHub works.
2. Even if you have a reasonable grasp of how to use git it's not obvious
how to contribute to the dictionary using git. I've maintained Navigator in
git/GitHub for about a year, and I'm sure I don't know the detailed steps
-- just the general sense of "clone the repository, make changes to the
dictionary, do a pull request." I just gave this a shot (pull request
) for the thinly-documented
merge function. We'll see if I did it right.

As an aside, I just checked, and the dictionary is now just two widgets? It
seems counterproductive and unnecessary to convert the dictionary to
widgets. There's no special functionality needed(?). And the dictionary
functionality is now expressly beyond the ability of a large portion of the
community to contribute to.

gc

On Sat, Jan 19, 2019 at 8:55 AM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> We have an even better option now.  Contributions to the actual dictionary
> can be submitted via GitHub.
>
> Thanks,
> Brian
> On Jan 19, 2019, 9:48 AM -0600, Richmond via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
> > Some of those user entries were extremely useful.
> >
> > It would be good if user entries could be restored to the dictionary
> > once again.
> >
> > Richmond.
> >
> > On 19.01.19 9:49, Simon Knight via use-livecode wrote:
> > > Hi all,
> > >
> > > I have just read about two “issues” and both would be resolved or at
> least helped with a more detailed dictionary entry. Now in the dim distant
> past the RunRev dictionary use to allow humble users to add comments and
> examples which I for one found useful. Does anyone know why this useful
> feature was removed? Security ?
> > >
> > >
> > >
> > > Simon Knight
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > 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: The merge function is redundant?

2019-01-18 Thread Geoff Canyon via use-livecode
There's some overlap, but merge has (at least) one feature that put
doesn't: the ability to run code within its statement. A simple example:

put merge("The coin came up .")

The equivalent might be:

put "The coin came up" && item random(2) of "heads,tails" & "."

But consider this:

   put 10 into myVar
   put merge("The sum of the numbers from 1 to [[myVar]] is .")

There is no way to do that with a simple "put". You could unroll the code,
but for instances like what I'm planning to do with Navigator, that would
be totally unworkable.
___
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 merge function is awesome!

2019-01-18 Thread Geoff Canyon via use-livecode
On Fri, Jan 18, 2019 at 3:23 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2019-01-18 06:48, Geoff Canyon via use-livecode wrote:
> > I was in the same position with merge(). If you haven't seen it
> > already,
> > format() has some pretty amazing capabilities as well.
>
> To answer your question about escaping - yes there is:
>
>[[[]] -> [
>[[]]] -> ]
>

Ha, so my string ends up as:

[[the name of tID]] - [[[]][[the id of tID]][[]]]

That's a lot of square brackets!


> Also the merge function has another feature (which I think was actually
> undocumented for a long time - although, for once, it is there now!):
>
>1) "[[ 1 + 2 ]]" -> 3 (function / expression evaluation)
>2) "" ->
> (command / statement evaluation)
>
> Basically (1) does the equivalent of 'value()' on the string enclosed in
> [[ / ]]; whilst (2) does the equivalent of 'do 

Re: The merge function is awesome!

2019-01-17 Thread Geoff Canyon via use-livecode
On Thu, Jan 17, 2019 at 2:27 PM Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 6 years with LC...never used the value or merge commands . never even
> came across them.
>
> mind blown.
>

I was in the same position with merge(). If you haven't seen it already,
format() has some pretty amazing capabilities as well.
___
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 merge function is awesome!

2019-01-17 Thread Geoff Canyon via use-livecode
On Thu, Jan 17, 2019 at 11:01 AM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Geoff wrote:
> > ... you've just given me an idea how to handle things like font/styling
> > tags. Something like:
> > function ifTag b,o,s,c
> > if b then return o & s & c else return s
> > end ifTag
>
> Allow me two remarks.
>
> 1. You could use, in order to avoid the check:
>
> function tag s,o,c
> return o & s & c
> end tag
>
> And both, tag("inner") and tag("inner","left-","-right") work.
>

I'm thinking about situations where the tags are optional, so something
like:

ifTag(word 1 of tID is "group","",the name of tID,"")

I'd have to do a timing test to see whether it's more costly to do the
function call or perform the test twice. And of course in this instance it
would be easy enough to simply use:

", & the name of tID & ""
else return the name of tID?>

But it would become unwieldy for more complex strings.

>
> 2. Also array-things work with merge, like [[a[1]]].
>

Yep, definitely planning to take advantage of this if possible:
https://github.com/gcanyon/navigator/issues/21
___
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 merge function is awesome!

2019-01-17 Thread Geoff Canyon via use-livecode
On Thu, Jan 17, 2019 at 4:36 AM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Geoff wrote:
> > using value():
> > the name of tID && "[" & the id of tID & "]"
> > using merge():
> > [[the name of tID]] - ([[the id of tID]])
> > (is there a way to escape the "["?)
>
> You could use with merge not only variables but also functions
> that are available for the script that calls merge:
>
> [[br(the id of tID)]]
>
> function br x
>   return "[" & x & "]"
> end br
>

True, and you've just given me an idea how to handle things like
font/styling tags. Something like:

function ifTag b,o,s,c
if b then return o & s & c else return s
end ifTag
___
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


The merge function is awesome!

2019-01-16 Thread Geoff Canyon via use-livecode
In Navigator I use the value() function in several ways. In particular, I
use it as a way for users to customize Navigator's list display. For some
reason I've managed to go all these years blissfully unaware of the merge()
function, which is seemingly superior to value() for this purpose in pretty
much every way. A few examples:

Using value() I use the string "tID" to represent the long id of the
control being represented. In retrospect I should have used value(,) which would allow the user to use "me". But I didn't
think of that when I first created the functionality, or really until just
a few minutes ago, but even so, the most basic displays are about
equivalent:

To display:
button "Cancel" - [1150]

using value():
the name of tID && "[" & the id of tID & "]"

using merge():
[[the name of tID]] - ([[the id of tID]])
(is there a way to escape the "["?)

The merge() call is cleaner, because it inherently has access to the tID
variable; for value() I have to replace "tID" with the long id before using
value().

For value(), I implemented a special iff() function, so I could do
conditionals inline. The drawback is that both of the return values get
implemented before being handed to the function, so this will fail:

get iff(1+1=2,"true",3/0) -- fails even though the value 3/0 isn't needed.

To work around that, I came up with the function iffv(), which takes
strings and then returns the value of only the necessary string. So this
will work:

get iffv("1+1=2","true","3/0") -- succeeds because the function does not
perform value("3/0")

But the syntax for that quickly becomes unwieldy. Instead, merge() supports
executing arbitrary code within it, so to display a control and its
behavior:

button "Cancel" | stack "rev_b_Cancel 5"

using value():
the name of tID & iffv(the behavior of tID is not empty,Q(" | ") && "&" &&
"the name of the behavior of" && the long id of tID,"")

using merge():
[[the name of tID]]

That's a lot simpler!

Merge is also possibly going to allow me to pre-calculate a single large
merge string and then use that to generate the entire HTMLtext for
Navigator's display.
___
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: Navigator 7.1rc1 is available

2019-01-15 Thread Geoff Canyon via use-livecode
Navigator edits custom properties in its standard editor, which resizes to
as big as you make Navigator -- so as big as you like, really.

But the custom list string editor is for Navigator's own custom list
display strings. Navigator has a number of built-in display options,
including the object name, name and id, and several others. But Navigator
can also take any custom string that will be accepted by LC's value()
function. Some interesting options:

the layer of tID && the name of tID
-- "tID" gets replaced with the long id of the control. This string will
result in numbering the controls displayed

the layer of tID && tIS & "" & toUpper(char 1 of the name of tID) &
""&& Q(the short name of tID) && "loc:" && the loc of tID
-- "tIS" gets replaced with the indent string. This string will result in
numbering on the left, then the indent string, then a single letter in bold
representing the control type, then the name and location of the control.
Like this:

1 *B*"Cancel" loc: 681,572

2 *B*"Save" loc: 766,572

3 *G*"group id 1148" loc: 423,346

4 | *F*"edit list string" loc: 423,359

And based on a recent request, this string:

iff(word 1 of the long id of tID is "group","","") & the name of tID && "-" && the id of tID &
iff(word 1 of the long id of tID is "group","","")

-- iff() is a function included in Navigator that performs and "if"
statement in a function: if the first argument is true, then it results in
the second argument. If not, it results in the third argument. So this list
string results in groups being bold and salmon-colored, like this:

button "Cancel" - 1150

button "Save" - 1135

*group id 1148 - 1148*

| field "edit list string" - 1133

regards,

Geoff

On Tue, Jan 15, 2019 at 11:01 AM Sannyasin Brahmanathaswami via
use-livecode  wrote:

> Kudo from making group layering consistent/doable!
>
> ?
> =
>  CUSTOM LIST STRINGS EDITOR
> This update adds an editor for custom list strings.
> ==
>
> "Custom list strings"
>
> what is it?
>
> A "custom property which is a string" ?
>
> If so, that huge, the IDE, Project Inspector give us a custom property
> value editor field with just 4 line...'s and no re-sizing option.
>
> Sheesh, do you want to  edit a long list cities name, or a big JSON
> property with only 4 lines
>
> BR
>
> ==
> Geoff Canyon
>
> As usual, you can get Navigator here
> . Or
> grab it
> from GitHub .
>
>
>
> ___
> 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


Navigator 7.1rc1 is available

2019-01-12 Thread Geoff Canyon via use-livecode
As usual, you can get Navigator here
. Or grab it
from GitHub .

Also, as part of this update I created several new scripts. I recorded my
screen while using Navigator to convert those scripts to behaviors. It's
super-easy, and the video only runs a minute-twenty. Find out how easy it is
!

For details read the release notes
,
but briefly this:

-- fixes the prefs file not saving.
-- fixes the card popup menu not including a fold-level menu.
-- significantly improves the relayering code. In particular, relayering
groups works properly now.
-- adds an editor for custom list strings, with a preview so you can see if
your string will work and what it will look like.

If you find any bugs, file them 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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-04 Thread Geoff Canyon via use-livecode
Wow, that's a lot of information you're displaying -- have you noticed any
hit on Navigator's display performance?

Also, couldn't you replace

the left of tID & "," & the top of tID & "," & the right of tID & ","
& the bottom
of tID

with

the rect of tID

?

On Fri, Jan 4, 2019 at 8:02 PM pink via use-livecode <
use-livecode@lists.runrev.com> wrote:

> >
> > 1.  One thing I would love to do is assign different commands to the
> > "Command Bars", I've been going through the source code and haven't
> > figured
> > out where this happens...
> >
>
> I obviously need to do better here: just right-click/control-click a
> command bar. The pop-up menu lets you select any existing command to assign
> to that command bar. You can create new named commands by selecting New
> Command... at the top of the menu. Note: I just now noticed that you have
> to have at least one control selected for this to work. I'll fix that in an
> update.
>
> EXCELLENT!
>
> >
> > 2.  Another feature request would be to assign a different color for
> > groups
> > (and folded group contents)
> >
>
> I thought about this, but I thought the overall "color things based on
> whether they have a script/behavior" was more important, but I'll take a
> look and see how tough this would be to work in.
>
> --Ultimately, a user can get around it by using the same color if they
> don't
> want to distinguish between certain things... I use the same color for with
> or without a script
>
> >
> > 3.  it seems as though all controls in a card are being indented... was
> it
> > always like that?
> >
>
> Good eye -- no, they weren't before, but I added that additional level of
> indent because of allowing multiple targets. It would be easy enough to
> undo depending on the consensus opinion.
>
> --I would prefer not to have the extra indent, but it's not a dealbreaker
> or
> anything :P
>
> >
> > 4.  it would be nice if there were an easier way to clean up the List
> > Display String list... as far as I can tell the only way is to manually
> > edit
> > the prefs file
> >
>
> Definitely agreed, it was just the lack of/need for interface inspiration
> and a desire to work on something else/laziness. But yes, editing the prefs
> is the only way at present to clean up the list display list.
>
> --I had A LOT to clean up, each addition to my line just made it
> exponentially larger...
>
> iff(the vis of tID,"","hid") & iff(char 1 to 5 of the name of tID is
> "group","---grp ---" & the short name of tID & "---",toUpper(char 1 of the
> name of tID) && the short name of tID) && "id[" & the short ID of tID & "]"
> && the height of tID & "x" & the width of tID && the mpDevNotes of tID &&
> the left of tID & "," & the top of tID & "," & the right of tID & "," & the
> bottom of tID & "/" & the layer of tID
>
> >
>
>
>
> -
> ---
> Greg (pink) Miller
> mad, pink and dangerous to code
> --
> Sent from:
> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
>
> ___
> 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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-04 Thread Geoff Canyon via use-livecode
Answers inline:

On Fri, Jan 4, 2019 at 5:06 AM pink via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I love this plugin... one of my top 3 favorites
>
> Here's my wishlist:
>
> 1.  One thing I would love to do is assign different commands to the
> "Command Bars", I've been going through the source code and haven't figured
> out where this happens...
>

I obviously need to do better here: just right-click/control-click a
command bar. The pop-up menu lets you select any existing command to assign
to that command bar. You can create new named commands by selecting New
Command... at the top of the menu. Note: I just now noticed that you have
to have at least one control selected for this to work. I'll fix that in an
update.


>
> 2.  Another feature request would be to assign a different color for groups
> (and folded group contents)
>

I thought about this, but I thought the overall "color things based on
whether they have a script/behavior" was more important, but I'll take a
look and see how tough this would be to work in.

>
> 3.  it seems as though all controls in a card are being indented... was it
> always like that?
>

Good eye -- no, they weren't before, but I added that additional level of
indent because of allowing multiple targets. It would be easy enough to
undo depending on the consensus opinion.

>
> 4.  it would be nice if there were an easier way to clean up the List
> Display String list... as far as I can tell the only way is to manually
> edit
> the prefs file
>

Definitely agreed, it was just the lack of/need for interface inspiration
and a desire to work on something else/laziness. But yes, editing the prefs
is the only way at present to clean up the list display list.

>
>
>
>
>
> -
> ---
> Greg (pink) Miller
> mad, pink and dangerous to code
> --
> Sent from:
> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
>
> ___
> 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: Refactoring is your friend / moving from 6.x to 9.x

2019-01-03 Thread Geoff Canyon via use-livecode
I wasn't sure what people were talking about with lock screen performance
issues, so I did a simple test: I set up a button to either lock the screen
once, or twice, and then timed setting the loc of the button while the
screen was locked. I didn't time locking the screen; just the movement
while locked. As I hoped, I didn't find any difference between locking once
or twice, either in 6.7.3, or in 9.0.1 (on an up-to-date Mac).

But...

There was a significant performance difference between 6.7.3 and 9.0.1.
*Maybe* this is Unicode related? In any case, this script takes about 0.04
seconds in 6.7.3, and 0.24 seconds in 9.0.1:

on mouseUp
   put the loc of me into L1
   put L1 into L2
   lock screen
   put the long seconds into T
   repeat 10
  set the loc of me to L2
  set the loc of me to L1
   end repeat
   put the long seconds - T into T
   unlock screen
   put T
end mouseUp

Then I noticed that I had forgotten one line of code. I changed it to this:

on mouseUp
   put the loc of me into L1
   put L1 into L2
   add 100 to item 1 of L2
   lock screen
   put the long seconds into T
   repeat 10
  set the loc of me to L2
  set the loc of me to L1
   end repeat
   put the long seconds - T into T
   unlock screen
   put T
end mouseUp

...and found that in 6.7.3 that change increased the duration to about 1.25
seconds -- a performance hit of about 30x just because a locked-screen
button is actually moving. In 9.0.1, the time changed to about 0.35
seconds. So if the button *isn't* moving, 6.7.3 is much faster, but in the
more practical and likely case that the button *is* moving, 9.0.1 is
faster. So ¯\_(ツ)_/¯


On Thu, Jan 3, 2019 at 11:03 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Read through this whole thread, optimistic that I'd find the list of
> things that differentiate v6 and v9 so we can hone in on actual solutions.
>
> I learned two things:
>
>   - lock/unlock changed
>
>   - It's apparently easier to write a thousands of words philosophizing
> about how a small team of C++ programmers should provide a uniform
> scripting interface for a nearly unprecedented number of OSes,
> stay on top of ongoing API changes in every one of those OSes,
> multiply features, fix bugs, incorporate Unicode, maintain or improve
> all aspects of performance, and keep the joint running than it is to
> even briefly summarize concerns about any of the above.
>
> Is there an actual list of concrete concerns here that the team may be
> able to take action on or at least explain how/why the change exists, or
> did I just spend an hour reading that I'll never get back?
>
> I feel rickrolled.
>
>
> I've worked with too many people moving from Drupal 7 to Drupal 8, or
> Python 2 to 3, or any version of Apple's C headers in the '90s that
> broke declarations quarterly, or HyperCard 2 to 3, to get too
> out-of-breath about undoing workarounds in old code to work
> with-the-grain for v9's enhancements and fixes for long-standing
> anomalies.  When I describe LC's high priority for backward
> compatibility to nearly any other experienced dev I know, they look at
> me like I'm high and spouting tales of dancing ponies; many professional
> development systems consider backward compatibility a very minor
> nice-to-have, if they devote time to it at all. Many of us here buy
> computers from a hardware vendor with a similar view.
>
> As for performance, in threads with Geoff Canyon, Mark Talutto, and
> others who provided real-world use cases and metrics, we do see some
> performance degradation in v9 from v6 in some cases, a surprising amount
> on par given how relatively little work v6 had to do under the hood with
> encodings and types, a few things a wee bit faster, and overall such a
> strong comeback from the v7 series that it should be clear to those
> earnestly following along that the team has indeed been quite evidently
> working on performance, and delivering improvements over the v9 cycle.
>
> Then again, my work may not touch the items on the concern list.  I
> can't know, because I couldn't find such a list in this long thread.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-03 Thread Geoff Canyon via use-livecode
This is fixed in 7.0.2 rc1. I had a variable where I was tracking
containers that had already been "default-folded" and I wasn't setting it
properly, so every time the display refreshes, it got the default fold.

As usual, you can get Navigator here
<https://www.dropbox.com/s/kz3zqi4botzglgq/navigator.zip?dl=1>. Or grab it
from GitHub <https://github.com/gcanyon/navigator>.

On Thu, Jan 3, 2019 at 9:55 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Folding seems to have broken. I cannot fold or unfold but the default
> folding is in effect.
>
> Bob S
>
>
> > On Jan 2, 2019, at 14:17 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > As usual, you can get Navigator here
> > <https://www.dropbox.com/s/kz3zqi4botzglgq/navigator.zip?dl=1>. Or grab
> it
> > from GitHub <https://github.com/gcanyon/navigator>.
> 
> ___
> 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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-03 Thread Geoff Canyon via use-livecode
Okay, that should be easy enough -- I just didn't see the need personally,
and it will require code that is different than the regular
drag/drop/relayering code, so I hadn't bothered.

gc

On Thu, Jan 3, 2019 at 2:55 PM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Geoff C. wrote:
> > So you want drag and drop in the stack list to reorder the windows?
> > What's the purpose? To bring a particular stack to the foreground?
>
> What others do with the "z-index". Or what we can do with setting the
> layer of card controls (no only setting the layer of a control to "top").
> Stack windows can be partially transparent. So it makes sense to set
> the whole layering of the windows, not only to set the front window...
>
> ___
> 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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-03 Thread Geoff Canyon via use-livecode
Can you give me more specifics? Folding is working for me:
https://www.youtube.com/watch?v=x-_nLJNJvpM=youtu.be

On Thu, Jan 3, 2019 at 9:55 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Folding seems to have broken. I cannot fold or unfold but the default
> folding is in effect.
>
> Bob S
>
>
> > On Jan 2, 2019, at 14:17 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > As usual, you can get Navigator here
> > <https://www.dropbox.com/s/kz3zqi4botzglgq/navigator.zip?dl=1>. Or grab
> it
> > from GitHub <https://github.com/gcanyon/navigator>.
> 
> ___
> 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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-03 Thread Geoff Canyon via use-livecode
So you want drag and drop in the stack list to reorder the windows? What's
the purpose? To bring a particular stack to the foreground?

On Thu, Jan 3, 2019 at 4:38 AM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> > Geoff C. wrote:
> > Let me know if there's anything still missing.
>
> A reordering in the stacks list that sets the window layering?
> (What a simple go to stack from last line down to first line does).
>
>
> ___
> 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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-02 Thread Geoff Canyon via use-livecode
Glad to help. Let me know if there's anything still missing.

On Wed, Jan 2, 2019 at 2:53 PM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This is (not only now) a real comfortable developer tool.
> Especially when starting a project the new features are very effective.
> Thanks for 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
>
___
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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-02 Thread Geoff Canyon via use-livecode
On Wed, Jan 2, 2019 at 5:04 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 1/2/19 2:30 PM, Geoff Canyon via use-livecode wrote:
> > Ha, I knew that to a select subset of people this would be the most
> > important feature of the update :-)
>
> Heh. Yeah, I've backburned for now a talk entitled "Global Variables and
> Their Discontents"
>

The last remaining global variable in Navigator is on my short list for
removal. It will be easy relative to the others that are already gone, it
just wasn't critical to the current update, and I didn't realize it was the
last one until last night.
___
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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-02 Thread Geoff Canyon via use-livecode
Ha, I knew that to a select subset of people this would be the most
important feature of the update :-)

On Wed, Jan 2, 2019 at 2:28 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 1/2/19 2:25 PM, Geoff Canyon via use-livecode wrote:
> > I also got rid of all but one of the global variables Navigator has used
> > since the very first version.
>
> Yay!
>
> --
>   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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-02 Thread Geoff Canyon via use-livecode
I forgot -- I made a video illustrating how the new features work. Here it
is: https://www.youtube.com/watch?v=B1_avMJnZ6k

On Wed, Jan 2, 2019 at 2:25 PM Geoff Canyon  wrote:

> I also got rid of all but one of the global variables Navigator has used
> since the very first version. I had tried in the past to do away with them,
> and failed miserably. But now they are vanquished!
>
> On Wed, Jan 2, 2019 at 2:17 PM Geoff Canyon  wrote:
>
>> As usual, you can get Navigator here
>> . Or grab
>> it from GitHub .
>>
>> Navigator now supports multiple targets per window. You can still have as
>> many Navigator windows as you like, but now each window can display the
>> controls for any set of cards and groups.
>>
>> Select multiple stacks in the stack list, then right-click and select
>> browse controls, and Navigator will display all of the stacks in the same
>> list.
>>
>> In any display, select any combination of cards and groups. Right-click
>> and select browse controls, and Navigator will display all of the
>> containers in the same list.
>>
>> In any command that sets the target for Navigator, hold down the Shift
>> key to add to the target list instead of replacing it.
>>
>> To remove a container from the list, right-click the container and select
>> Stop Browsing from the popup menu. Navigator will remove the container from
>> the display while retaining the others in the list.
>>
>> Creating Navigator 7 required completely reworking how Navigator relayers
>> controls, which resulted in several improvements. First, if you drag a
>> control beneath a group, Navigator is now able to relayer the control
>> properly, without forcing it into the group. You can still drag controls
>> into and out of groups. And if you drag a grouped control to the bottom of
>> the group, it will remain in the group.
>>
>> The new relayering code is smart about whether to move or duplicate
>> controls. Even if there are two representations of a container in the list,
>> dragging a control from one to the other will simply relayer the control
>> without duplicating it. Of course dragging a control from one container to
>> another will duplicate it.
>>
>> Holding the option key reverses this behavior: if you hold the option key
>> while dragging a control within its container, the control will be
>> duplicated. And if you hold the option key while dragging a control to a
>> different container, the control will be moved to the new location, and
>> removed from the original.
>>
>> I also updated the target crosshair so selecting an IDE stack will only
>> work if "Show IDE Stacks" is selected in the target menu.
>>
>> I look forward to your feedback!
>>
>
___
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: Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-02 Thread Geoff Canyon via use-livecode
I also got rid of all but one of the global variables Navigator has used
since the very first version. I had tried in the past to do away with them,
and failed miserably. But now they are vanquished!

On Wed, Jan 2, 2019 at 2:17 PM Geoff Canyon  wrote:

> As usual, you can get Navigator here
> . Or grab
> it from GitHub .
>
> Navigator now supports multiple targets per window. You can still have as
> many Navigator windows as you like, but now each window can display the
> controls for any set of cards and groups.
>
> Select multiple stacks in the stack list, then right-click and select
> browse controls, and Navigator will display all of the stacks in the same
> list.
>
> In any display, select any combination of cards and groups. Right-click
> and select browse controls, and Navigator will display all of the
> containers in the same list.
>
> In any command that sets the target for Navigator, hold down the Shift key
> to add to the target list instead of replacing it.
>
> To remove a container from the list, right-click the container and select
> Stop Browsing from the popup menu. Navigator will remove the container from
> the display while retaining the others in the list.
>
> Creating Navigator 7 required completely reworking how Navigator relayers
> controls, which resulted in several improvements. First, if you drag a
> control beneath a group, Navigator is now able to relayer the control
> properly, without forcing it into the group. You can still drag controls
> into and out of groups. And if you drag a grouped control to the bottom of
> the group, it will remain in the group.
>
> The new relayering code is smart about whether to move or duplicate
> controls. Even if there are two representations of a container in the list,
> dragging a control from one to the other will simply relayer the control
> without duplicating it. Of course dragging a control from one container to
> another will duplicate it.
>
> Holding the option key reverses this behavior: if you hold the option key
> while dragging a control within its container, the control will be
> duplicated. And if you hold the option key while dragging a control to a
> different container, the control will be moved to the new location, and
> removed from the original.
>
> I also updated the target crosshair so selecting an IDE stack will only
> work if "Show IDE Stacks" is selected in the target menu.
>
> I look forward to your feedback!
>
___
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


Navigator 7.0.1rc1 is available -- Multi-target windows!

2019-01-02 Thread Geoff Canyon via use-livecode
As usual, you can get Navigator here
. Or grab it
from GitHub .

Navigator now supports multiple targets per window. You can still have as
many Navigator windows as you like, but now each window can display the
controls for any set of cards and groups.

Select multiple stacks in the stack list, then right-click and select
browse controls, and Navigator will display all of the stacks in the same
list.

In any display, select any combination of cards and groups. Right-click and
select browse controls, and Navigator will display all of the containers in
the same list.

In any command that sets the target for Navigator, hold down the Shift key
to add to the target list instead of replacing it.

To remove a container from the list, right-click the container and select
Stop Browsing from the popup menu. Navigator will remove the container from
the display while retaining the others in the list.

Creating Navigator 7 required completely reworking how Navigator relayers
controls, which resulted in several improvements. First, if you drag a
control beneath a group, Navigator is now able to relayer the control
properly, without forcing it into the group. You can still drag controls
into and out of groups. And if you drag a grouped control to the bottom of
the group, it will remain in the group.

The new relayering code is smart about whether to move or duplicate
controls. Even if there are two representations of a container in the list,
dragging a control from one to the other will simply relayer the control
without duplicating it. Of course dragging a control from one container to
another will duplicate it.

Holding the option key reverses this behavior: if you hold the option key
while dragging a control within its container, the control will be
duplicated. And if you hold the option key while dragging a control to a
different container, the control will be moved to the new location, and
removed from the original.

I also updated the target crosshair so selecting an IDE stack will only
work if "Show IDE Stacks" is selected in the target menu.

I look forward to your feedback!
___
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: Refactoring is your friend / moving from 6.x to 9.x

2018-12-31 Thread Geoff Canyon via use-livecode
On Sun, Dec 30, 2018 at 11:58 AM Andre Alves Garzia via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I wish we had better refactoring tools
> so that we could rename a handler and all code that called that handler
> was fixed, or stuff such as rename variable...
>

One of the reasons I like experimenting with different environments is to
see what advantages they have. One advantage that FileMaker Pro has had for
25 years, is that all references to tables, fields, and layouts, are based
on underlying unique IDs. Meaning that if you rename something, the
underlying reference ID doesn't change, and anywhere the reference occurs,
the name change is reflected automatically. Obviously this would require
significant effort to work in any text-file-based system, but it has always
amazed me that I have never seen this feature replicated elsewhere.
___
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: Refactoring is your friend / moving from 6.x to 9.x

2018-12-30 Thread Geoff Canyon via use-livecode
In 6.7.3 on a Mac, this results in true for me.
Checked in 5.0, also resulted in true.

On Sun, Dec 30, 2018 at 1:26 PM Malte Pfaff-Brill via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Regarding lock screen, here is one simple example:
>
> on mouseUp
> lock screen
> subhandler
> unlock screen
> answer the lockscreen
> end mouseUp
>
>
> on subhandler
> lock screen
> — other stuff may follow, but do not unlock
> end subhandler
>
> My expectation in the answer would be „false“, but guess what. :-)
___
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: Find In the IDE

2018-12-28 Thread Geoff Canyon via use-livecode
(self-promotion alert)

Navigator's popup menu has a find function that can:
do a text search in all scripts of selected objects,
 in all behaviors of selected objects -- including chained behaviors,
 in all enclosed controls: select a card and it will search all
controls on that card,
 in all behaviors of all enclosed controls.

Or do a search by any test you like for any of the options above. Tests use
"tID" for the id of the tested control. So for example you could find all
controls that are square by using:

the width of tID is the height of tID

On Fri, Dec 28, 2018 at 9:30 AM Sannyasin Brahmanathaswami via use-livecode
 wrote:

> I tried, in the IDE, to use the dialog
>
> Find and Replace
> Find: "toggleImgSize"
> In: All stack files in a folder
> Folder: _Siva-Siva-app
> Script (checked)
>
> # I know for sure it is at least in one *.livecodescript file…
> # Hopefully to see where else it is used…
> # Set the "folder" to my whole app folder…to look through all subfolders.
>
> I get "0 objects found"
>
> I am off to BBEdit's "Multi-File search" But this why doesn't this
> work in the IDE?
>
> [Hmmm BBedit file search opens the binary files and you can actually see
> the script *inside* the stack... ]
>
> 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: Navigator 6.7rc1 is available

2018-12-26 Thread Geoff Canyon via use-livecode
I updated to 6.7.1rc1 -- based on a suggestion from Sannyasin
Brahmanathaswami, selecting a script-only stack on the target menu now
immediately edits the script for that stack instead of showing it in
Navigator.

As usual, you can get Navigator here
. Or grab it
from GitHub .

On Tue, Dec 25, 2018 at 8:56 PM Geoff Canyon  wrote:

> I found out about strokeGradient, so I updated:
>
> 1. Added strokeGradient property editing, similar to fillGradient editing.
> 2. Added popups for fillGradient["type"] and strokeGradient["type"], and
> fillGradient["quality"] and strokeGradient["quality"].
> 3. Modified the property editor so start, end, via, and repeat edit inline
> instead of opening the editor.
> 4. Fixed a bug where setting the fillGradient or strokeGradient types to
> "No Gradient" failed (because that's actually an invalid value). It now
> clears the gradient properly.
>
> As usual, you can get Navigator here
> . Or grab
> it from GitHub .
>
___
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


Navigator 6.7rc1 is available

2018-12-25 Thread Geoff Canyon via use-livecode
I found out about strokeGradient, so I updated:

1. Added strokeGradient property editing, similar to fillGradient editing.
2. Added popups for fillGradient["type"] and strokeGradient["type"], and
fillGradient["quality"] and strokeGradient["quality"].
3. Modified the property editor so start, end, via, and repeat edit inline
instead of opening the editor.
4. Fixed a bug where setting the fillGradient or strokeGradient types to
"No Gradient" failed (because that's actually an invalid value). It now
clears the gradient properly.

As usual, you can get Navigator here
. Or grab it
from GitHub .
___
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: 9.0.2 Stable Gradient Tool Frequently Fails

2018-12-25 Thread Geoff Canyon via use-livecode
Okay, I updated Navigator to 6.7rc1. I'll post to the list separately with
the changes.
___
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: 9.0.2 Stable Gradient Tool Frequently Fails

2018-12-25 Thread Geoff Canyon via use-livecode
It's not an editor, per se, but all the fill gradient properties are
accessible and editable in Navigator's property editor.

I realized while checking this that there can be stroke gradients as well.
I didn't know that, and they're not editable yet. I'll update Navigator and
post when they're done.

gc


On Mon, Dec 24, 2018 at 6:37 AM Sannyasin Brahmanathaswami via use-livecode
 wrote:

> In 9.0.2 the gradients tools fail to open.
>
> I create graphic set gradient, double click on the dialog doesn't appear
>
> Is there a work around for this? Can you open to model Dialog for working
> to gradients "by hand" from the msg box?
>
> Frankly working with gradients is a "pain" because I often need to move
> the location bars far outside the object.
>
> I believe someone create tool for editing gradients. What is that?
>
> 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: Setting hidden of lines very slow

2018-11-30 Thread Geoff Canyon via use-livecode
Why do you need to simulate non-contiguous selections? Set the
listBehavior, multipleHilites, and noncontiguousHilites of the field to
true and then you can do things like:

set the hilitedLines of fld 1 to 1,3,5

But to your original question, you should use:

repeat for each line L in the htmlText of fld 1
  -- put some htmlText after a variable based on what L contains
end repeat
  -- set the htmlText of fld 1 to the new htmlText

Or if you know what you want to do and don't need to check the existing
textColor and hidden, just:

repeat for each line L in fld 1


Here's an example of what the htmlText looks like for a field where the
first line has a font color and the second line is hidden:

test
this
thing

So if you don't need to check the existing state your code would look
something like this:

put 0 into i -- if you need a line count
repeat for each line L in fld 1
 add 1 to i -- again, if you need a line count
 if  then
  put "" & L & ""
& cr after newHTML
else
   put "" & L & "" & cr after newHTML
end if
end repeat
set the htmlText of fld 1 to newHTML

gc


On Fri, Nov 30, 2018 at 8:36 AM Kaveh Bazargan via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I am simulating a non-contiguous selection of text with a "Find all" button
> that sets the style of all found items of text.
>
> Then I want to inspect those "selections" only but showing the paras that
> contain them and hiding all other lines. So I have a full view and a
> "compact" view that the user can choose by clicking a button
>
> On Fri, 30 Nov 2018 at 16:31, Glen Bojsza via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I was wondering at what stage or how the lines get chosen to be hidden or
> > not?
> > ___
> > 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
> >
>
>
> --
> Kaveh Bazargan
> Director
> River Valley Technologies  • Twitter
>  • LinkedIn
> 
> ___
> 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: Max number of columns in a datagrid?

2018-11-29 Thread Geoff Canyon via use-livecode
On Thu, Nov 29, 2018 at 3:42 AM Niggemann, Bernd via use-livecode <
use-livecode@lists.runrev.com> wrote:

> From the dictionary p 59
>
>
> Maximum length of a LINE in a field:
>
> 65,536 characters storage
> No more than 32,786 pixels wide for display
>
> Kind regards
> Bernd
>

I guess I should have just checked the dictionary :-)

So whether you use a DataGrid or simply a field, if the data you want to
display exceeds a certain width, you're going to have to do some work to
virtualize the display.
___
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: Max number of columns in a datagrid?

2018-11-28 Thread Geoff Canyon via use-livecode
I just checked, and (LC 8 on a Mac) indeed fields fail beyond a certain
width/character limit/???

This:

on mouseUp
   repeat with i = 1 to 1
  put char -10 to -1 of ("aa" & i & " ")  after x
   end repeat
   put x into fld 1
end mouseUp

results in a field that scrolls right only until it displays about "aa294
aa295 aa296 aa2" So, something like 3,000 characters wide.
Again, something that could be worked around, but basically whether it's a
field or the DG, some sort of virtualized display seems necessary.


On Tue, Nov 27, 2018 at 5:31 PM Geoff Canyon  wrote:

> On Mon, Nov 26, 2018 at 3:08 PM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Try the field object.
>>
>
> Not that this couldn't be worked around, but isn't a field limited in the
> width of what it can display? i.e. put a single line 100,000 characters
> long into an un-wrapped field, and the field fails in some way.
>
> gc
>
___
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: How to update the project browser?

2018-11-28 Thread Geoff Canyon via use-livecode
On Wed, Nov 28, 2018 at 2:08 AM Tiemo Hollmann TB via use-livecode <
use-livecode@lists.runrev.com> wrote:

> sometimes the project browser doesn't gets updated automatically. E.g. when
> ungrouping a group via msg box, the group stays visible in the project
> browser until I close and reopen the PB.
>
> Is there something like a "F5" to let the PB update, or is closing and
> reopening the common way to handle it?


 If Navigator ever fails to catch an update, there is an
"Update List Now" button on the Actions menu.
https://gcanyon.wixsite.com/navigator 
___
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: OT: Automate Modifying a PDF

2018-11-27 Thread Geoff Canyon via use-livecode
My first guess would be to find a MacOS PDF editing application that is
either AppleScript-able, or experiment with using Automator. The
alternative might be just cracking open the binary of the PDF file in LC
and see what you find.
___
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: Max number of columns in a datagrid?

2018-11-27 Thread Geoff Canyon via use-livecode
On Mon, Nov 26, 2018 at 3:08 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Try the field object.
>

Not that this couldn't be worked around, but isn't a field limited in the
width of what it can display? i.e. put a single line 100,000 characters
long into an un-wrapped field, and the field fails in some way.

gc
___
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: Max number of columns in a datagrid?

2018-11-23 Thread Geoff Canyon via use-livecode
I don't remember what-all he did with it, but FileMaker proved to be
remarkably resilient pretty much no matter what he threw at it. The one
limitation back then was that a given file couldn't be more than 32MB(!).

On Fri, Nov 23, 2018 at 4:38 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Geoff Canyon wrote:
>
>  > It's not relevant to the current discussion, but wy back when, I
>  > worked with a guy who had created some monster spreadsheets in Excel
>  > with something like 9,000 columns. It was working, but it was
>  > incredibly slow -- this was running on 68k Macs. Not expecting
>  > success, I suggested he give FileMaker a shot. He did, and amazingly,
>  > not only did it happily handle database definitions with 9,000 fields,
>  > it was not just faster than Excel, it was actually speedy. It had zero
>  > problems, and he built out the entirety of his solution that way.
>
> Did he create a layout in FileMaker with 9,000 fields?
>
> If he had I suspect it would expose the root of the issue as being not
> so much about internal handling of the data, but about rendering it all.
>
> One more reason to remember that spreadsheets are not databases.  Very
> different tools with very different feature focuses and tradeoffs.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


Re: Max number of columns in a datagrid?

2018-11-22 Thread Geoff Canyon via use-livecode
It's not relevant to the current discussion, but wy back when, I worked
with a guy who had created some monster spreadsheets in Excel with
something like 9,000 columns. It was working, but it was incredibly slow --
this was running on 68k Macs. Not expecting success, I suggested he give
FileMaker a shot. He did, and amazingly, not only did it happily handle
database definitions with 9,000 fields, it was not just faster than Excel,
it was actually speedy. It had zero problems, and he built out the entirety
of his solution that way.

On Thu, Nov 22, 2018 at 1:05 PM JJS via use-livecode <
use-livecode@lists.runrev.com> wrote:

> you mean like this one:
>
>
> https://www.legamaster.com/products/product/interactive-products/e-screen-interactive-touch-monitors/ptx-9800uhd-e-screen-8713797081610/?no_cache=1=158c87c7f0527df039ce11bc76eae9ab
>
>
> But who can cope with 1500 columns, most people would stop and lost
> track before reaching the 50th
>
> What kind of data is that?
>
>
> Op 21-11-2018 om 22:39 schreef dunbarxx via use-livecode:
> > People with wide monitors?
> >
> >
> >
> > --
> > Sent from:
> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
> >
> > ___
> > 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: What is LC's internal text format?

2018-11-20 Thread Geoff Canyon via use-livecode
I'll chip in and point out that the implicit conversion caused significant
hiccups in figuring out the offsets issues -- several people (including me)
were fooled by the fact that conversion to UTF-32 results in binary data,
but can be transparently treated as text. Or maybe I'm
mistaken/misremembering, which reinforces the fact that it's confusing. :-)

On Tue, Nov 20, 2018 at 10:25 AM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This isn't about strongly typed variables though, but about when (correct)
> conversion is possible.
>
> LC throws an error if you implicitly ask it to convert the wrong kind of
> string to a number - for example, add 45 to "horse". (Obviously
> multiplication
> is fine: the answer would be "45 horses".)
>
> LC throws an error if you implicitly ask it convert the wrong kind of
> string
> or number to a colour: try setting the backcolor of a control to "horse".
>
> LC throws an error if asked to convert a number, or the wrong kind of
> string,
> to a boolean: try setting the hilite of a button to 45.
>
> In all these cases, LC knows it cannot do the right thing, so it throws an
> error to tell you so, rather than guessing, for example, what the truth
> value
> of "45" is.
>
> I'm just suggesting that it cannot know how to correctly convert binary
> data
> into a string - so it should throw an error rather than possibly
> (probably?)
> do the wrong thing.
>
>
> On 20/11/2018 17:55, Mark Wieder via use-livecode wrote:
> > On 11/20/18 8:33 AM, Ben Rubinstein via use-livecode wrote:
> >
> >> Would it not be better to refuse to make an assumption, i.e. require an
> >> explicit conversion?
> >
> > While I'd love to have the option of strongly typed variables at the
> scripting
> > level, I know better than to expect that this will ever happen.
> >
>
> ___
> 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: bignum math library

2018-11-19 Thread Geoff Canyon via use-livecode
Well, the code is theirs to use if it's useful. We'll see.

On Mon, Nov 19, 2018 at 3:02 PM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Here's a scenario that makes your scripts nevertheless valuable.
>
> If they implement "Decimal number" for LC Builder, what I hope,
> because the numbers implementation in LCB is rather uncomplete.
>
>
>
> ___
> 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: bignum math library

2018-11-19 Thread Geoff Canyon via use-livecode
There are libraries for this stuff in C. I'm sure if they incorporate
something in the engine my stuff would be entirely unnecessary. Anything in
C is going to *far* outclass/speed anything I've done in script.

On Sun, Nov 18, 2018 at 11:15 PM hh via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On LC Global (Nov 2018, Monthly report) Kevin and Ali announced among
> others "Decimal Number Implementation", see my screenshot
> http://forums.livecode.com/viewtopic.php?f=76=31797
>
> This is probably close to an arbitrary-precision Decimal type,
> I know the javascript version:
> https://github.com/MikeMcl/decimal.js/
>
> Perhaps it is possible to have "synergetic effects" by joining your work?
>
> ___
> 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


bignum math library

2018-11-18 Thread Geoff Canyon via use-livecode
I've created bignum libraries in the past, but never organized it or did
all four operators. So I started with earlier versions of some of the
functions, optimized, corrected, and extended, and here it is:
https://github.com/gcanyon/bignum

It includes functions for addition, subtraction, multiplication, division,
and comparison/equals. All functions handle any length of argument. Most
have options that handle signed arguments. The functions are optimized for
things like different-length arguments.

Some performance benchmarks on my five-year-old laptop:

Add two 10,000 digit numbers: 0.005 seconds.
Add two 10,000 digit numbers: 0.004 seconds.
Multiply two 10,000 digit numbers: 3.1 seconds.
Divide a 10,000 digit number by a 5,000 digit number: 9.4 seconds -- needs
some optimization.

For division in particular, I wrote a faster algorithm that is included,
but there is a bug in the final steps that I haven't figured out yet.
bigDivFlawed is about 40% faster than bigDiv, but can bork the last few
digits of the quotient. Included in case anyone sees the logic error.

If anyone has any suggestions, let me know here, or file bug reports on
github, or code and submit a pull request.

A list of the functions included:


function bigAdd -- returns the sum
function bigAddSigned -- handles positive and negative arguments
function bigSubtract -- returns the difference
function bigSubtractSigned -- handles positive and negative arguments
function bigTimes -- returns the product
function bigTimesSigned -- handles positive and negative arguments
function bigDiv -- returns (the integer quotient),(the remainder)
function bigDivSigned -- handles positive and negative arguments
function bigishDiv -- Handles any length dividend; divisor must be a valid
LC number (< 16 digits)
function bigDivFlawed -- About 40% faster than bigDiv, but can bork the
last few digits of the quotient. Included in case anyone sees the logic
error.
function bigCompare -- Applies >,<,=,<=,>= to any length arguments
function stripLeadingZeros -- returns any string without whatever leading
zeros it contains
___
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: What is LC's internal text format?

2018-11-13 Thread Geoff Canyon via use-livecode
I never left, I just went silent.

But since I'm "back", I'm curious to know what the engine-types think of
Bernd's solution for fixing the UTF-32 offsets code. It seems that when
converting both the stringToFind and stringToSearch to UTF-32 and then
searching the binary with byteOffset, you won't find "Reykjavík" in
"Reykjavík er höfuðborg"

But if you first append "せ" to each string, then do the textEncode, then
strip the last 4 bytes, the match will work. That seems like strange voodoo
to me.

On Tue, Nov 13, 2018 at 12:54 PM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> For the avoidance of doubt, all my outrage is faux outrage.
> Public life on both sides of the Atlantic (and around the world) has
> completely exhausted capacity for real outrage.
>
> Come back Geoff!
>
> Ben
>
> On 13/11/2018 17:29, Mark Waddingham via use-livecode wrote:
> > On 2018-11-13 18:21, Geoff Canyon via use-livecode wrote:
> >> Nothing I said in this thread has anything to do with optimizing the
> >> allOffsets routines; I only used examples from that discussion because
> they
> >> illustrate my puzzlement on the exact topic you (in general) raised: how
> >> data types are handled by the engine. I'd generalize the responses, to
> say
> >> that it seems how the engine stores data and how it presents that data
> are
> >> not identical in all cases.
> >
> > The best way to think about it is that the engine stores data pretty
> much in
> > the form it is presented with it; however, what script sees of data is
> in the
> > form it requests. In particular, if data has been through some
> operation, or
> > mutated, then there is a good change it won't be in the same form it was
> before.
> >
> > e.g. put tVar + 1 into tVar
> >
> > Here tVar could start off as a string, but would end up as a number by
> virtue
> > of the fact you've performed an arithmetic operation on it.
> >
> >> The above notwithstanding: sorry I outraged you; I'll exit this thread.
> >
> > Obviously I'm not Ben, but I *think* it was 'faux outrage' (well I hope
> it was
> > - hence my jocular comment about herding cats!) - so I don't think
> there's a
> > reason to exit...
> >
> > Warmest Regards,
> >
> > Mark.
> >
>
> ___
> 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: How to find offsets in Unicode Text fast

2018-11-13 Thread Geoff Canyon via use-livecode
I didn't realize this conversation was just between Bernd and me, so here
it is for the list. Bernd found a solution for the Reykjavík issue
(seemingly -- it works, but it's weird) and based on a conversation in
another thread I have a solution for non-case-sensitive matching. So the
UTF-32 version has been updated to account for those issues. It's available
here: https://github.com/gcanyon/alloffsets

On Tue, Nov 13, 2018 at 12:23 PM Geoff Canyon  wrote:

> It's amazing to me that appending the character "せ" for the textEncoding
> fixes the issues with the other characters. I have no idea why that would
> affect anything else at all. Maybe the engine crew can weigh in.
>
> In any case, you seem to have hit on the right bizarre solution, so I
> added that in. I also added a modification to correctly handle case by
> using toUpper instead of (wrongly) depending on caseSensitive, and changed
> from offset to byteOffset, which might speed things up a little. The UTF32
> version is about 3x faster than the item-based solution, but both scale
> well, so I added comments leaving it up to the developer which to use.
>
> The updated version is here: https://github.com/gcanyon/alloffsets
>
> On Tue, Nov 13, 2018 at 9:34 AM Niggemann, Bernd <
> bernd.niggem...@uni-wh.de> wrote:
>
>> Geoff,
>>
>> The thread is very instructive but also a bit disillusioning as far as
>> speed goes. I tried a couple of things Mark Waddingham recommended and they
>> kind of work (I don't know if I did it correctly) but are still slow. Not
>> as slow as simple offset for complex texts but still.
>>
>> Here I pick up on your latest attempt to use UTF-32 which fails on
>> Icelandic Reykjavík (the í is the culprit). There are more Icelandic
>> characters that fail UTF32.
>>
>> On the other hand UTF-32 works surprisingly fast and in many cases
>> accurately.
>>
>> Now I figured that forcing the text to be UTF-32 compliant I would cheat
>> in appending a Japanese character to pFind and pSearch before converting to
>> UTF-32 and removing those afterwards.
>>
>> It turns out that it cures the Icelandic disease...
>> It should also cure similar cases in similar languages.
>> It turns out to be accurate in many things I tested in Brian's test stack.
>>
>> I would love to know the limits of this approach
>>
>> Kind regards
>>
>> Bernd
>>
>> here is the code, additions marked as "new"
>>
>>
>> -
>> *function* allOffsets pFind,pString,pCaseSensitive,pNoOverlaps
>>*-- returns a comma-delimited list of the offsets of pFind in pString*
>>*-- note, this seems to fail on some searches, for example:*
>>*-- searching for "Reykjavík" in "Reykjavík er höfuðborg"*
>>*-- It is uncertain why.*
>>*-- See thread here:
>> http://lists.runrev.com/pipermail/use-livecode/2018-November/251357.html
>> *
>>*local* tNewPos, tPos, tResult, tSkip
>>
>>
>>*put* "せ" after pFind *#<- new force UTF-32*
>>*put* "せ" after pString *#<- new force UTF-32*
>>
>>
>>
>>
>>*put* textEncode(pFind,"UTF-32") into pFind
>>*put* textEncode(pString,"UTF-32") into pString
>>
>>
>>*delete* byte -4 to -1 of pFind *#<- new force UTF-32*
>>*delete* byte -4 to -1 of pString *#<- new force UTF-32*
>>
>>
>>*if* pNoOverlaps *then* *put* length(pFind) - 1 into tSkip
>>
>>
>>*set* the caseSensitive to pCaseSensitive is true
>>*put* 0 into tPos
>>*repeat* forever
>>   *put* offset(pFind, pString, tPos) into tNewPos
>>   *if* tNewPos = 0 *then* *exit* *repeat*
>>   *add* tNewPos to tPos
>>   *if* tPos mod 4 = 1 *then* *put* (tPos div 4 + 1),"" after tResult
>>   *if* pNoOverlaps *then* *add* tSkip to tPos
>>*end* * repeat*
>>*if* tResult is empty *then* *return* 0
>>*else* *return* char 1 to -2 of tResult
>> *end* allOffsets
>> -
>>
>
___
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: What is LC's internal text format?

2018-11-13 Thread Geoff Canyon via use-livecode
On Tue, Nov 13, 2018 at 3:43 AM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'm grateful for all the information, but _outraged_ that the thread that
> I
> carefully created separate from the offset thread was so quickly hijacked
> for
> the continuing (useful!) detailed discussion on that topic.
>

Nothing I said in this thread has anything to do with optimizing the
allOffsets routines; I only used examples from that discussion because they
illustrate my puzzlement on the exact topic you (in general) raised: how
data types are handled by the engine. I'd generalize the responses, to say
that it seems how the engine stores data and how it presents that data are
not identical in all cases.

Separately, it's interesting to hear that the engine (can) store(s) numeric
values for strings, as an optimization.

The above notwithstanding: sorry I outraged you; I'll exit this thread.
___
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: How to find offsets in Unicode Text fast

2018-11-13 Thread Geoff Canyon via use-livecode
A lot of useful points here, thanks.

The caseSensitive vs. binary has been covered in the other discussion --
Monte said that by using offset() "the engine will convert your data to a
string and assume native encoding. This is probably why you are getting
some case insensitivity."


I understand (generally) the complexity of comparison, but that's not the
speed issue causing this discussion. Most of the proposed solutions are
using nearly the same operators/functions for comparison, or at least the
same comparison is being done. Instead, the problem is a Foolish Line
Painter problem: with single-byte characters, finding all occurrences of
one string in another by repeatedly using offset() with charsToSkip scales
well; but with multi-byte characters, the penalty for repeatedly
calculating out longer and longer skips is exponential.

The fastest proposed solutions so far, which both scale much more closely
to linearly with the size of the stringToSearch, are:

1. Set the item delimiter to the charsToFind and then use repeat for each
item on the stringToSearch. This comes with its own headaches, but supports
(lack of) case sensitivity.
2. Converting to UTF-32 binary, and using offset and charsToSkip. This
hasn't yet been corrected to use byteOffset and toUpper to property handle
case insensitivity, but once that is done, this will probably be the
preferred solution between the two -- the logic is simpler, and it's
several times faster.

Thanks,

Geoff

On Tue, Nov 13, 2018 at 12:27 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-11-13 01:06, Geoff Canyon via use-livecode wrote:
> > On Mon, Nov 12, 2018 at 11:36 AM Ben Rubinstein via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> I'm really confused that case-insensitive should work at all for
> >> UTF-16 or
> >> UTF-32;
>
> The caseSensitive (and formSensitive) properties only apply to strings
> *not* binary strings.
>
> The output of textEncode() is a binary string.
>
> The 'is' operator is overloaded - in strict order:
>
>left-empty 'is' right-ANY -- returns is-empty(right-ANY)
>left-ANY 'is' right-empty -- returns is-empty(left-ANY)
>left-array 'is' left-array -- compare as array
>left-number 'is' right-number -- compare as number
>left-numeric-[binary]-string 'is' right-numeric-[binary]-string --
> compare as number
>left-binary-string 'is' right-binary-string -- compare as binary
> strings
>left-any 'is' right-any -- compare as strings
>
> Also concatenation, put after and put before are overloaded:
>
> binary-string & binary-string -> binary-string
> string & ANY -> string
> ANY & string -> string
>
> put src-data after|before dst-data -> dst-data is binary-string
> put src-ANY after|before dst-ANY -> dst-ANY is string
>
> > This is so puzzling. I tried this code in a button:
> >
> > on mouseUp
> >put "Ѡ" into x
> >put "ѡ" into y
> >--put ("Ѡ" is "ѡ") && (x is y)
> >--exit mouseUp
> >put textencode("Ѡ","UTF-32") into xBig
> >put textencode("ѡ","UTF-32") into xSmall
> >repeat for each byte B in xBig
> >   put B after yBig
> >end repeat
> >repeat for each byte B in xSmall
> >   put B after ySmall
> >end repeat
> >put "Ѡ" into zBig
> >put "ѡ" into zSmall
> >put zBig into wBig
> >put zSamll into wSmall
> >put textencode(zBig,"UTF-32") into zBig
> >put textencode(zSmall,"UTF-32") into zSmall
> >put x into j
> >put y into k
> >set caseSensitive to false
> >put ("Ѡ" is "ѡ") && (xBig is xSmall) && (yBig is ySmall) && (zBig is
> > zSmall) && (wBig is wSmall) && (x is y) && (j is k)
> > end mouseUp
> >
> >
> > That puts: true false false false true true true
> >
> > Things to note:
> >
> > 1. "Ѡ" and "ѡ" are upper and lower case omega in cyrillic, 0460 and
> > 0461. Given the string literals, LC is happy to say they are the
> > same
> > (the first true)
> > 2. Put them in a variable, LC is happy to say they are the same
> > (the second-to-last true).
> > 3. Convert them to UTF-32 and LC no longer recognizes them as the same
> > (the
> > fourth boolean, false)
> > 4. Put the variables into other variables, and LC identifies them as
> > the
> > same (the last true)
>
> ("Ѡ" is "ѡ"

Re: What is LC's internal text format?

2018-11-13 Thread Geoff Canyon via use-livecode
I don't *think* I'm confusing binary string/data with binary numbers -- I
was just trying to illustrate that when a Latin Small Letter A (U+0061)
gets encoded, somewhere there is stored (four bytes, one of which is) a
byte 97, i.e. the bit sequence 111, unless computers don't work that
way anymore.

What I now see is tripping me up is the implicit cast to a character you're
saying that charToNum supports, without the corresponding cast to a number
supported in numToChar -- i.e. this fails:

put textEncode("a","UTF-32") into X;put numtochar(byte 1 of X)

while this works:

put textEncode("a","UTF-32") into X;put numtochar(bytetonum(byte 1 of X))

Thanks for the insight,

Geoff

On Tue, Nov 13, 2018 at 12:03 AM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-11-13 08:35, Geoff Canyon via use-livecode wrote:
> > So then why does put textEncode("a","UTF-32") into X;put chartonum(byte
> > 1
> > of X) put 97?
>
> Because:
>
>1) textEncode("a", "UTF-32") produces the byte sequence <97,0,0,0>
>2) byte 1 of <97,0,0,0> is <97>
>3) charToNum(<97>) first converts the byte <97> into a native string
> which is "a" (as the 97 is the code for 'a' in the native encoding
> table), then converts that (native) char to a number -> 97
>
> > That implies that "byte" 1 is "a", not 111.
>
> 111 is 97 but printed in base-2.
>
> FWIW, I think you are confusing 'binary string' with 'binary number' -
> these are not the same thing.
>
> A 'binary string' (internally the data type is 'Data') is a sequence of
> bytes (just as a 'string' is a sequence of
> characters/codepoints/codeunits).
>
> A 'binary number' is a number which has been rendered to a string with
> base-2.
>
> Bytes are like characters (and codepoints, and codeunits) in that they
> are 'abstract' things - they aren't numbers, and have no direct
> conversion to them - which is why we have byteToNum, numToByte,
> nativeCharToNum, numToNativeChar, codepointToNum and numToCodepoint.
>
> The charToNum and numToChar functions are actually deprecated /
> considered legacy - as their function (when useUnicode is set to true)
> depends on processing unicode text as binary data - which isn't how
> unicode works post-7 (indeed, there was no way to fold their behavior
> into the new model - hence the deprecation, and replacement with
> nativeCharToNum / numToNativeChar).
>
> You'll notice that there is no modern 'charToNum'/'numToChar' - just
> 'codepointToNum'/'numToCodepoint'. A codepoint is an index into the
> (large - 21-bit) Unicode code table; Unicode characters can be composed
> of multiple codepoints (e.g. [e,combining-acute] and thus don't have a
> 'number' per-se.
>
> Warmest Regards,
>
> Mark.
>
> >
> > I've looked in the dictionary and I don't see anything that comes close
> > to
> > describing this.
> >
> > gc
> >
> > On Mon, Nov 12, 2018 at 10:21 PM Mark Waddingham via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> On 2018-11-13 07:15, Geoff Canyon via use-livecode wrote:
> >> > On Mon, Nov 12, 2018 at 3:50 PM Monte Goulding via use-livecode <
> >> > use-livecode@lists.runrev.com> wrote:
> >> > Unless I'm misunderstanding, this hasn't been my observation. Using
> >> > offset
> >> > on a string that has been textEncodet()ed to UTF-32 returns values
> that
> >> > are
> >> > 4 * (the character offset - 1) + 1 -- if it were re-encoded, wouldn't
> >> > it
> >> > return the actual offsets (except when it fails)? Also,  encodes to
> >> > 00010001, and routines that convert to UTF-32 and then use offset will
> >> > find
> >> > five instances of that character in the UTF-32 encoding because of
> >> > improper
> >> > boundaries. To see this, run this code:
> >> >
> >> > on mouseUp
> >> >put textencode("","UTF-32") into X
> >> >put textencode("","UTF-32") into Y
> >> >put offset(X,Y,1)
> >> > end mouseUp
> >> >
> >> > That will return 2, meaning that it found the encoding for X starting
> >> > at
> >> > character 2 + 1 = 3 of Y. In other words, it found X using the last
> >> > half of
> >> > the first "" and the first half of the second ""
> >>
> >> The textEncode function generates binary data which is composed o

Re: What is LC's internal text format?

2018-11-12 Thread Geoff Canyon via use-livecode
So then why does put textEncode("a","UTF-32") into X;put chartonum(byte 1
of X) put 97? That implies that "byte" 1 is "a", not 111. Likewise, put
textEncode("㍁","UTF-32") into X;put chartonum(byte 1 of X) puts 65.

I've looked in the dictionary and I don't see anything that comes close to
describing this.

gc

On Mon, Nov 12, 2018 at 10:21 PM Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 2018-11-13 07:15, Geoff Canyon via use-livecode wrote:
> > On Mon, Nov 12, 2018 at 3:50 PM Monte Goulding via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> > Unless I'm misunderstanding, this hasn't been my observation. Using
> > offset
> > on a string that has been textEncodet()ed to UTF-32 returns values that
> > are
> > 4 * (the character offset - 1) + 1 -- if it were re-encoded, wouldn't
> > it
> > return the actual offsets (except when it fails)? Also,  encodes to
> > 00010001, and routines that convert to UTF-32 and then use offset will
> > find
> > five instances of that character in the UTF-32 encoding because of
> > improper
> > boundaries. To see this, run this code:
> >
> > on mouseUp
> >put textencode("","UTF-32") into X
> >put textencode("","UTF-32") into Y
> >put offset(X,Y,1)
> > end mouseUp
> >
> > That will return 2, meaning that it found the encoding for X starting
> > at
> > character 2 + 1 = 3 of Y. In other words, it found X using the last
> > half of
> > the first "" and the first half of the second ""
>
> The textEncode function generates binary data which is composed of
> bytes. When you use binary data in a text function (which offset is),
> the engine uses a compatability conversion which treats the sequence of
> bytes as a sequence of native characters (this preserves what happened
> pre-7.0 when strings were only ever native, and as such binary and
> string were essentially the same thing).
>
> So if you textEncode a 1 (native) character string as UTF-32, you will
> get a four byte string, which will then turn back into a 4 (native)
> character string when passed to offset.
>
> 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
___
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: What is LC's internal text format?

2018-11-12 Thread Geoff Canyon via use-livecode
On Mon, Nov 12, 2018 at 3:50 PM Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Text strings in LiveCode are native encoded (MacRoman or ISO 8859) where
> possible and where you don’t explicitly tell the engine
> For what it’s worth using `offset` is the wrong thing to do if you have
> textEncoded your strings into binary data. You want to use `byteOffset`
> otherwise the engine will convert your data to a string and assume native
> encoding. This is probably why you are getting some case insensitivity.
>

Unless I'm misunderstanding, this hasn't been my observation. Using offset
on a string that has been textEncodet()ed to UTF-32 returns values that are
4 * (the character offset - 1) + 1 -- if it were re-encoded, wouldn't it
return the actual offsets (except when it fails)? Also,  encodes to
00010001, and routines that convert to UTF-32 and then use offset will find
five instances of that character in the UTF-32 encoding because of improper
boundaries. To see this, run this code:

on mouseUp
   put textencode("","UTF-32") into X
   put textencode("","UTF-32") into Y
   put offset(X,Y,1)
end mouseUp

That will return 2, meaning that it found the encoding for X starting at
character 2 + 1 = 3 of Y. In other words, it found X using the last half of
the first "" and the first half of the second ""
___
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: How to find offsets in Unicode Text fast

2018-11-12 Thread Geoff Canyon via use-livecode
I didn't realize until now that offset() simply fails with some unicode
strings:

put offset("a","↘܎qeiuruioqeaaa↘܎qeiuar",13) -- puts 0

On Mon, Nov 12, 2018 at 9:17 PM Geoff Canyon  wrote:

> A few things:
>
> 1. It seems codepointOffset can only find a single character? So it
> won't work for any search for a multi-character string?
> 2: codepointOffset seems to work differently for multi-byte characters and
> regular characters:
>
> put codepointoffset("e","↘ndatestest",6) -- puts 3
> put codepointoffset("e","andatestest",6) -- puts 9
>
> 3: It seems that when multi-byte characters are involved, codepointOffset
> suffers from the same sort of slow-down as offset does. For example, in a
> 145K string with about 20K hits for a single character, a simple
> codepointOffset routine (below) takes over 10 seconds, while the item-based
> routine takes about 0.3 seconds for the same results.
>
> On Mon, Nov 12, 2018 at 4:21 PM Monte Goulding via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Hi Folks
>>
>> I was a bit perplexed by this so I had a quick look about the engine and
>> I see the issue. The problem is you are using `offset` which works on
>> characters. Characters in LiveCode are neither unicode codepoints or bytes.
>> They are graphemes. This means that when you have chars to skip the entire
>> string needs to be parsed to find the grapheme boundaries so that the index
>> can be translated into graphemes to skip. Note that if the strings you were
>> dealing with weren’t unicode then the translation of chars to graphemes is
>> 1 -> 1 so there’s no big cost which is why things are much faster when you
>> textEncode and offset that.
>>
>> So! Change to using codepointOffset and hopefully it will be much
>> speedier!
>>
>> 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: How to find offsets in Unicode Text fast

2018-11-12 Thread Geoff Canyon via use-livecode
A few things:

1. It seems codepointOffset can only find a single character? So it
won't work for any search for a multi-character string?
2: codepointOffset seems to work differently for multi-byte characters and
regular characters:

put codepointoffset("e","↘ndatestest",6) -- puts 3
put codepointoffset("e","andatestest",6) -- puts 9

3: It seems that when multi-byte characters are involved, codepointOffset
suffers from the same sort of slow-down as offset does. For example, in a
145K string with about 20K hits for a single character, a simple
codepointOffset routine (below) takes over 10 seconds, while the item-based
routine takes about 0.3 seconds for the same results.

On Mon, Nov 12, 2018 at 4:21 PM Monte Goulding via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Folks
>
> I was a bit perplexed by this so I had a quick look about the engine and I
> see the issue. The problem is you are using `offset` which works on
> characters. Characters in LiveCode are neither unicode codepoints or bytes.
> They are graphemes. This means that when you have chars to skip the entire
> string needs to be parsed to find the grapheme boundaries so that the index
> can be translated into graphemes to skip. Note that if the strings you were
> dealing with weren’t unicode then the translation of chars to graphemes is
> 1 -> 1 so there’s no big cost which is why things are much faster when you
> textEncode and offset that.
>
> So! Change to using codepointOffset and hopefully it will be much speedier!
>
> 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: How to find offsets in Unicode Text fast

2018-11-12 Thread Geoff Canyon via use-livecode
On Mon, Nov 12, 2018 at 11:36 AM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I'm really confused that case-insensitive should work at all for UTF-16 or
> UTF-32;


This is so puzzling. I tried this code in a button:

on mouseUp
   put "Ѡ" into x
   put "ѡ" into y
   --put ("Ѡ" is "ѡ") && (x is y)
   --exit mouseUp
   put textencode("Ѡ","UTF-32") into xBig
   put textencode("ѡ","UTF-32") into xSmall
   repeat for each byte B in xBig
  put B after yBig
   end repeat
   repeat for each byte B in xSmall
  put B after ySmall
   end repeat
   put "Ѡ" into zBig
   put "ѡ" into zSmall
   put zBig into wBig
   put zSamll into wSmall
   put textencode(zBig,"UTF-32") into zBig
   put textencode(zSmall,"UTF-32") into zSmall
   put x into j
   put y into k
   set caseSensitive to false
   put ("Ѡ" is "ѡ") && (xBig is xSmall) && (yBig is ySmall) && (zBig is
zSmall) && (wBig is wSmall) && (x is y) && (j is k)
end mouseUp


That puts: true false false false true true true

Things to note:

1. "Ѡ" and "ѡ" are upper and lower case omega in cyrillic, 0460 and
0461. Given the string literals, LC is happy to say they are the same
(the first true).
2. Put them in a variable, LC is happy to say they are the same
(the second-to-last true).
3. Convert them to UTF-32 and LC no longer recognizes them as the same (the
fourth boolean, false)
4. Put the variables into other variables, and LC identifies them as the
same (the last true)

gc
___
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: How to find offsets in Unicode Text fast

2018-11-12 Thread Geoff Canyon via use-livecode
On Mon, Nov 12, 2018 at 11:36 AM Ben Rubinstein via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> I'm really confused that case-insensitive should work at all for UTF-16 or
> UTF-32; at this point as far as I understand it, LC has no idea that how
> to
> correctly interpret the value of the variable as text.
>
> Mr Very Picky would also suggest that to be really correct, the code in
> this
> case should also check that the offset found was on a four-byte boundary
> (tPos
> mod 4 = 1); it's probably a purely theoretical consideration, but I think
> that
> the four-byte sequence (representing the character you're searching for)
> could
> in theory be incorrectly matched across two other characters.
>

I also thought of the four-byte boundary consideration. The code below is
available at: https://github.com/gcanyon/alloffsets

For example, previous UTF-32 versions will fail on characters like ,
which converts to 00010001 and therefore finding  in  would return
1,1,2,2,3. I don't know how many other possible issues there are, but given
the current UTF-32 character set there are a few, but likely not many. The
failure searching for "Reykjavík" in "Reykjavík er höfuðborg" is weirder
and worse, obviously.

I was puzzled at first by the case-sensitive functionality in
UTF-32-encoded strings, but I realized that standard case-insensitive
searches are presumably just implemented as a set of exceptions at a low
level. For example, the the engine isn't looking at "a" and "A"  and
saying, "those are the same." Instead, it's looking at raw ACII and
mapping 97 to 65 if case-insensitive is requested. The same must be true of
UTF-32: the engine isn't looking at "Ѡ" and "ѡ", it's mapping 0460
to 0461. I agree that it seems a little odd that LC knows the string of
binary data is "text", but maybe there's some trick to that?

Anyway, here's the boundary-respecting, but still-flawed version of
UTF-32-based allOffsets, with a documented bad example in a comment:

function allOffsetsUTF32 pFind,pString,pCaseSensitive,pNoOverlaps
   -- returns a comma-delimited list of the offsets of pFind in pString
   -- note, this seems to fail on some searches, for example:
   -- searching for "Reykjavík" in "Reykjavík er höfuðborg"
   -- It is uncertain why.
   -- See thread here:
http://lists.runrev.com/pipermail/use-livecode/2018-November/251357.html
   local tNewPos, tPos, tResult, tSkip
   put textEncode(pFind,"UTF-32") into pFind
   put textEncode(pString,"UTF-32") into pString
   if pNoOverlaps then put length(pFind) - 1 into tSkip

   set the caseSensitive to pCaseSensitive is true
   put 0 into tPos
   repeat forever
  put offset(pFind, pString, tPos) into tNewPos
  if tNewPos = 0 then exit repeat
  add tNewPos to tPos
  if tPos mod 4 = 1 then put (tPos div 4 + 1),"" after tResult
  if pNoOverlaps then add tSkip to tPos
   end repeat
   if tResult is empty then return 0
   else return char 1 to -2 of tResult
end allOffsetsUTF32
___
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: How to find offsets in Unicode Text fast

2018-11-10 Thread Geoff Canyon via use-livecode
One thing I don't get is how (not) caseSensitive gets handled? Once the
text is all binary data, is the engine really still able to look at the
binary values for "A" and "a" and treat them as the same?

On Sat, Nov 10, 2018 at 8:54 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> The correct formula for UTF16 should be:
> put tPos div 2 + 1,"" after tResult
>
> The correct formula for UTF32 should be:
> put tPos div 4 + 1,"" after tResult
>
> If you go to card #6 of my stack that is on GitHub, it has the first
> chapter of John that I copied from the internet.  I added a single UTF(8?)
> character to it so get the results that are listed (last char of the first
> visible line).
>
> Making the change is dramatic.  Offset takes 65k ms.  Geoff's code and my
> code take 6k ms.  Converting to UTF16 first and using offset takes 519 ms.
> And note that the timings include those 2 calls to convert the variables to
> UTF16.
>
> Now, if I take Geoff's sample that didn't work, I get the same incorrect
> results.  The problem is that some of those characters end up needing 2
> UTF16 codepoints to represent them. (I hope I'm using the correct
> terminology.)
>
> So, the safe solution is to always use UTF32.  Speed looks to be close
> between them.  On my largest text example, UTF16 took 448ms and UTF32 took
> 584ms.
>
> I'll update my stack and push an update to my repo so others can check out
> the new code.
>
> On Sat, Nov 10, 2018 at 6:05 PM Niggemann, Bernd <
> bernd.niggem...@uni-wh.de>
> wrote:
>
> > That is what I alluded to,
> > UTF is  a wild country and I don't know my ways,
> > try
> > -
> > function allOffsets pDelim, pString, pCaseSensitive
> >local tNewPos, tPos, tResult
> >
> >put textEncode(pDelim,"UTF32") into pDelim
> >put textEncode(pString,"UTF32") into pString
> >
> >set the caseSensitive to pCaseSensitive is true
> >put 0 into tPos
> >repeat forever
> >   put offset(pDelim, pString, tPos) into tNewPos
> >   if tNewPos = 0 then exit repeat
> >   add tNewPos to tPos
> >   put tPos div 4 + tPos mod 4,"" after tResult
> >end repeat
> >if tResult is empty then return 0
> >else return char 1 to -2 of tResult
> > end allOffsets
> > --
> >
> > It teaches me to use UTF32 to be on the safe side, thank you.
> > But that should take care of it.
> >
> > Kind regards
> > Bernd
> >
> >
> > Unfortunately, I just discovered that your solution doesn't produce
> correct
> > results. If I get the offsets of "aa" in
> > "↘܎aa↘܎a↘܎",
> >
> > My code (and Brian Milby's) will return: 7,8,9,10
> >
> > Your code will return: 9,10,11,12
> >
> > As I understand it, textEncode transforms unicode text into binary data,
> > which has the effect of speeding things up because LC is no longer
> dealing
> > with variable-byte-length characters, just the underlying (fixed-length)
> > binary data that makes them up. Hence the above discrepancy. At least I
> > think so. Maybe there's a way to fix it?
> >
> > gc
> >
> >
> >
> > Am 11.11.2018 um 00:00 schrieb Geoff Canyon :
> >
> > Unfortunately, I just discovered that your solution doesn't produce
> > correct results. If I get the offsets of "aa" in
> > "↘܎aa↘܎a↘܎",
> >
> > My code (and Brian Milby's) will return: 7,8,9,10
> >
> > Your code will return: 9,10,11,12
> >
> > As I understand it, textEncode transforms unicode text into binary data,
> > which has the effect of speeding things up because LC is no longer
> dealing
> > with variable-byte-length characters, just the underlying (fixed-length)
> > binary data that makes them up. Hence the above discrepancy. At least I
> > think so. Maybe there's a way to fix it?
> >
> > gc
> >
> > On Sat, Nov 10, 2018 at 12:12 PM Niggemann, Bernd <
> > bernd.niggem...@uni-wh.de> wrote:
> >
> >> I figured that the slowdown was due to UTF8, for each char it has to
> test
> >> if it is a compounded character. So I just tried with utf16 figuring,
> that
> >> now it just compares at the byte-level.
> >>
> >> As it turned out it was indeed faster.
> >>
> >> Now I don't understand unicode but as I understand for some
> >> languages/signs/characters you need UTF32 to display them correctly. I
> may
> >> be wrong on that. But if it is true then the overhead to use UTF32 in
> >> textEncoding only adds a small amount to processing time.
> >>
> >> The nice thing is that UTF16 and UTF32 textencoding also support
> >> caseSensitivity.  ByteOffset() for UTF16 is probably always
> case-sensitive,
> >> but only saves a small amount of processing time.
> >>
> >> Also, LC apparently has to turn ASCII into UTF8 as soon as there is one
> >> non-ASCII character in the source text. In my naive understanding LC
> could
> >> internally switch to UTF16/32 for offset() as soon as it realizes that
> UTF8
> >> is in the source. Would make obsolete this workaround.
> >>
> >>
> >> This is just 

Re: How to find offsets in Unicode Text fast

2018-11-10 Thread Geoff Canyon via use-livecode
Unfortunately, I just discovered that your solution doesn't produce correct
results. If I get the offsets of "aa" in
"↘܎aa↘܎a↘܎",

My code (and Brian Milby's) will return: 7,8,9,10

Your code will return: 9,10,11,12

As I understand it, textEncode transforms unicode text into binary data,
which has the effect of speeding things up because LC is no longer dealing
with variable-byte-length characters, just the underlying (fixed-length)
binary data that makes them up. Hence the above discrepancy. At least I
think so. Maybe there's a way to fix it?

gc

On Sat, Nov 10, 2018 at 12:12 PM Niggemann, Bernd 
wrote:

> I figured that the slowdown was due to UTF8, for each char it has to test
> if it is a compounded character. So I just tried with utf16 figuring, that
> now it just compares at the byte-level.
>
> As it turned out it was indeed faster.
>
> Now I don't understand unicode but as I understand for some
> languages/signs/characters you need UTF32 to display them correctly. I may
> be wrong on that. But if it is true then the overhead to use UTF32 in
> textEncoding only adds a small amount to processing time.
>
> The nice thing is that UTF16 and UTF32 textencoding also support
> caseSensitivity.  ByteOffset() for UTF16 is probably always case-sensitive,
> but only saves a small amount of processing time.
>
> Also, LC apparently has to turn ASCII into UTF8 as soon as there is one
> non-ASCII character in the source text. In my naive understanding LC could
> internally switch to UTF16/32 for offset() as soon as it realizes that UTF8
> is in the source. Would make obsolete this workaround.
>
>
> This is just how I "think" it works, the explanation may be all wrong.
>
> Kind regards
>
> Bernd
>
> Am 10.11.2018 um 20:30 schrieb Geoff Canyon :
>
> This is faster -- under some circumstances, much faster! Any idea why
> textEncoding suddenly fixes everything?
>
> On Sat, Nov 10, 2018 at 5:13 AM Niggemann, Bernd via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> This is a little late but there was a discussion about the slowness of
>> simple offset() when dealing with text that contains Unicode characters.
>>
>> Geoff Canyon and Brian Milby found a faster solution by setting the
>> itemDelimiter to the search string.
>> They even provided a way to find the position of substrings in the search
>> string which the offset() command does by design.
>>
>> Here I propose a variant of the offset() form that uses UTF16 to search,
>> easily adaptable to UTF32 if necessary.
>>
>> To test (as in Brian's testStack) add a unicode character to the text to
>> be searched e.g. at the end. Just any non-ASCII character to see the speed
>> penalty of simple offset(). I used ð (Icelandic d) or use any chinese
>> character.
>>
>>
>> Kind regards
>> Bernd
>>
>> ---
>> function allOffsets pDelim, pString, pCaseSensitive
>>local tNewPos, tPos, tResult
>>
>>put textEncode(pDelim,"UTF16") into pDelim
>>put textEncode(pString,"UTF16") into pString
>>
>>set the caseSensitive to pCaseSensitive is true
>>put 0 into tPos
>>repeat forever
>>   put offset(pDelim, pString, tPos) into tNewPos
>>   if tNewPos = 0 then exit repeat
>>   add tNewPos to tPos
>>   put tPos div 2 + tPos mod 2,"" after tResult
>>end repeat
>>if tResult is empty then return 0
>>else return char 1 to -2 of tResult
>> end allOffsets
>> -
>> ___
>> 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: How to find offsets in Unicode Text fast

2018-11-10 Thread Geoff Canyon via use-livecode
This is faster -- under some circumstances, much faster! Any idea why
textEncoding suddenly fixes everything?

On Sat, Nov 10, 2018 at 5:13 AM Niggemann, Bernd via use-livecode <
use-livecode@lists.runrev.com> wrote:

> This is a little late but there was a discussion about the slowness of
> simple offset() when dealing with text that contains Unicode characters.
>
> Geoff Canyon and Brian Milby found a faster solution by setting the
> itemDelimiter to the search string.
> They even provided a way to find the position of substrings in the search
> string which the offset() command does by design.
>
> Here I propose a variant of the offset() form that uses UTF16 to search,
> easily adaptable to UTF32 if necessary.
>
> To test (as in Brian's testStack) add a unicode character to the text to
> be searched e.g. at the end. Just any non-ASCII character to see the speed
> penalty of simple offset(). I used ð (Icelandic d) or use any chinese
> character.
>
>
> Kind regards
> Bernd
>
> ---
> function allOffsets pDelim, pString, pCaseSensitive
>local tNewPos, tPos, tResult
>
>put textEncode(pDelim,"UTF16") into pDelim
>put textEncode(pString,"UTF16") into pString
>
>set the caseSensitive to pCaseSensitive is true
>put 0 into tPos
>repeat forever
>   put offset(pDelim, pString, tPos) into tNewPos
>   if tNewPos = 0 then exit repeat
>   add tNewPos to tPos
>   put tPos div 2 + tPos mod 2,"" after tResult
>end repeat
>if tResult is empty then return 0
>else return char 1 to -2 of tResult
> end allOffsets
> -
> ___
> 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: How to find the offset of the last instance of a repeating character in a string? (Geoff Canyon)

2018-11-05 Thread Geoff Canyon via use-livecode
I've updated my GitHub to the following, which adopts Brian's "starts with"
(I can't count how many times I've had to re-remember that "starts with" is
faster than comparing to char 1 through ) and added minor
optimizations to the wrapping-up code.

gc

function allOffsets D,S,pCase,pNoOverlaps
   -- returns a comma-delimited list of the offsets of D in S
   set the caseSensitive to pCase is true
   put length(D) into dLength
   put pNoOverlaps and dLength > 1 into pNoOverlaps
   put numtochar(chartonum(char -1 of D) mod 2 + 1) after S
   if not pNoOverlaps then
  repeat with i = 1 to dLength - 1
 if not (char i + 1 to -1 of D is char 1 to dLength - i of D) then
next repeat
 put char -i to -1 of D into OV[i]
 put i & cr after kList
  end repeat
   end if
   set the itemDel to D
   put 1 - dLength into C
   if pNoOverlaps or kList is empty then
  repeat for each item i in S
 add length(i) + dLength to C
 put C,"" after R
  end repeat
   else
  repeat for each item i in S
 repeat for each line K in kList
if i & D begins with OV[K] then put (C + K),"" after R
 end repeat
 add length(i) + dLength to C
 put C,"" after R
  end repeat
   end if
   set the itemDel to comma
   repeat with i = 1 to 999
  if item i of R > 0 then exit repeat
   end repeat
   delete item 1 to i - 1 of R
   if R begins with C then return 0
   return char 1 to -3 - length(C) of R
end allOffsets
___
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: How to find the offset of the last instance of a repeating character in a string? (Geoff Canyon)

2018-11-05 Thread Geoff Canyon via use-livecode
On Sun, Nov 4, 2018 at 7:11 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> If you're looking for 'romeo' in pText, would you set pOverlaps to true
> or to false?


I'd set it to false, there's no way for "romeo" to overlap. But even if I
were looking for "radar", which could overlap, I'd set it to false if I
were searching an english text document, because there's no word
"radaradar". But as I said, I've switched it to default to finding overlaps.
___
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: How to find the offset of the last instance of a repeating character in a string? (Geoff Canyon)

2018-11-05 Thread Geoff Canyon via use-livecode
On Sun, Nov 4, 2018 at 7:42 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Simply add 1 to the last offset pointer. If after the first iteration you
> return 1, then set the charsToSkip to 2 instead of offset +
> len(searchString) if you take my meaning.
>
> Bob S
>

The method we're using avoids charsToSkip because it suffers mightily with
multi-byte characters. But the latest updates handle overlapping results,
see other posts in this thread.
___
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: How to find the offset of the last instance of a repeating character in a string? (Geoff Canyon)

2018-11-04 Thread Geoff Canyon via use-livecode
On Sun, Nov 4, 2018 at 4:34 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 11/4/18 10:40 AM, Geoff Canyon via use-livecode wrote:
> > I also added a "with overlaps" option.
>
> My problem with the pWithOverlaps parameter is that is requires a priori
> knowledge of the data being consumed. If you already know there are
> overlaps then you'd set the parameter to true. If you don't know whether
> or not there are overlaps, then you'd need to set it to true so you
> don't miss anything (aside, of course, for the trivial case where you
> don't care whether or not there are overlaps - is there a use case for
> this?).
>
> The only time you would set it to false is after you've already
> determined that there are no overlaps, and the time spent on that would
> probably more than offset the extra processing in the function.


I'm not sure I agree that it would be so unlikely to know that overlaps
won't occur (or that it's unreasonable to not want them). If I'm looking
for every instance of "romeo" in romeo and juliet, then obviously I'm not
expecting, nor do I want, overlaps. Likewise, overlaps can only occur if
the search string allows for them, so "romeo" makes it impossible from the
get go

That said, it seems reasonable to default overlaps to true rather than
false. I'll set it up that way when I add the modification below.

On Sun, Nov 4, 2018 at 4:02 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> put kList is not empty into pWithOverlaps
>

Good point -- I suppose it also makes sense (albeit that the speed
improvement would be trivial) to not bother even building kList if the term
to be found is a single character.

gc
___
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: How to find the offset of the last instance of a repeating character in a string? (Geoff Canyon)

2018-11-04 Thread Geoff Canyon via use-livecode
Alex, good catch! The code below and at
https://github.com/gcanyon/alloffsets now puts a stop character after the
string to prevent the error you found. I also added a "with overlaps"
option. I think this is correct, and about as efficient as possible, but
thanks to anyone who finds a bug or a faster way.

gc


function allOffsets D,S,pCase,pWithOverlaps
   -- returns a comma-delimited list of the offsets of D in S
   set the caseSensitive to pCase is true
   put length(D) into dLength
   put numtochar(chartonum(char -1 of D) mod 2 + 1) after S
   if pWithOverlaps then
  repeat with i = 1 to dLength - 1
 if not (char i + 1 to -1 of D is char 1 to dLength - i of D) then
next repeat
 put char -i to -1 of D into OV[i]
 put i & cr after kList
  end repeat
   end if
   set the itemDel to D
   put 1 - dLength into C
   if pWithOverlaps then
  repeat for each item i in S
 repeat for each line K in kList
if char 1 to K of (i & D) is OV[K] then put (C + K),"" after R
 end repeat
 add length(i) + dLength to C
 put C,"" after R
  end repeat
   else
  repeat for each item i in S
 add length(i) + dLength to C
 put C,"" after R
  end repeat
   end if
   set the itemDel to comma
   repeat until item 1 of R > 0
  delete item 1 of R
   end repeat
   delete item -1 of R
   if R is empty then return 0 else return char 1 to -2 of R
end allOffsets
___
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


  1   2   3   >