Re: Stylistic question.

[Geoff Canyon via use-livecode]

Ah, okay, I think I understand. There's a bit to unpack here:

1. There is no direct communication between Navigator and the LC IDE
toolbar. That means that the inspector triggered by the IDE toolbar will
reflect whatever is selected.
2. Navigator *only* tries to change the current selection automatically
when it is displaying "This Card" of "The Topstack" -- that goes both ways;
it only tries to reflect the selection in the IDE when this card and the
topstack are displayed.
3. Navigator will try to select controls when Select Objects is selected in
the popup menu.
4. It is not always possible to select controls. As I recall, controls in
groups can be selected, controls in stacks displaying as palettes or in
other modes cannot. I'm not sure about controls on not-currently-displayed
cards.
5. Because of (4) and (1), It is not always the case that selecting
"Inspector" in the IDE toolbar will open an inspector for whatever is
selected in Navigator.

1. Inspector palettes can be locked or unlocked. This is indicated by the
small padlock that is, for me at least, the left-most of the right group of
icons at the top of the inspector. This is unrelated to Navigator; you can
click the lock or unlock the inspector.
2. I don't know the particulars of the lock in the IDE; as far as I know,
it always starts out unlocked.
3. If you select "Single Object Inspector" from either the popup menu or
the properties menu, Navigator will do its best to select the highlighted
objects, and then open the inspector unlocked. The inspector reflects the
current selection. So for example, selecting two cards and then "Single
Object Inspector" *has* to fail; LiveCode doesn't support selecting two
cards at once. Likewise, selecting ar card that is not the current card of
the particular stack and then "Single Object Inspector" will also fail, and
display the stack.

I can't fix this; what to display when the inspector is unlocked is up to
the inspector code.

The alternative -- Individual Object Inspectors -- *will* work. It opens
one copy of the inspector for each control in Navigator's selection, and
opens them with the lock closed.This allows the inspector to reflect
anything. But it does have the drawback of opening an individual palette
for each control. I think I put a warning in if the number of controls is
large, with an option to cancel.

Then there is the use case where you want to have just one inspector,
reflecting a number of controls that might not be "select"-able. As far as
I know the IDE palette doesn't support this.

Navigator's Property Editor does. It reflects any selected controls in
Navigator when it is opened, and can set properties for all of them at
once. It can also be opened as a separate palette. In that case it reflects
the most recent selection in whichever copy of Navigator you interact with,
meaning that if you make a new selection of controls in a different copy of
Navigator, that will be reflected in the palette. The Navigator Property
Editor is a simple list for speed. It displays only the properties the
controls have in common, snd bolds the ones where the obects' properties
differ. There's more to the palette, but I don't want to write (more of) a
novel.

Hopefully this helps. As far as I know Navigator is working properly
regarding this use case.

Thanks for the feedback!

Geoff

On Thu, Sep 8, 2022 at 8:38 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Yes that works. What doesn't work is selecting the card in the list, then
> clicking the Inspector button in the LC IDE toolbar. It's easier for me to
> do that because if I click another object in Navigator, the focus of the
> Inspector (Properties Editor) changes to the selected object. If I do the
> right-click single object method, sometimes the focus does NOT change, and
> I have to do the right-click thungummy again.
>
> Bob S
>
>
> On Sep 8, 2022, at 24:54 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com>
> wrote:
>
> Can you be more specific? I tried selecting the card both in the live
> display and the specific card display, and then on the Properties "P" menu
> I selected Property Editor, Single Object Inspector, and Individual Object
> Inspectors, and it always came up showing the card.
>
> ___
> use-livecode mailing list
> use-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: Stylistic question.

[Bob Sneidar via use-livecode]

Yes that works. What doesn't work is selecting the card in the list, then 
clicking the Inspector button in the LC IDE toolbar. It's easier for me to do 
that because if I click another object in Navigator, the focus of the Inspector 
(Properties Editor) changes to the selected object. If I do the right-click 
single object method, sometimes the focus does NOT change, and I have to do the 
right-click thungummy again.

Bob S


On Sep 8, 2022, at 24:54 , Geoff Canyon via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Can you be more specific? I tried selecting the card both in the live
display and the specific card display, and then on the Properties "P" menu
I selected Property Editor, Single Object Inspector, and Individual Object
Inspectors, and it always came up showing the card.

___
use-livecode mailing list
use-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: Stylistic question.

[Geoff Canyon via use-livecode]

Can you be more specific? I tried selecting the card both in the live
display and the specific card display, and then on the Properties "P" menu
I selected Property Editor, Single Object Inspector, and Individual Object
Inspectors, and it always came up showing the card.

On Wed, Sep 7, 2022 at 3:04 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> While you are at it, selecting the card, then selecting the Inspector
> button in the toolbar gets the stack properties, not the card properties. I
> know I can right-click and get the card properties, but if this is not the
> intended behavior I figured you'd want to know.
>
> Bob S
>
>
> > On Sep 7, 2022, at 08:03 , Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Awesome good job.
> >
> > Bob S
> >
> >
> >> On Sep 7, 2022, at 24:16 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> Okay, I figured it out. When Navigator is displaying whatever the
> contents
> >> are of the current card (its default state) it syncs the selection with
> the
> >> selected controls. This goes both ways, so it's important not to get
> stuck
> >> in a loop: Navigator sets the selected controls, which in turn triggers
> >> Navigator to update its selection, which sets the selected controls,
> and so
> >> on.
> >>
> >> My code set a flag when changing the selection to stop that endless
> cycle,
> >> and that flag was stopping updates when the filter changes.
> >>
> >> So selections were retained when a specific card or group was displayed,
> >> but not retained when showing the top card "live".
> >>
> >> I've fixed this I think. I've also fixed named bookmark sets. I want to
> add
> >> an option on stacks to display all cards within the stack (and maybe all
> >> controls within the stack). And I want to run some tests on how fast
> >> Navigator is at this point, and do some regression testing, and then
> I'll
> >> release an update.
> >>
> >> Thanks for the report!
> >>
> >> gc
> >>
> >> On Tue, Sep 6, 2022 at 8:50 AM Bob Sneidar via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >>> I went to Github, the latest version is 7.3 RC1 which is what I already
> >>> had. Not sure where to look for the most recent version. Issue
> persists for
> >>> me.
> >>>
> >>> Bob S
> >>>
> >>>
>  On Sep 6, 2022, at 08:11 , Bob Sneidar via use-livecode <
> >>> use-livecode@lists.runrev.com> wrote:
> 
>  I'll have a look.
> 
>  Bob S
> 
> 
>  On Sep 5, 2022, at 19:11 , Geoff Canyon via use-livecode <
> >>> use-livecode@lists.runrev.com>
> >>> wrote:
> 
>  On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
>  use-livecode@lists.runrev.com>
> >>> wrote:
>  I will however ask for just one enhancement: If I am filtering the
> list
>  and have an item or items selected, and then I clear the filter, it
> also
>  clears the selection. It would be great if the selection could be
>  maintained or restored.
> 
>  I checked, and there is code that is supposed to do exactly this. I
>  checked, and at least in the simple scenarios I tried, it works as
>  advertised. Do you have a recipe to make it not work?
> 
>  Note: I think I added this fairly recently, so you probably need the
> most
>  recent version (or nearly so) for this to work.
> 
>  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
> >
> >
> > ___
> > use-livecode mailing list
> > use-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.runr

Re: Stylistic question.

[Geoff Canyon via use-livecode]

Hmm, I'll take a look.

On Wed, Sep 7, 2022 at 3:04 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> While you are at it, selecting the card, then selecting the Inspector
> button in the toolbar gets the stack properties, not the card properties. I
> know I can right-click and get the card properties, but if this is not the
> intended behavior I figured you'd want to know.
>
> Bob S
>
>
> > On Sep 7, 2022, at 08:03 , Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Awesome good job.
> >
> > Bob S
> >
> >
> >> On Sep 7, 2022, at 24:16 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >>
> >> Okay, I figured it out. When Navigator is displaying whatever the
> contents
> >> are of the current card (its default state) it syncs the selection with
> the
> >> selected controls. This goes both ways, so it's important not to get
> stuck
> >> in a loop: Navigator sets the selected controls, which in turn triggers
> >> Navigator to update its selection, which sets the selected controls,
> and so
> >> on.
> >>
> >> My code set a flag when changing the selection to stop that endless
> cycle,
> >> and that flag was stopping updates when the filter changes.
> >>
> >> So selections were retained when a specific card or group was displayed,
> >> but not retained when showing the top card "live".
> >>
> >> I've fixed this I think. I've also fixed named bookmark sets. I want to
> add
> >> an option on stacks to display all cards within the stack (and maybe all
> >> controls within the stack). And I want to run some tests on how fast
> >> Navigator is at this point, and do some regression testing, and then
> I'll
> >> release an update.
> >>
> >> Thanks for the report!
> >>
> >> gc
> >>
> >> On Tue, Sep 6, 2022 at 8:50 AM Bob Sneidar via use-livecode <
> >> use-livecode@lists.runrev.com> wrote:
> >>
> >>> I went to Github, the latest version is 7.3 RC1 which is what I already
> >>> had. Not sure where to look for the most recent version. Issue
> persists for
> >>> me.
> >>>
> >>> Bob S
> >>>
> >>>
>  On Sep 6, 2022, at 08:11 , Bob Sneidar via use-livecode <
> >>> use-livecode@lists.runrev.com> wrote:
> 
>  I'll have a look.
> 
>  Bob S
> 
> 
>  On Sep 5, 2022, at 19:11 , Geoff Canyon via use-livecode <
> >>> use-livecode@lists.runrev.com>
> >>> wrote:
> 
>  On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
>  use-livecode@lists.runrev.com>
> >>> wrote:
>  I will however ask for just one enhancement: If I am filtering the
> list
>  and have an item or items selected, and then I clear the filter, it
> also
>  clears the selection. It would be great if the selection could be
>  maintained or restored.
> 
>  I checked, and there is code that is supposed to do exactly this. I
>  checked, and at least in the simple scenarios I tried, it works as
>  advertised. Do you have a recipe to make it not work?
> 
>  Note: I think I added this fairly recently, so you probably need the
> most
>  recent version (or nearly so) for this to work.
> 
>  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
> >
> >
> > ___
> > use-livecode mailing list
> > use-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: Stylistic question.

[Bob Sneidar via use-livecode]

While you are at it, selecting the card, then selecting the Inspector button in 
the toolbar gets the stack properties, not the card properties. I know I can 
right-click and get the card properties, but if this is not the intended 
behavior I figured you'd want to know. 

Bob S


> On Sep 7, 2022, at 08:03 , Bob Sneidar via use-livecode 
>  wrote:
> 
> Awesome good job. 
> 
> Bob S
> 
> 
>> On Sep 7, 2022, at 24:16 , Geoff Canyon via use-livecode 
>>  wrote:
>> 
>> Okay, I figured it out. When Navigator is displaying whatever the contents
>> are of the current card (its default state) it syncs the selection with the
>> selected controls. This goes both ways, so it's important not to get stuck
>> in a loop: Navigator sets the selected controls, which in turn triggers
>> Navigator to update its selection, which sets the selected controls, and so
>> on.
>> 
>> My code set a flag when changing the selection to stop that endless cycle,
>> and that flag was stopping updates when the filter changes.
>> 
>> So selections were retained when a specific card or group was displayed,
>> but not retained when showing the top card "live".
>> 
>> I've fixed this I think. I've also fixed named bookmark sets. I want to add
>> an option on stacks to display all cards within the stack (and maybe all
>> controls within the stack). And I want to run some tests on how fast
>> Navigator is at this point, and do some regression testing, and then I'll
>> release an update.
>> 
>> Thanks for the report!
>> 
>> gc
>> 
>> On Tue, Sep 6, 2022 at 8:50 AM Bob Sneidar via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> 
>>> I went to Github, the latest version is 7.3 RC1 which is what I already
>>> had. Not sure where to look for the most recent version. Issue persists for
>>> me.
>>> 
>>> Bob S
>>> 
>>> 
 On Sep 6, 2022, at 08:11 , Bob Sneidar via use-livecode <
>>> use-livecode@lists.runrev.com> wrote:
 
 I'll have a look.
 
 Bob S
 
 
 On Sep 5, 2022, at 19:11 , Geoff Canyon via use-livecode <
>>> use-livecode@lists.runrev.com>
>>> wrote:
 
 On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
 use-livecode@lists.runrev.com>
>>> wrote:
 I will however ask for just one enhancement: If I am filtering the list
 and have an item or items selected, and then I clear the filter, it also
 clears the selection. It would be great if the selection could be
 maintained or restored.
 
 I checked, and there is code that is supposed to do exactly this. I
 checked, and at least in the simple scenarios I tried, it works as
 advertised. Do you have a recipe to make it not work?
 
 Note: I think I added this fairly recently, so you probably need the most
 recent version (or nearly so) for this to work.
 
 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
> 
> 
> ___
> use-livecode mailing list
> use-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: Stylistic question.

[Bob Sneidar via use-livecode]

Awesome good job. 

Bob S


> On Sep 7, 2022, at 24:16 , Geoff Canyon via use-livecode 
>  wrote:
> 
> Okay, I figured it out. When Navigator is displaying whatever the contents
> are of the current card (its default state) it syncs the selection with the
> selected controls. This goes both ways, so it's important not to get stuck
> in a loop: Navigator sets the selected controls, which in turn triggers
> Navigator to update its selection, which sets the selected controls, and so
> on.
> 
> My code set a flag when changing the selection to stop that endless cycle,
> and that flag was stopping updates when the filter changes.
> 
> So selections were retained when a specific card or group was displayed,
> but not retained when showing the top card "live".
> 
> I've fixed this I think. I've also fixed named bookmark sets. I want to add
> an option on stacks to display all cards within the stack (and maybe all
> controls within the stack). And I want to run some tests on how fast
> Navigator is at this point, and do some regression testing, and then I'll
> release an update.
> 
> Thanks for the report!
> 
> gc
> 
> On Tue, Sep 6, 2022 at 8:50 AM Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> I went to Github, the latest version is 7.3 RC1 which is what I already
>> had. Not sure where to look for the most recent version. Issue persists for
>> me.
>> 
>> Bob S
>> 
>> 
>>> On Sep 6, 2022, at 08:11 , Bob Sneidar via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>>> 
>>> I'll have a look.
>>> 
>>> Bob S
>>> 
>>> 
>>> On Sep 5, 2022, at 19:11 , Geoff Canyon via use-livecode <
>> use-livecode@lists.runrev.com>
>> wrote:
>>> 
>>> On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
>>> use-livecode@lists.runrev.com>
>> wrote:
>>> I will however ask for just one enhancement: If I am filtering the list
>>> and have an item or items selected, and then I clear the filter, it also
>>> clears the selection. It would be great if the selection could be
>>> maintained or restored.
>>> 
>>> I checked, and there is code that is supposed to do exactly this. I
>>> checked, and at least in the simple scenarios I tried, it works as
>>> advertised. Do you have a recipe to make it not work?
>>> 
>>> Note: I think I added this fairly recently, so you probably need the most
>>> recent version (or nearly so) for this to work.
>>> 
>>> 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


___
use-livecode mailing list
use-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: Stylistic question.

[Geoff Canyon via use-livecode]

Okay, I figured it out. When Navigator is displaying whatever the contents
are of the current card (its default state) it syncs the selection with the
selected controls. This goes both ways, so it's important not to get stuck
in a loop: Navigator sets the selected controls, which in turn triggers
Navigator to update its selection, which sets the selected controls, and so
on.

My code set a flag when changing the selection to stop that endless cycle,
and that flag was stopping updates when the filter changes.

So selections were retained when a specific card or group was displayed,
but not retained when showing the top card "live".

I've fixed this I think. I've also fixed named bookmark sets. I want to add
an option on stacks to display all cards within the stack (and maybe all
controls within the stack). And I want to run some tests on how fast
Navigator is at this point, and do some regression testing, and then I'll
release an update.

Thanks for the report!

gc

On Tue, Sep 6, 2022 at 8:50 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I went to Github, the latest version is 7.3 RC1 which is what I already
> had. Not sure where to look for the most recent version. Issue persists for
> me.
>
> Bob S
>
>
> > On Sep 6, 2022, at 08:11 , Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I'll have a look.
> >
> > Bob S
> >
> >
> > On Sep 5, 2022, at 19:11 , Geoff Canyon via use-livecode <
> use-livecode@lists.runrev.com>
> wrote:
> >
> > On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
> > use-livecode@lists.runrev.com>
> wrote:
> > I will however ask for just one enhancement: If I am filtering the list
> > and have an item or items selected, and then I clear the filter, it also
> > clears the selection. It would be great if the selection could be
> > maintained or restored.
> >
> > I checked, and there is code that is supposed to do exactly this. I
> > checked, and at least in the simple scenarios I tried, it works as
> > advertised. Do you have a recipe to make it not work?
> >
> > Note: I think I added this fairly recently, so you probably need the most
> > recent version (or nearly so) for this to work.
> >
> > 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: Stylistic question.

[Bob Sneidar via use-livecode]

I went to Github, the latest version is 7.3 RC1 which is what I already had. 
Not sure where to look for the most recent version. Issue persists for me. 

Bob S


> On Sep 6, 2022, at 08:11 , Bob Sneidar via use-livecode 
>  wrote:
> 
> I'll have a look.
> 
> Bob S
> 
> 
> On Sep 5, 2022, at 19:11 , Geoff Canyon via use-livecode 
> mailto:use-livecode@lists.runrev.com>> wrote:
> 
> On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> I will however ask for just one enhancement: If I am filtering the list
> and have an item or items selected, and then I clear the filter, it also
> clears the selection. It would be great if the selection could be
> maintained or restored.
> 
> I checked, and there is code that is supposed to do exactly this. I
> checked, and at least in the simple scenarios I tried, it works as
> advertised. Do you have a recipe to make it not work?
> 
> Note: I think I added this fairly recently, so you probably need the most
> recent version (or nearly so) for this to work.
> 
> 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: Stylistic question.

[Bob Sneidar via use-livecode]

I'll have a look.

Bob S


On Sep 5, 2022, at 19:11 , Geoff Canyon via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:
I will however ask for just one enhancement: If I am filtering the list
and have an item or items selected, and then I clear the filter, it also
clears the selection. It would be great if the selection could be
maintained or restored.

I checked, and there is code that is supposed to do exactly this. I
checked, and at least in the simple scenarios I tried, it works as
advertised. Do you have a recipe to make it not work?

Note: I think I added this fairly recently, so you probably need the most
recent version (or nearly so) for this to work.

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: Stylistic question.

[Geoff Canyon via use-livecode]

Ha, I just realized that I responded to the Navigator part of the
conversation without responding to the style part. When I wrote the
"convert a control(s) to behaviors" code, I didn't think twice about what
to apply it to or not -- I selected everything and converted it all. That
was something like five or six years ago, and: Navigator, which I work on
seriously, is all behavior scripts. Everything else, which is *not*
serious, is zero behavior scripts. I think it needs to be a setting at the
IDE level for behaviors to be a thing (for me).

For the original question, I always put code in the control that's doing
the work, unless it's shared. So utility routines and functions in the
card, regular code in the button.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stylistic question.

[Pi Digital via use-livecode]

Arriving late to the conversation. I never put code into buttons other that 
enough to cover messages. These will only have enough code in them to pass on 
the rest of the message. Eg

on mouseUp pBtn
btn_nameOfButtonMUp pBtn
end mouseUp

on mouseRelease
btn_nameOfBtnMRel
end mouseRelease

Then I’d have the main code in either the card or stack script. Cards and 
stacks are a lot harder to delete than an object. Too many times I’ve seen 
objects get deleted accidentally and loose a heap of code. 

For what it’s worth, my preference is for If/Then/Else rather than 
Switch/Case/Default. But sometimes it is better, not to mention faster. But 
even so, for something like an option button I would use

on menuPick pOption
btn_btnNameMenuP pOption
end menuPick

Rather than put the switch code into the button. Rebuilding those few lines of 
code in a lost/deleted button is far easier than trying to remember all of the 
other operations it could have had in it. 

I hope you are all well, btw :)

Sean Cole
Pi Digital
___
use-livecode mailing list
use-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: Stylistic question.

[Geoff Canyon via use-livecode]

On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:
> I will however ask for just one enhancement: If I am filtering the list
and have an item or items selected, and then I clear the filter, it also
clears the selection. It would be great if the selection could be
maintained or restored.

I checked, and there is code that is supposed to do exactly this. I
checked, and at least in the simple scenarios I tried, it works as
advertised. Do you have a recipe to make it not work?

Note: I think I added this fairly recently, so you probably need the most
recent version (or nearly so) for this to work.

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: Stylistic question.

[Geoff Canyon via use-livecode]

On Thu, Sep 1, 2022 at 10:32 AM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I will however ask for just one enhancement: If I am filtering the list
> and have an item or items selected, and then I clear the filter, it also
> clears the selection. It would be great if the selection could be
> maintained or restored.
>

I'm surprised it doesn't actually. I'll take a look.

And: thanks for the kind words. I'm still surprised by its longevity.

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: Stylistic question.

[Bob Sneidar via use-livecode]

by Navigator I was put off by Navigator at first, mainly because it was able to 
do a LOT, and I was looking for an easy answer to a complex problem: How to set 
properties for objects in a much more intuitive way that the LC Property 
Editor. 

Once I started using it however, I cannot imagine how I lived without it. I 
don't think I am going too far to say that it is in the top 3 most useful 
interface enhancements ever developed in LC. 

I will however ask for just one enhancement: If I am filtering the list and 
have an item or items selected, and then I clear the filter, it also clears the 
selection. It would be great if the selection could be maintained or restored. 

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

Re: Stylistic question.

[Geoff Canyon via use-livecode]

Sorry for the late response, but thanks for the shoutout. I'll also mention
that some time ago I put a fair bit of effort into enabling Navigator to
behavior-ify any set of controls, automatically extracting their built-in
code to script-only-stacks. I did it as part of the migration of Navigator
to SOS behaviors. I haven't checked to make sure, but I believe *all code*
in Navigator is a SOS-behavior; and I did that automatically from a
no-behaviors standing start with a simple command in Navigator itself. The
end result is that there can be any number of Navigator windows without any
duplication of code at all. Previously I had built Navigator with three
built-in copies, at the cost of making it three times as large. That wasn't
such a terrible thing, but I did find that anything beyond three copies
eventually broke (no idea why). Since migrating 100% to behaviors, I've
tried, I think, having ten copies open with no problem.

Disclaimer/warning: I wrote that code five years ago and haven't looked at
it since. No one has told me it doesn't work, but I only used it the one
time on Navigator itself. So work on a copy, please.

gc

On Wed, Jun 22, 2022 at 1:25 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Well then Navigator is for you! If an object has a behavior and no script
> of it's own, it's color in the list is green. If it has a script but no
> behavior, it's color is blue. If it has both, it's purple. Simply double
> clicking an object opens it's behavior script if it has one, and it's
> native script if it doesn't.
>
> You don't have to keep track of anything anymore.
>
> Bob S
>
>
> > On Jun 22, 2022, at 12:41 , J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I find that too many behavior stacks make it difficult to keep track of
> where things are. But the primary downside is that script-only stacks don't
> work with remote debugging. That's a big drawback for me since most of my
> apps these days are for mobile. I do use behaviors quite a bit, but I put
> the scripts into buttons so they can be debugged remotely. Or maybe you
> mean you use regular stacks for behaviors? Those would work.
> >
> > The switch construct is way more flexible than if/then and much cleaner
> to read and track. I use them all the time. They're especially useful when
> you want to group several conditionals. What don't you like about them?
> Just curious.
> >
> > --
> > Jacqueline Landman Gay | jac...@hyperactivesw.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Stylistic question.

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> Breakpoints work fine in the IDE. But script only stacks do not
> retain them when remote debugging

Breakpoints are a runtime-settable property, so those who enjoy 
C-flavored workflows with lots of tiny text files could save their 
breakpoints out to text files and have a module load them in again at 
runtime.


Maybe that could be added to any of the tools that turn normal 
stackfiles into script-only stack files and back again so they can be 
worked on.


Then we could add a tool to handle custom props, turning those into JSON 
files and back again.


Then the UI stuff could still be binary like it is with Apple's tools, 
and as long as we don't call them stackfiles but call them NIBs instead 
then it's cool again. :)


::ducking::

#FaFaFaFashion

--
 Richard Gaskin
 Fourth World Systems

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

Re: Stylistic question.

[Mike Kerner via use-livecode]

Red-dotting:
A couple of things:
1) I don't use the SE very often, so I have not tried red-dotting before
building. However, "BREAKPOINT" works.
2) Once you have the remote debugger up, you can red-dot all you like, and
they will stick until the app closes
3) When I'm debugging (like I am, tonight), I have a group of debugging
buttons that I have show in the app. One of those is just
on mouseUp
  global lastCommand
  ask "What" with lastCommand
  if it is not empty then
put it into lastCommand
do it
  end if
end mouseUp
When the dialog pops up, I type something like
breakpoint; send "mouseUp" to someControl

and I'm in the debugger, in that control

On Thu, Jun 23, 2022 at 1:34 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> OIC I didn't grok you were talking about standalone apps.
>
> Bob S
>
>
> > On Jun 23, 2022, at 10:25 , J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Breakpoints work fine in the IDE. But script only stacks do not retain
> them when remote debugging, or at least they didn't for me. Are you talking
> about mobile apps?
> > --
> > Jacqueline Landman Gay | jac...@hyperactivesw.com
> > HyperActive Software | http://www.hyperactivesw.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


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

Re: Stylistic question.

[Bob Sneidar via use-livecode]

OIC I didn't grok you were talking about standalone apps. 

Bob S


> On Jun 23, 2022, at 10:25 , J. Landman Gay via use-livecode 
>  wrote:
> 
> Breakpoints work fine in the IDE. But script only stacks do not retain them 
> when remote debugging, or at least they didn't for me. Are you talking about 
> mobile apps?
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com


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

Re: Stylistic question.

[J. Landman Gay via use-livecode]

Breakpoints work fine in the IDE. But script only stacks do not retain them 
when remote debugging, or at least they didn't for me. Are you talking 
about mobile apps?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 23, 2022 12:05:27 PM Bob Sneidar via use-livecode 
 wrote:


Hi Jacqueline. I use script only stacks a LOT, and the red dot breakpoints 
are working for me. Try Clear All Breakpoints from the SE Debug menu (I 
think it will only clear breakpoints from open scripts though.) Also in the 
SE under the Breakpoints tab, you can uncheck all the existing breakpoints.


Bob S


On Jun 23, 2022, at 09:59 , J. Landman Gay via use-livecode 
 wrote:


Something must have changed or you use a debugging method different from 
mine. Red dot breakpoints do not work in script only stacks because those 
stacks have no custom properties, which is where breakpoints are kept. I 
couldn't get scripted breakpoints to work either but I may have forgotten 
to save correctly.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com



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

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





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

Re: Stylistic question.

[Bob Sneidar via use-livecode]

Hi Jacqueline. I use script only stacks a LOT, and the red dot breakpoints are 
working for me. Try Clear All Breakpoints from the SE Debug menu (I think it 
will only clear breakpoints from open scripts though.) Also in the SE under the 
Breakpoints tab, you can uncheck all the existing breakpoints. 

Bob S


> On Jun 23, 2022, at 09:59 , J. Landman Gay via use-livecode 
>  wrote:
> 
> Something must have changed or you use a debugging method different from 
> mine. Red dot breakpoints do not work in script only stacks because those 
> stacks have no custom properties, which is where breakpoints are kept. I 
> couldn't get scripted breakpoints to work either but I may have forgotten to 
> save correctly.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com


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

Re: Stylistic question.

[J. Landman Gay via use-livecode]

Something must have changed or you use a debugging method different from 
mine. Red dot breakpoints do not work in script only stacks because those 
stacks have no custom properties, which is where breakpoints are kept. I 
couldn't get scripted breakpoints to work either but I may have forgotten 
to save correctly.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 22, 2022 8:14:45 PM Mike Kerner via use-livecode 
 wrote:



All of these behaviors are in script-only-stacks. I have zero difficulty
debugging them with the remote debugger.




___
use-livecode mailing list
use-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: Stylistic question.

[Mike Kerner via use-livecode]

J.:
Not true on the remote debugging.
Everything I write is for mobes. Literally everything. Except for the
server code for the mobes, but comparatively speaking, there are many,
many, many more lines in the mobe code than there is in the server code.
All of these behaviors are in script-only-stacks. I have zero difficulty
debugging them with the remote debugger.
I have not found that I have too many files, but I also organize them into
folders, as needed, and I do just about all of my editing in Sublime, which
makes keeping the project straight very easy.
The dislike I have for switch is a personal thing. I get that it's very
similar to the way switch is used in other tongues. Maybe it's the way it
looks. Maybe it's the break at the end of each segment. I don't know. It
always feels clunky to write and it feels clunky to read.

On Wed, Jun 22, 2022 at 4:25 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Well then Navigator is for you! If an object has a behavior and no script
> of it's own, it's color in the list is green. If it has a script but no
> behavior, it's color is blue. If it has both, it's purple. Simply double
> clicking an object opens it's behavior script if it has one, and it's
> native script if it doesn't.
>
> You don't have to keep track of anything anymore.
>
> Bob S
>
>
> > On Jun 22, 2022, at 12:41 , J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > I find that too many behavior stacks make it difficult to keep track of
> where things are. But the primary downside is that script-only stacks don't
> work with remote debugging. That's a big drawback for me since most of my
> apps these days are for mobile. I do use behaviors quite a bit, but I put
> the scripts into buttons so they can be debugged remotely. Or maybe you
> mean you use regular stacks for behaviors? Those would work.
> >
> > The switch construct is way more flexible than if/then and much cleaner
> to read and track. I use them all the time. They're especially useful when
> you want to group several conditionals. What don't you like about them?
> Just curious.
> >
> > --
> > Jacqueline Landman Gay | jac...@hyperactivesw.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


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

Re: Stylistic question.

[Bob Sneidar via use-livecode]

Well then Navigator is for you! If an object has a behavior and no script of 
it's own, it's color in the list is green. If it has a script but no behavior, 
it's color is blue. If it has both, it's purple. Simply double clicking an 
object opens it's behavior script if it has one, and it's native script if it 
doesn't. 

You don't have to keep track of anything anymore. 

Bob S


> On Jun 22, 2022, at 12:41 , J. Landman Gay via use-livecode 
>  wrote:
> 
> I find that too many behavior stacks make it difficult to keep track of where 
> things are. But the primary downside is that script-only stacks don't work 
> with remote debugging. That's a big drawback for me since most of my apps 
> these days are for mobile. I do use behaviors quite a bit, but I put the 
> scripts into buttons so they can be debugged remotely. Or maybe you mean you 
> use regular stacks for behaviors? Those would work.
> 
> The switch construct is way more flexible than if/then and much cleaner to 
> read and track. I use them all the time. They're especially useful when you 
> want to group several conditionals. What don't you like about them? Just 
> curious.
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com


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

Re: Stylistic question.

[J. Landman Gay via use-livecode]

I find that too many behavior stacks make it difficult to keep track of 
where things are. But the primary downside is that script-only stacks don't 
work with remote debugging. That's a big drawback for me since most of my 
apps these days are for mobile. I do use behaviors quite a bit, but I put 
the scripts into buttons so they can be debugged remotely. Or maybe you 
mean you use regular stacks for behaviors? Those would work.


The switch construct is way more flexible than if/then and much cleaner to 
read and track. I use them all the time. They're especially useful when you 
want to group several conditionals. What don't you like about them? Just 
curious.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 22, 2022 8:49:51 AM Mike Kerner via use-livecode 
 wrote:



For an example like a session during LCG, throwing everything into a single
script can make it easier to see everything, together, however,
I absolutely, always, without exception, do this:
1) Every object that needs to do something gets its own handler, unless
there is some reason to allow the behavior to pass up the chain. This
situation is not one of them.
2) I don't use scripts, at all, ever. Every handler is in a behavior stack.
3) I don't ever use switch. I can't stand it. If I had to write something
like the above, I would do something like
put the short name of the target into snot
if snot is "first" then
 doCommandFirst
else if snot is "another"
 doCommandAnother
else if snot is "lastnotleast"
 doCommandLastNotLeast
else # uh oh
 answer "ruh roh."
end if # snot is "first"

this assumes that the names of the handlers I would be calling are not
named like the ones in the example, because if they were, you could also
put the short name of the target into snot
put "doCommand" & snot into toDo
try
 do toDo
catch e
 answer "ruh roh."
end try

On Sun, Jun 19, 2022 at 4:33 PM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:


I've noticed that in a lot of the example code I've seen recently,
there's a bit of a common pattern.

In the card script, there will be code like

on mouseUp
   switch the short name of the target
 case "first"
 doCommandFirst
 break
 case "another"
 doCommandAnother
 break
 case "lastnotleast"
 doCommandlastnotleast
 break
   end switch
end mouseUp

I've seen this in examples from Livecloud, Appli, the WebApp example
from Steven/Michael, and a few other places.

I would generally have put this code in each button (or other control)
directly, and I'm wondering whether there are advantages or preferences
for one of those versus the other.

Thanks for any opinions,

Alex.


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




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

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





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

Re: Stylistic question.

[Mike Kerner via use-livecode]

wupz. - i forgot the THEN's after each of the ELSE IF's
too many languages on the same project swimming in my brain

On Wed, Jun 22, 2022 at 9:46 AM Mike Kerner 
wrote:

> For an example like a session during LCG, throwing everything into a
> single script can make it easier to see everything, together, however,
> I absolutely, always, without exception, do this:
> 1) Every object that needs to do something gets its own handler, unless
> there is some reason to allow the behavior to pass up the chain. This
> situation is not one of them.
> 2) I don't use scripts, at all, ever. Every handler is in a behavior stack.
> 3) I don't ever use switch. I can't stand it. If I had to write something
> like the above, I would do something like
> put the short name of the target into snot
> if snot is "first" then
>   doCommandFirst
> else if snot is "another"
>   doCommandAnother
> else if snot is "lastnotleast"
>   doCommandLastNotLeast
> else # uh oh
>   answer "ruh roh."
> end if # snot is "first"
>
> this assumes that the names of the handlers I would be calling are not
> named like the ones in the example, because if they were, you could also
> put the short name of the target into snot
> put "doCommand" & snot into toDo
> try
>   do toDo
> catch e
>   answer "ruh roh."
> end try
>
> On Sun, Jun 19, 2022 at 4:33 PM Alex Tweedly via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> I've noticed that in a lot of the example code I've seen recently,
>> there's a bit of a common pattern.
>>
>> In the card script, there will be code like
>>
>> on mouseUp
>>switch the short name of the target
>>  case "first"
>>  doCommandFirst
>>  break
>>  case "another"
>>  doCommandAnother
>>  break
>>  case "lastnotleast"
>>  doCommandlastnotleast
>>  break
>>end switch
>> end mouseUp
>>
>> I've seen this in examples from Livecloud, Appli, the WebApp example
>> from Steven/Michael, and a few other places.
>>
>> I would generally have put this code in each button (or other control)
>> directly, and I'm wondering whether there are advantages or preferences
>> for one of those versus the other.
>>
>> Thanks for any opinions,
>>
>> Alex.
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
>


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

Re: Stylistic question.

[Mike Kerner via use-livecode]

For an example like a session during LCG, throwing everything into a single
script can make it easier to see everything, together, however,
I absolutely, always, without exception, do this:
1) Every object that needs to do something gets its own handler, unless
there is some reason to allow the behavior to pass up the chain. This
situation is not one of them.
2) I don't use scripts, at all, ever. Every handler is in a behavior stack.
3) I don't ever use switch. I can't stand it. If I had to write something
like the above, I would do something like
put the short name of the target into snot
if snot is "first" then
  doCommandFirst
else if snot is "another"
  doCommandAnother
else if snot is "lastnotleast"
  doCommandLastNotLeast
else # uh oh
  answer "ruh roh."
end if # snot is "first"

this assumes that the names of the handlers I would be calling are not
named like the ones in the example, because if they were, you could also
put the short name of the target into snot
put "doCommand" & snot into toDo
try
  do toDo
catch e
  answer "ruh roh."
end try

On Sun, Jun 19, 2022 at 4:33 PM Alex Tweedly via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I've noticed that in a lot of the example code I've seen recently,
> there's a bit of a common pattern.
>
> In the card script, there will be code like
>
> on mouseUp
>switch the short name of the target
>  case "first"
>  doCommandFirst
>  break
>  case "another"
>  doCommandAnother
>  break
>  case "lastnotleast"
>  doCommandlastnotleast
>  break
>end switch
> end mouseUp
>
> I've seen this in examples from Livecloud, Appli, the WebApp example
> from Steven/Michael, and a few other places.
>
> I would generally have put this code in each button (or other control)
> directly, and I'm wondering whether there are advantages or preferences
> for one of those versus the other.
>
> Thanks for any opinions,
>
> Alex.
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>


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

Re: Stylistic question.

[Alex Tweedly via use-livecode]

On 20/06/2022 00:19, Bob Sneidar via use-livecode wrote:

Well code shared commonly between multiple objects should generally be in an 
object shared by those objects. That can be the card, stack, behavior or 
front/back script. The script of a group as well.


Absolutely. And the converse - code that is not shared should be as low 
in the hierarchy as possible.


In this case, there is really no shared code.

If it's button "first" you call one handler. If it's button "whatever I 
called the second", you call a different handler. etc.  Nothing shared 
at all.



As to Brian's point about behaviours and Git, I can see that. I admit to 
being slightly "slack" about what code needs to go into behaviour 
scripts so it can be Gitted. If it's code that is very brief, and will 
"never" change, I put that in the regular stack. So in this case, I'd 
have the script of button "first" be


on mouseUp
   doCommandFirst
end mouseUp

and I'm willing to bet that will ever change :-)


For example I have a behavior for all my datagrids. Each datagrid has a 
property called gridconstants which is an array of all the things specific to 
each datagrid. The behavior handlers will get this property so that I can use 
generic terms in the behavior like cTableName and cPriKey etc. Now my behavior 
handlers like selectionChanged and such become universal to all my datagrids. 
Only one place to edit the handlers now.


Sounds cool. If I ever use a Datagrid, I'll do that.

Alex.


If I need to do anything specific with a datagrid, I keep those handlers in 
each datagrid script.

Sent from my iPhone


On Jun 19, 2022, at 14:09, Brian Milby via use-livecode 
 wrote:

One reason would be if you were trying to use behaviors so you could manage 
your code with a repository like Git.  This would greatly reduce the number of 
behavior scripts that you would create.  One app that work on has the code in 
the stack’s behavior script.

Sent from my iPhone


On Jun 19, 2022, at 4:33 PM, Alex Tweedly via use-livecode 
 wrote:

I've noticed that in a lot of the example code I've seen recently, there's a 
bit of a common pattern.

In the card script, there will be code like

on mouseUp
  switch the short name of the target
case "first"
doCommandFirst
break
case "another"
doCommandAnother
break
case "lastnotleast"
doCommandlastnotleast
break
  end switch
end mouseUp

I've seen this in examples from Livecloud, Appli, the WebApp example from 
Steven/Michael, and a few other places.

I would generally have put this code in each button (or other control) 
directly, and I'm wondering whether there are advantages or preferences for one 
of those versus the other.

Thanks for any opinions,

Alex.


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

___
use-livecode mailing list
use-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: Stylistic question.

[Bob Sneidar via use-livecode]

Well code shared commonly between multiple objects should generally be in an 
object shared by those objects. That can be the card, stack, behavior or 
front/back script. The script of a group as well. 

For example I have a behavior for all my datagrids. Each datagrid has a 
property called gridconstants which is an array of all the things specific to 
each datagrid. The behavior handlers will get this property so that I can use 
generic terms in the behavior like cTableName and cPriKey etc. Now my behavior 
handlers like selectionChanged and such become universal to all my datagrids. 
Only one place to edit the handlers now.

If I need to do anything specific with a datagrid, I keep those handlers in 
each datagrid script. 

Sent from my iPhone

> On Jun 19, 2022, at 14:09, Brian Milby via use-livecode 
>  wrote:
> 
> One reason would be if you were trying to use behaviors so you could manage 
> your code with a repository like Git.  This would greatly reduce the number 
> of behavior scripts that you would create.  One app that work on has the code 
> in the stack’s behavior script.
> 
> Sent from my iPhone
> 
>> On Jun 19, 2022, at 4:33 PM, Alex Tweedly via use-livecode 
>>  wrote:
>> 
>> I've noticed that in a lot of the example code I've seen recently, there's 
>> a bit of a common pattern.
>> 
>> In the card script, there will be code like
>> 
>> on mouseUp
>>  switch the short name of the target
>>case "first"
>>doCommandFirst
>>break
>>case "another"
>>doCommandAnother
>>break
>>case "lastnotleast"
>>doCommandlastnotleast
>>break
>>  end switch
>> end mouseUp
>> 
>> I've seen this in examples from Livecloud, Appli, the WebApp example from 
>> Steven/Michael, and a few other places.
>> 
>> I would generally have put this code in each button (or other control) 
>> directly, and I'm wondering whether there are advantages or preferences for 
>> one of those versus the other.
>> 
>> Thanks for any opinions,
>> 
>> Alex.
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-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: Stylistic question.

[Brian Milby via use-livecode]

One reason would be if you were trying to use behaviors so you could manage 
your code with a repository like Git.  This would greatly reduce the number of 
behavior scripts that you would create.  One app that work on has the code in 
the stack’s behavior script.

Sent from my iPhone

> On Jun 19, 2022, at 4:33 PM, Alex Tweedly via use-livecode 
>  wrote:
> 
> I've noticed that in a lot of the example code I've seen recently, there's a 
> bit of a common pattern.
> 
> In the card script, there will be code like
> 
> on mouseUp
>   switch the short name of the target
> case "first"
> doCommandFirst
> break
> case "another"
> doCommandAnother
> break
> case "lastnotleast"
> doCommandlastnotleast
> break
>   end switch
> end mouseUp
> 
> I've seen this in examples from Livecloud, Appli, the WebApp example from 
> Steven/Michael, and a few other places.
> 
> I would generally have put this code in each button (or other control) 
> directly, and I'm wondering whether there are advantages or preferences for 
> one of those versus the other.
> 
> Thanks for any opinions,
> 
> Alex.
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Stylistic question.

[Alex Tweedly via use-livecode]

I've noticed that in a lot of the example code I've seen recently, 
there's a bit of a common pattern.


In the card script, there will be code like

on mouseUp
  switch the short name of the target
    case "first"
    doCommandFirst
    break
    case "another"
    doCommandAnother
    break
    case "lastnotleast"
    doCommandlastnotleast
    break
  end switch
end mouseUp

I've seen this in examples from Livecloud, Appli, the WebApp example 
from Steven/Michael, and a few other places.


I would generally have put this code in each button (or other control) 
directly, and I'm wondering whether there are advantages or preferences 
for one of those versus the other.


Thanks for any opinions,

Alex.


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