Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Devin Asay via use-livecode]

On Jun 14, 2017, at 9:21 AM, Devin Asay via use-livecode 
> wrote:

As one who teaches newbies LiveCode, I am a proponent of property labels that 
are both succinct and descriptive, while not straying too far from the actual 
property name. There are obvious exceptions (destroyStack, anyone?). But in 
this case, maybe something like:

Clip child controls to rect

Strikes a good balance between similarity to the property name and giving a 
better idea of what the property does.

I went with Clip child controls to rect.

Join the discussion on the Pull Request on Github if you think it needs 
massaging.

https://github.com/livecode/livecode-ide/pull/1632

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Devin Asay via use-livecode]

Great discussion!

> On Jun 14, 2017, at 1:20 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
> On 2017-06-14 02:18, Monte Goulding via use-livecode wrote:
>> I think this is one of those cases where the default behaviour was a
>> bad idea. Or perhaps was implemented before groups were used for much
>> other than backgrounds. Other objects we need to set to the formatted
>> width/height so why are groups special cased. Anyway, I would keep it
>> simple and use `Clips to rect` so at least it’s easy to relate to the
>> dictionary entry/property name.
> 
> Notionally 'backgrounds' don't really need an extent - they should be card 
> sized - the difference being that controls are shared amongst several cards.
> 
> Of course MetaCard generalized 'the background' to multiple backgrounds and 
> then groups (which aren't backgrounds) - however, as this was done 
> 'evolutionary', we've ended up with several properties for controlling them 
> which interact not-all-that-well.
> 
> If you step back and look at the types of 'group' thing which actually get 
> used, then there are probably only three main ones:
> 
>   1) Card sized layers which are not shared amongst cards (foreground groups, 
> if you like)
> 
>   2) Card sized layers which are shared amongst cards (background groups, if 
> you like)
> 
>   3) Groups with an explicit rect which are not shared amongst cards (control 
> groups, if you like)
> 
> (Variants of these where the content rect is distinct from the visible rect 
> are also plausible - i.e. scrolling views).
> 
> Currently (1) and (2) are catered for because groups (by default) resize to 
> the size of their controls; 'clipsToRect' caters for (3).
> 
> I'd perhaps suggest that 'Clips to rect' or similar is a suitable name for 
> the property. Why? Because that is precisely what it does - all children are 
> clipped to the rect of the group, rather than the group's rect being resized 
> to accomodate them so they are not clipped.
> 


As one who teaches newbies LiveCode, I am a proponent of property labels that 
are both succinct and descriptive, while not straying too far from the actual 
property name. There are obvious exceptions (destroyStack, anyone?). But in 
this case, maybe something like:

Clip child controls to rect

Strikes a good balance between similarity to the property name and giving a 
better idea of what the property does.

Devin


Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Mark Waddingham via use-livecode]

On 2017-06-14 02:18, Monte Goulding via use-livecode wrote:

I think this is one of those cases where the default behaviour was a
bad idea. Or perhaps was implemented before groups were used for much
other than backgrounds. Other objects we need to set to the formatted
width/height so why are groups special cased. Anyway, I would keep it
simple and use `Clips to rect` so at least it’s easy to relate to the
dictionary entry/property name.


Notionally 'backgrounds' don't really need an extent - they should be 
card sized - the difference being that controls are shared amongst 
several cards.


Of course MetaCard generalized 'the background' to multiple backgrounds 
and then groups (which aren't backgrounds) - however, as this was done 
'evolutionary', we've ended up with several properties for controlling 
them which interact not-all-that-well.


If you step back and look at the types of 'group' thing which actually 
get used, then there are probably only three main ones:


   1) Card sized layers which are not shared amongst cards (foreground 
groups, if you like)


   2) Card sized layers which are shared amongst cards (background 
groups, if you like)


   3) Groups with an explicit rect which are not shared amongst cards 
(control groups, if you like)


(Variants of these where the content rect is distinct from the visible 
rect are also plausible - i.e. scrolling views).


Currently (1) and (2) are catered for because groups (by default) resize 
to the size of their controls; 'clipsToRect' caters for (3).


I'd perhaps suggest that 'Clips to rect' or similar is a suitable name 
for the property. Why? Because that is precisely what it does - all 
children are clipped to the rect of the group, rather than the group's 
rect being resized to accomodate them so they are not clipped.


Warmest Regards,

Mark.

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

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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Monte Goulding via use-livecode]

> On 14 Jun 2017, at 3:21 pm, J. Landman Gay via use-livecode 
>  wrote:
> 
> I wonder why we have both lockUpdates and boundingRect. They seem very 
> similar.

Lock updates is intended to avoid recalculation of group properties when child 
object properties are changed. The general idea is:

set the lockUpdates of group X to true
repeat
   — lots of stuff modifying group content here
end repeat
set the lockUpdates of group X to false

It is not saved with the stack as it’s intended to be transient.

So if that’s not clear from the docs we probably have a docs bug. 

I usually avoid boundingRect because you need to remember to update it if you 
change the group rect. clipsToRect is basically the same as:

on resizeControl
  set the boundingRect of me to the rect of me
end resizeControl

Cheers

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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[J. Landman Gay via use-livecode]

I wonder why we have both lockUpdates and boundingRect. They seem very 
similar.


On 6/13/17 7:54 PM, Scott Rossi via use-livecode wrote:

Keep in mind, there’s also the lockUpdates property of groups, which while 
differing mechanically “under the hood”, essentially causes the same perceived 
result — while enabled, a group’s rect is not changed when its child objects 
are resized/repositioned.

I don’t know how all these are verbosely named since I also use the default 
property names.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On Jun 13, 2017, at 3:37 PM, Devin Asay via use-livecode 
 wrote:



On Jun 13, 2017, at 4:19 PM, Devin Asay via use-livecode 
 wrote:

Yes, in essence. If you have a group and set the clipsToRect property to true 
(there’s no way to set it in the PI yet—that’s what I’m going to add), you can 
then change the rect of the group, and the group will *not* automatically reset 
its rect to the size of the child controls + margin. It is persistent, even if 
you leave the card or close the stack. Yet the group’s position and size 
remains unlocked so you can quickly select and change the group’s rect if you 
want. A nice feature when you need it.

ClipsToRect is the property name. So what “plain language” label do you think 
would be best for the PI?


How about “Prevent auto-resize of rect”?



Devin



On Jun 13, 2017, at 4:11 PM, Phil Davis via use-livecode 
> wrote:

So it's about manually updating the rect vs. having it in an auto-update mode?

Phil Davis


On 6/13/17 3:01 PM, Devin Asay via use-livecode wrote:
So far I’m kind of partial to Scott R’s “Persistent rect”. Conversely, it could 
be something like “Auto-update rect”, but then the checkbox would be opposite 
the property setting. That’s almost as bad as something like dontUpdateRect. 
(Sorry, Scott, plug your ears.)

Devin


On Jun 13, 2017, at 3:34 PM, J. Landman Gay via use-livecode 
>
 wrote:

On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:
or
‘Clip Group to rect’

There are a few others like that, where the explanation is just the original 
term (or close) with spaces added. I always felt that didn't explain much. But 
the suggestion does have company in the PI.


Devin Asay
Director
Office of Digital Humanities
Brigham Young University




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




--
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: Instantiaing Grouped Controls - Templates - Responsive

[prothero--- via use-livecode]

What about "keepGroupRect"?

Like set the keepGroupRect of grp "xyz" to true
That way it explicitly limits it to groups. Or it could be
"KeepRect" but that might imply a more general meaning.
Bill P



William Prothero
http://es.earthednet.org

> On Jun 13, 2017, at 5:44 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> james at thehales.id.au wrote:
> 
> > Jacque wrote:
> >> I agree with the concept in general, but the word "crop" implies
> >> permanent removal. When you crop an image, it permanently erases the
> >> parts outside the rectangle. Unfortunately I can't think of a better
> >> term. Maybe something like "prevent auto-resizing"?
> >
> > Actually it doesn't (in practice).
> > Many of the apps I use, use a non destructive crop.
> > That is, the viewable area is reduced to the crop but the full object
> > is still there.
> 
> It varies by app, but it may be worth noting that in LiveCode we have a crop 
> command, and it permanently erases the area outside the crop rect.
> 
> I know it may sound geeky, but maybe describing the clipsToRect with the verb 
> "clips" may not be bad.
> 
> -- 
> 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: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Scott Rossi via use-livecode]

Keep in mind, there’s also the lockUpdates property of groups, which while 
differing mechanically “under the hood”, essentially causes the same perceived 
result — while enabled, a group’s rect is not changed when its child objects 
are resized/repositioned.

I don’t know how all these are verbosely named since I also use the default 
property names.

Regards,

Scott Rossi 
Creative Director 
Tactile Media, UX/UI Design 



> On Jun 13, 2017, at 3:37 PM, Devin Asay via use-livecode 
>  wrote:
> 
>> 
>> On Jun 13, 2017, at 4:19 PM, Devin Asay via use-livecode 
>>  wrote:
>> 
>> Yes, in essence. If you have a group and set the clipsToRect property to 
>> true (there’s no way to set it in the PI yet—that’s what I’m going to add), 
>> you can then change the rect of the group, and the group will *not* 
>> automatically reset its rect to the size of the child controls + margin. It 
>> is persistent, even if you leave the card or close the stack. Yet the 
>> group’s position and size remains unlocked so you can quickly select and 
>> change the group’s rect if you want. A nice feature when you need it.
>> 
>> ClipsToRect is the property name. So what “plain language” label do you 
>> think would be best for the PI?
> 
> How about “Prevent auto-resize of rect”?
> 
>> 
>> Devin
>> 
>> 
>> 
>> On Jun 13, 2017, at 4:11 PM, Phil Davis via use-livecode 
>> > wrote:
>> 
>> So it's about manually updating the rect vs. having it in an auto-update 
>> mode?
>> 
>> Phil Davis
>> 
>> 
>> On 6/13/17 3:01 PM, Devin Asay via use-livecode wrote:
>> So far I’m kind of partial to Scott R’s “Persistent rect”. Conversely, it 
>> could be something like “Auto-update rect”, but then the checkbox would be 
>> opposite the property setting. That’s almost as bad as something like 
>> dontUpdateRect. (Sorry, Scott, plug your ears.)
>> 
>> Devin
>> 
>> 
>> On Jun 13, 2017, at 3:34 PM, J. Landman Gay via use-livecode 
>> >
>>  wrote:
>> 
>> On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:
>> or
>> ‘Clip Group to rect’
>> 
>> There are a few others like that, where the explanation is just the original 
>> term (or close) with spaces added. I always felt that didn't explain much. 
>> But the suggestion does have company in the PI.
> 
> Devin Asay
> Director
> Office of Digital Humanities
> Brigham Young University
> 


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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

james at thehales.id.au wrote:

> Jacque wrote:
>> I agree with the concept in general, but the word "crop" implies
>> permanent removal. When you crop an image, it permanently erases the
>> parts outside the rectangle. Unfortunately I can't think of a better
>> term. Maybe something like "prevent auto-resizing"?
>
> Actually it doesn't (in practice).
> Many of the apps I use, use a non destructive crop.
> That is, the viewable area is reduced to the crop but the full object
> is still there.

It varies by app, but it may be worth noting that in LiveCode we have a 
crop command, and it permanently erases the area outside the crop rect.


I know it may sound geeky, but maybe describing the clipsToRect with the 
verb "clips" may not be bad.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[james--- via use-livecode]

Jacque wrote:
> I agree with the concept in general, but the word "crop" implies 
> permanent removal. When you crop an image, it permanently erases the 
> parts outside the rectangle. Unfortunately I can't think of a better 
> term. Maybe something like "prevent auto-resizing"?

Actually it doesn't (in practice).
Many of the apps I use, use a non destructive crop. 
That is, the viewable area is reduced to the crop but the full object is still 
there.
Apple's own Preview is a good example as are many other graphic apps.

James

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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Monte Goulding via use-livecode]

> On 14 Jun 2017, at 8:19 am, Devin Asay via use-livecode 
>  wrote:
> 
> Yes, in essence. If you have a group and set the clipsToRect property to true 
> (there’s no way to set it in the PI yet—that’s what I’m going to add), you 
> can then change the rect of the group, and the group will *not* automatically 
> reset its rect to the size of the child controls + margin. It is persistent, 
> even if you leave the card or close the stack. Yet the group’s position and 
> size remains unlocked so you can quickly select and change the group’s rect 
> if you want. A nice feature when you need it.
> 
> ClipsToRect is the property name. So what “plain language” label do you think 
> would be best for the PI?

I think this is one of those cases where the default behaviour was a bad idea. 
Or perhaps was implemented before groups were used for much other than 
backgrounds. Other objects we need to set to the formatted width/height so why 
are groups special cased. Anyway, I would keep it simple and use `Clips to 
rect` so at least it’s easy to relate to the dictionary entry/property name.

What would really be good and resolve this to a significant extent is if the 
tooltip were multi-line with the property summary included.

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


Cheers

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[james--- via use-livecode]

 
> Brahmanathaswami. wrote:
> I am pretty sure that
> 
> Crops to rect  
> 
> would suffice.

+1
Even I could follow that argument without reading it twice. ;-)

James






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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Mark Wieder via use-livecode]

On 06/13/2017 03:19 PM, Devin Asay via use-livecode wrote:


ClipsToRect is the property name. So what “plain language” label do you think 
would be best for the PI?


I always have my preference set to display the LC property rather than 
the 'description', so I don't really care, but...


how about 'resize in place'

--
 Mark Wieder
 ahsoftw...@gmail.com


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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Bob Sneidar via use-livecode]

AnchorRect?

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: Instantiaing Grouped Controls - Templates - Responsive

[Bob Sneidar via use-livecode]

+1 but too late. 

Bob S


> On Jun 13, 2017, at 10:15 , Scott Rossi via use-livecode 
>  wrote:
> 
> 
> 
> The most important rule to follow when establishing any new property should 
> be: Don't use "dont".
> 
> The application of a "negative property" should never have been established 
> (dontWrap, I'm talking to you).  Properties should always be non-negative and 
> simply enabled or disabled depending on the default behavior.
> 
> 


___
use-livecode mailing list
use-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: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Devin Asay via use-livecode]

> On Jun 13, 2017, at 4:19 PM, Devin Asay via use-livecode 
>  wrote:
> 
> Yes, in essence. If you have a group and set the clipsToRect property to true 
> (there’s no way to set it in the PI yet—that’s what I’m going to add), you 
> can then change the rect of the group, and the group will *not* automatically 
> reset its rect to the size of the child controls + margin. It is persistent, 
> even if you leave the card or close the stack. Yet the group’s position and 
> size remains unlocked so you can quickly select and change the group’s rect 
> if you want. A nice feature when you need it.
> 
> ClipsToRect is the property name. So what “plain language” label do you think 
> would be best for the PI?

How about “Prevent auto-resize of rect”?

> 
> Devin
> 
> 
> 
> On Jun 13, 2017, at 4:11 PM, Phil Davis via use-livecode 
> > wrote:
> 
> So it's about manually updating the rect vs. having it in an auto-update mode?
> 
> Phil Davis
> 
> 
> On 6/13/17 3:01 PM, Devin Asay via use-livecode wrote:
> So far I’m kind of partial to Scott R’s “Persistent rect”. Conversely, it 
> could be something like “Auto-update rect”, but then the checkbox would be 
> opposite the property setting. That’s almost as bad as something like 
> dontUpdateRect. (Sorry, Scott, plug your ears.)
> 
> Devin
> 
> 
> On Jun 13, 2017, at 3:34 PM, J. Landman Gay via use-livecode 
> >
>  wrote:
> 
> On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:
> or
> ‘Clip Group to rect’
> 
> There are a few others like that, where the explanation is just the original 
> term (or close) with spaces added. I always felt that didn't explain much. 
> But the suggestion does have company in the PI.

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Devin Asay via use-livecode]

Yes, in essence. If you have a group and set the clipsToRect property to true 
(there’s no way to set it in the PI yet—that’s what I’m going to add), you can 
then change the rect of the group, and the group will *not* automatically reset 
its rect to the size of the child controls + margin. It is persistent, even if 
you leave the card or close the stack. Yet the group’s position and size 
remains unlocked so you can quickly select and change the group’s rect if you 
want. A nice feature when you need it.

ClipsToRect is the property name. So what “plain language” label do you think 
would be best for the PI?

Devin



On Jun 13, 2017, at 4:11 PM, Phil Davis via use-livecode 
> wrote:

So it's about manually updating the rect vs. having it in an auto-update mode?

Phil Davis


On 6/13/17 3:01 PM, Devin Asay via use-livecode wrote:
So far I’m kind of partial to Scott R’s “Persistent rect”. Conversely, it could 
be something like “Auto-update rect”, but then the checkbox would be opposite 
the property setting. That’s almost as bad as something like dontUpdateRect. 
(Sorry, Scott, plug your ears.)

Devin


On Jun 13, 2017, at 3:34 PM, J. Landman Gay via use-livecode 
>
 wrote:

On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:
or
‘Clip Group to rect’

There are a few others like that, where the explanation is just the original 
term (or close) with spaces added. I always felt that didn't explain much. But 
the suggestion does have company in the PI.

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

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

--
Phil Davis


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

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Phil Davis via use-livecode]

(The ? was meant to soften my suggestion, not to indicate that I'm not 
following - that's that's always a possibility)


Phil


On 6/13/17 3:11 PM, Phil Davis wrote:
So it's about manually updating the rect vs. having it in an 
auto-update mode?


Phil Davis


On 6/13/17 3:01 PM, Devin Asay via use-livecode wrote:
So far I’m kind of partial to Scott R’s “Persistent rect”. 
Conversely, it could be something like “Auto-update rect”, but then 
the checkbox would be opposite the property setting. That’s almost as 
bad as something like dontUpdateRect. (Sorry, Scott, plug your ears.)


Devin


On Jun 13, 2017, at 3:34 PM, J. Landman Gay via use-livecode 
> 
wrote:


On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:
or
‘Clip Group to rect’

There are a few others like that, where the explanation is just the 
original term (or close) with spaces added. I always felt that didn't 
explain much. But the suggestion does have company in the PI.


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

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

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




--
Phil Davis


___
use-livecode mailing list
use-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: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Phil Davis via use-livecode]

So it's about manually updating the rect vs. having it in an auto-update 
mode?


Phil Davis


On 6/13/17 3:01 PM, Devin Asay via use-livecode wrote:

So far I’m kind of partial to Scott R’s “Persistent rect”. Conversely, it could 
be something like “Auto-update rect”, but then the checkbox would be opposite 
the property setting. That’s almost as bad as something like dontUpdateRect. 
(Sorry, Scott, plug your ears.)

Devin


On Jun 13, 2017, at 3:34 PM, J. Landman Gay via use-livecode 
> wrote:

On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:
or
‘Clip Group to rect’

There are a few others like that, where the explanation is just the original 
term (or close) with spaces added. I always felt that didn't explain much. But 
the suggestion does have company in the PI.

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

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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


--
Phil Davis


___
use-livecode mailing list
use-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: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Devin Asay via use-livecode]

So far I’m kind of partial to Scott R’s “Persistent rect”. Conversely, it could 
be something like “Auto-update rect”, but then the checkbox would be opposite 
the property setting. That’s almost as bad as something like dontUpdateRect. 
(Sorry, Scott, plug your ears.)

Devin


On Jun 13, 2017, at 3:34 PM, J. Landman Gay via use-livecode 
> wrote:

On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:
or
‘Clip Group to rect’

There are a few others like that, where the explanation is just the original 
term (or close) with spaces added. I always felt that didn't explain much. But 
the suggestion does have company in the PI.

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

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

Re: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[J. Landman Gay via use-livecode]

On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:

or

‘Clip Group to rect’


There are a few others like that, where the explanation is just the 
original term (or close) with spaces added. I always felt that didn't 
explain much. But the suggestion does have company in the PI.


--
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: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Jim Lambert via use-livecode]

or

‘Clip Group to rect’

Jim Lambert
___
use-livecode mailing list
use-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: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Jim Lambert via use-livecode]

Group crops to rect

> Jacque wrote:
> I agree with the concept in general, but the word "crop" implies permanent 
> removal. When you crop an image, it permanently erases the parts outside the 
> rectangle. Unfortunately I can't think of a better term. Maybe something like 
> "prevent auto-resizing”?

How about ‘Group clips to rect’ ?

Jim Lambert




___
use-livecode mailing list
use-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: clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Sannyasin Brahmanathaswami via use-livecode]

Tks Devin for moving this over here.

@ Jacque: OK rignt-- agreed "crop" is wrong.. because, yes, it implies 
"irrevocably chopping off image data"  

But "lock" also has the problem of assuming the loc is locked, which it is not.

How about a word that really is what it does

Constrain rect

Logic: as Mark said "instead of the union of child objects"

Seems like "an act of constraint" to me

and that word is in fact used in discussion about CSS overflow management, 
which to my mind,  is exactly what is happening here.. effectively setting 
"overflow" to "hidden," leaving the rect alone

BR



 

On 6/13/17, 8:32 AM, "use-livecode on behalf of Devin Asay via use-livecode" 
 wrote:

Good suggestions, Scott and BR. 

My list now:

- Persistent rect
- Crop to rect
- Lock rect  (analogous to lockLoc’s “Lock size and position”)

Anyone else want to chime in?


Yes, I admit I threw up a little bit in my mouth when I typed “Don’t…”, but 
in my defense it was pretty far down the list.


Devin



___
use-livecode mailing list
use-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: Instantiaing Grouped Controls - Templates - Responsive

[Devin Asay via use-livecode]

Jacque,

I moved this tangent to a new thread. See thread "clipsToRect property (was Re: 
Instantiaing Grouped Controls - Templates - Responsive)”.

FWIW I had the same reaction to “crop”.

Devin

On Jun 13, 2017, at 1:31 PM, J. Landman Gay via use-livecode 
<use-livecode@lists.runrev.com<mailto:use-livecode@lists.runrev.com>> wrote:

On 6/13/17 12:36 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
there is also strong logic for
Group crops to rect
This also correlates well with the word "clips" in the property name itself.  
i.e. zero ambiquity

I agree with the concept in general, but the word "crop" implies permanent 
removal. When you crop an image, it permanently erases the parts outside the 
rectangle. Unfortunately I can't think of a better term. Maybe something like 
"prevent auto-resizing"?

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

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

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[J. Landman Gay via use-livecode]

On 6/13/17 12:36 PM, Sannyasin Brahmanathaswami via use-livecode wrote:

there is also strong logic for

Group crops to rect

This also correlates well with the word "clips" in the property name itself.  
i.e. zero ambiquity


I agree with the concept in general, but the word "crop" implies 
permanent removal. When you crop an image, it permanently erases the 
parts outside the rectangle. Unfortunately I can't think of a better 
term. Maybe something like "prevent auto-resizing"?


--
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: Instantiaing Grouped Controls - Templates - Responsive

[Scott Rossi via use-livecode]

My understanding is, “before” and “after” are really only intended to work with 
mouse events.

Regards,

Scott Rossi 
Creative Director 
Tactile Media, UX/UI Design 



> On Jun 13, 2017, at 12:24 PM, Sannyasin Brahmanathaswami via use-livecode 
>  wrote:
> 
> OK so *why* is 
> 
> before mouseup  # valid syntax
> 
> But
> 
> before show # invalid


___
use-livecode mailing list
use-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: Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami via use-livecode]

Oh boy, this custom control thing is awesome + external behaviors as text only 
scripts… What a break through! At 60+ should not get too excited about 
anything, but this has my brain on fire.  I even took all the code out of the 
control, moved it to a behavior… and then, even for buttons the *only* logic 
needed in the control is the name.. remove or pass the mouseup then trap in the 
behavior with "target" and now we have a true "zero code" binary "view" object 

Wow! too much fun.

OK.. I decided for instantiation for now just to adopt Terry's option:

"I usually include it as a shared group and place it on any card that might 
require it and show/hide, populate and layer it dynamically as required."

this saves the dev time needed to do a complete "create from outerspace" script 
for now.  Until a use case for creating on the fly comes up, I'll just copy 
this group "around" as needed.

But there is a caveat here: once the card is open, the preOpenControl and 
openControl no longer fire. Of course, that would be expected behavior.

Given that many of us do GUI on a single card composed of multiple 
objects/groups that are simply hidden or shown on demand.  I thought, why not 
request an enhancement "on preShowControl"  or "on showControl" and "on 
hideControl" could be very useful.

of course you can roll your own, but the you have to things like

dispatch "setMyVisState" to group "info-diplay" with "true"

then your behavior has  to do stuff like:

on setMyVisState pBool
  switch pBool
 case "true"
# set up some controls for internal animation in the group 
control
 show me
 break
end setMyVisState pBool

Sure, OK, no problem that works… 

But thought, hmm maybe the language has something mysteriously hidden like 
clipsToRect.

So I looked up "before" into the dictionary, thought.. Ha! there it is: this is 
a "no brainer"
just make a behavior for the group and add this to the behavior

before show  
 #  Oops fails to compile
 # "button "info-display-behavior": compilation error at line 1 (
 #  Handler: bad handler name (may be reserved word)) near "show", char 1
 
   answer "hello" with "OK"

end show

on mouseUp
   put the short name of the target into tMouseEvent
   switch tMouseEvent
  case "close-info"
 hide me
 break
   end switch
end mouseUp

on resizeControl
   lock screen
   set the clipstoRect of me to true
   set the width of grc "info-field-bkgnd" to the width of me * .95
   set the height of grc "info-field-bkgnd" to the height of me * .95
   set the width of fld "info-text" to the width of me * .85
   set the height of fld "info-text" to the height of me * .85
   set the loc of  img "info-bkgnd-img" to the loc of me
   set the loc of grc "info-field-bkgnd" to the loc of me
   set the loc of  fld "info-text"  to the loc of me
   set the right of widget "close-info" to the right of grc "info-field-bkgnd" 
-8
   set the top  of widget "close-info" to the top of grc "info-field-bkgnd" +10
   set the loc of me to the loc of this card  
   unlock screen  

# but the default state is vis false so:

   show me with visual effect dissolve very fastend resizeControl

OK so *why* is 

before mouseup  # valid syntax

But

before show # invalid

??





   




> Maybe a better message to trap in this case would be preOpenControl or
> openControl, which is sent to a group the first time it is accessed or
> when the card opens, depending on whether it's a background or card
> group.

Yep, those are good triggers too, still allowing the group to manage its 
own contents.

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

clipsToRect property (was Re: Instantiaing Grouped Controls - Templates - Responsive)

[Devin Asay via use-livecode]

Good suggestions, Scott and BR. 

My list now:

 - Persistent rect
 - Crop to rect
 - Lock rect  (analogous to lockLoc’s “Lock size and position”)

Anyone else want to chime in?


Yes, I admit I threw up a little bit in my mouth when I typed “Don’t…”, but in 
my defense it was pretty far down the list.


Devin

> On Jun 13, 2017, at 11:15 AM, Scott Rossi via use-livecode 
>  wrote:
> 
> 
> 
> The most important rule to follow when establishing any new property should 
> be: Don't use "dont".
> 
> The application of a "negative property" should never have been established 
> (dontWrap, I'm talking to you).  Properties should always be non-negative and 
> simply enabled or disabled depending on the default behavior.
> 
> 
> 
> In this case, I get that you're referring to readable label, so there's more 
> flexibility here of course, I just needed to vent :-)
> 
> The above said, you're right, this is a tricky case.  IMO the real 
> differentiation here is that the rect of the *unlocked* group remains 
> unaffected by the locations of its child objects.  Since you know the control 
> is a group, maybe the verbose label is something like "persistent rect" since 
> the rect will, for the most part, remain constant.
> 
> Maybe I'm forgetting something…
> 

> On Jun 13, 2017, at 11:36 AM, Sannyasin Brahmanathaswami  
> wrote:
> 
> re: label for adding clipsToRect to the PI 
> 
> from a graphic design point of view…where people are frequently doing this 
> very same thing inside some frame|window|div  etc.  in fact, may be switching 
> back and forth between their image design environment and Livecode…
> 
> there is also strong logic for
> 
> Group crops to rect
> 
> This also correlates well with the word "clips" in the property name itself.  
> i.e. zero ambiquity
> 
> Where as "fixed" doesn't quite cut it from a linguistic "brain can follow" 
> perspective 
> 
> And..  since we don't iterate the name of the object in other property 
> labels… ie.. there is no label "Don't search group" … just "Don't search"
> 
> I am pretty sure that
> 
> Crops to rect  
> 
> would suffice.
>> On Jun 13, 2017, at 9:27 AM, Devin Asay via use-livecode 
>>  wrote:
>> 
>> 
>> On Jun 12, 2017, at 11:45 PM, Mark Waddingham via use-livecode 
>> > wrote:
>> 
>> On 2017-06-12 22:22, Richard Gaskin via use-livecode wrote:
>> For group controls you will find that it is. Try it.  It's quite handy.
>> 
>> Another useful thing which I'm not sure is particularly visible (but is in 
>> the dictionary!) is the group 'clipsToRect' property.
>> 
>> When 'the clipsToRect' is set to true you get a group which acts like 
>> lockLocation is set, but is resizable. In  this case the group's size is 
>> determined purely by the rect it has set, and not the union of the 
>> rectangles of its children.
>> 
>> This might have been mentioned somewhere else in this thread, but its 
>> probably worth repeating if so as a group with clipsToRect true, and a 
>> resizeControl handler makes a good base for a custom control.
>> 
>> It’s not visible in the PI, but it’s not hard to add. I’d be happy to make a 
>> pull request for it. The main question is what would be the “readable label” 
>> of this property? (My current favorite is the first one.)
>> 
>> - Group rect remains fixed
>> - Fixed group rect
>> - Lock group rect
>> - Group rect is fixed
>> - Don’t change group rect
>> - Group rect is independent of child controls
>> - Prevent group rect size when child objects move or resize
>> 
>> It’s a tricky balance between clear enough and short enough.
>> 
>> Ideas?
>> 
>> Devin
>> 
>> 
>> 
>> Devin Asay
>> Director
>> Office of Digital Humanities
>> Brigham Young University
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami via use-livecode]

re: label for adding clipsToRect to the PI 

from a graphic design point of view…where people are frequently doing this very 
same thing inside some frame|window|div  etc.  in fact, may be switching back 
and forth between their image design environment and Livecode…

there is also strong logic for

Group crops to rect

This also correlates well with the word "clips" in the property name itself.  
i.e. zero ambiquity

Where as "fixed" doesn't quite cut it from a linguistic "brain can follow" 
perspective 

And..  since we don't iterate the name of the object in other property labels… 
ie.. there is no label "Don't search group" … just "Don't search"

 I am pretty sure that

Crops to rect  

would suffice.

Brahmanathaswami



 

On 6/13/17, 6:27 AM, "use-livecode on behalf of Devin Asay via use-livecode" 
 wrote:

It’s not visible in the PI, but it’s not hard to add. I’d be happy to make 
a pull request for it. The main question is what would be the “readable label” 
of this property? (My current favorite is the first one.)

  - Group rect remains fixed
  - Fixed group rect

___
use-livecode mailing list
use-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: Instantiaing Grouped Controls - Templates - Responsive

[Scott Rossi via use-livecode]

The most important rule to follow when establishing any new property should be: 
Don't use "dont".

The application of a "negative property" should never have been established 
(dontWrap, I'm talking to you).  Properties should always be non-negative and 
simply enabled or disabled depending on the default behavior.



In this case, I get that you're referring to readable label, so there's more 
flexibility here of course, I just needed to vent :-)

The above said, you're right, this is a tricky case.  IMO the real 
differentiation here is that the rect of the *unlocked* group remains 
unaffected by the locations of its child objects.  Since you know the control 
is a group, maybe the verbose label is something like "persistent rect" since 
the rect will, for the most part, remain constant.

Maybe I'm forgetting something...

Scott Rossi
Creative Director
Tactile Media UX/UI Design

> On Jun 13, 2017, at 9:27 AM, Devin Asay via use-livecode 
>  wrote:
> 
> 
> On Jun 12, 2017, at 11:45 PM, Mark Waddingham via use-livecode 
> > wrote:
> 
> On 2017-06-12 22:22, Richard Gaskin via use-livecode wrote:
> For group controls you will find that it is. Try it.  It's quite handy.
> 
> Another useful thing which I'm not sure is particularly visible (but is in 
> the dictionary!) is the group 'clipsToRect' property.
> 
> When 'the clipsToRect' is set to true you get a group which acts like 
> lockLocation is set, but is resizable. In  this case the group's size is 
> determined purely by the rect it has set, and not the union of the rectangles 
> of its children.
> 
> This might have been mentioned somewhere else in this thread, but its 
> probably worth repeating if so as a group with clipsToRect true, and a 
> resizeControl handler makes a good base for a custom control.
> 
> It’s not visible in the PI, but it’s not hard to add. I’d be happy to make a 
> pull request for it. The main question is what would be the “readable label” 
> of this property? (My current favorite is the first one.)
> 
>  - Group rect remains fixed
>  - Fixed group rect
>  - Lock group rect
>  - Group rect is fixed
>  - Don’t change group rect
>  - Group rect is independent of child controls
>  - Prevent group rect size when child objects move or resize
> 
> It’s a tricky balance between clear enough and short enough.
> 
> Ideas?
> 
> Devin
> 
> 
> 
> Devin Asay
> Director
> Office of Digital Humanities
> Brigham Young University
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Devin Asay via use-livecode]

On Jun 12, 2017, at 11:45 PM, Mark Waddingham via use-livecode 
> wrote:

On 2017-06-12 22:22, Richard Gaskin via use-livecode wrote:
For group controls you will find that it is. Try it.  It's quite handy.

Another useful thing which I'm not sure is particularly visible (but is in the 
dictionary!) is the group 'clipsToRect' property.

When 'the clipsToRect' is set to true you get a group which acts like 
lockLocation is set, but is resizable. In  this case the group's size is 
determined purely by the rect it has set, and not the union of the rectangles 
of its children.

This might have been mentioned somewhere else in this thread, but its probably 
worth repeating if so as a group with clipsToRect true, and a resizeControl 
handler makes a good base for a custom control.

It’s not visible in the PI, but it’s not hard to add. I’d be happy to make a 
pull request for it. The main question is what would be the “readable label” of 
this property? (My current favorite is the first one.)

  - Group rect remains fixed
  - Fixed group rect
  - Lock group rect
  - Group rect is fixed
  - Don’t change group rect
  - Group rect is independent of child controls
  - Prevent group rect size when child objects move or resize

It’s a tricky balance between clear enough and short enough.

Ideas?

Devin



Devin Asay
Director
Office of Digital Humanities
Brigham Young University

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> On 2017-06-13 17:37, Richard Gaskin via use-livecode wrote:
>> FWIW the clipsToRect property does not appear among the keys of
>> "the properties" of a group either.
>>
>> Should I add a note to that report, or file a separate report for
>> that?
>
> If you could file a separate report - they are logically distinct
> things

Wasn't sure if both might be addressed in a single session, but it makes 
sense to log them separately - done:


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

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Mark Waddingham via use-livecode]

On 2017-06-13 17:37, Richard Gaskin via use-livecode wrote:

Mark Waddingham wrote:


I think this might be missing from the PI control definitions:

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


FWIW this property does not appear among the keys of "the properties"
of a group either.

Should I add a note to that report, or file a separate report for that?


If you could file a separate report - they are logically distinct things 
:)


Thanks!

Mark.

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

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> I think this might be missing from the PI control definitions:
>
> http://quality.livecode.com/show_bug.cgi?id=18945

FWIW this property does not appear among the keys of "the properties" of 
a group either.


Should I add a note to that report, or file a separate report for that?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> On 6/12/17, 7:45 PM, "use-livecode on behalf of Mark Waddingham wrote:
>
> Another useful thing which I'm not sure is particularly visible
> (but is in the dictionary!) is the group 'clipsToRect' property.
...
> Mark …Ha! "OOooh Myy Gawd"
>
> had I known this from the beginning it would all have "worked out of
> the box" because the resetting rects and locs of child objects of the
> group was causing the rect of the group to "jump around" hence there
> no fixed coord system to work from.

The default behavior of groups (automatically resizing to fit their 
interior controls) is not limited to adjusting the rects of those 
controls by script.  If you move them with the pointer tool you'll see 
the same expansion of the group to accommodate them.


Prior to the clipsToRect property you can get the same clipping by 
locking the location of the group.


While clipping is rarely needed, this is a great convenience for those 
times when it is.


Another property worth noting is the boundingRect, which limits the 
scrollable are in a group to a specified rect.  This can be esp. useful 
for apps that include a drawing/layout UI, letting you limit the 
scrolling group to mimic a fixed page size, for example.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> On 2017-06-12 22:22, Richard Gaskin via use-livecode wrote:
>> For group controls you will find that it is. Try it.  It's quite
>> handy.
>
> Another useful thing which I'm not sure is particularly visible (but
> is in the dictionary!) is the group 'clipsToRect' property.
>
> When 'the clipsToRect' is set to true you get a group which acts like
> lockLocation is set, but is resizable. In  this case the group's size
> is determined purely by the rect it has set, and not the union of the
> rectangles of its children.
>
> This might have been mentioned somewhere else in this thread, but its
> probably worth repeating if so as a group with clipsToRect true, and a
> resizeControl handler makes a good base for a custom control.

Super cool.  I missed that in the v6.2 Release Notes when it appeared - 
thanks for pointing it out.


As long as we're exploring methods for encapsulating resizing, what are 
the odds this enhancement you submitted may be implemented in v9?:


ANOMALY: Messages are blocked if a control is disabled
http://quality.livecode.com/show_bug.cgi?id=17123

I very much appreciate your submitting that one.

Without that it can be quite cumbersome to write extra blocks of code to 
explicitly send those messages if a group is disabled.  But once in 
place, so much becomes so clean and simple.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami via use-livecode]

Mark Waddingham wrote:

This might have been mentioned somewhere else in this thread, but its 
probably worth repeating if so as a group with clipsToRect true, and a 
resizeControl handler makes a good base for a custom control.

BR: indeed confirmed

just by setting that one property for the group. the very first script I wrote 
to attempt this "responsive business"

works, because the coord system is now "me" or the rect of the group which is 
really what we want.

on resizeControl
   lock screen
   set the rect of img "info-bkgnd-img" to the rect of me
   set the width of grc "info-field-bkgnd" to the width of me * .95
   set the height of grc "info-field-bkgnd" to the height of me * .95
   set the width of fld "info-text" to the width of me * .85
   set the height of fld "info-text" to the height of me * .85
   set the loc of  img "info-bkgnd-img" to the loc of me
   set the loc of grc "info-field-bkgnd" to the loc of me
   set the loc of  fld "info-text"  to the loc of me
   set the right of widget "close-info" to the right of grc "info-field-bkgnd" 
-8
   set the top  of widget "close-info" to the top of grc "info-field-bkgnd" +10
   set the loc of me to the loc of this card
   unlock screen
end resizeControl

@Richard who wrote:"  Another key change is when "resizeControl" is sent: 
historically
  that was only sent to controls when resized with the pointer tool,
  but in recent versions that message is sent to groups whenever
  anything changes their rect, even other scripts."

OK yes… this does work, I was thinking it was broken because of the wonky 
behavior of the group shifting to the rect of the union of child objects.   I 
probably could have set a break point on the resizeControl handler.. but didn't 
think of that until just now.

on mouseUp
   set the rect of grp "display-info" to 50,50,400,400 
 # this is just to set a base coords = a square  for "me"
 # later set to the card loc
 
   send "resizeControl" to grp "display-info" 

#hacky bit in case clutzy fingers moved the control in dev
# the resizeControl does not fire, but the the control shifts to topleft 
,50,50
# so we force it… 

end mouseUp

OK this is very cool… next trick…I forcing myself to see how far I can separate 
code from the actual binary stack into lib's and behaviors. so that nothing but 
"little triggers" remain in the binary GUI.livecode stack; fascinating.

___
use-livecode mailing list
use-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: Instantiaing Grouped Controls - Templates - Responsive

[Mark Waddingham via use-livecode]

On 2017-06-13 08:53, Sannyasin Brahmanathaswami via use-livecode wrote:

Mark …Ha! "OOooh Myy Gawd"

had I known this from the beginning it would all have "worked out of
the box" because the resetting rects and locs of child objects of the
group was causing the rect of the group to "jump around" hence there
no fixed coord system to work from.

This is great… right we don't see this in the PI for groups… so
definitely hidden!


I think this might be missing from the PI control definitions:

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


Another related mystery:

there is a new check box in the position for groups

[ ] resize when setting rect property

what does this do?


This makes it so that when you set the left/top/right/bottom fields in 
the PI it resizes the control rather than move it (if unchecked, setting 
the left of the control in the PI will move it to that left position; if 
checked, setting the left of the control will set the width 
appropriately so left and right are as specified).


Warmest Regards,

Mark.

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

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami via use-livecode]

Mark …Ha! "OOooh Myy Gawd"

had I known this from the beginning it would all have "worked out of the box" 
because the resetting rects and locs of child objects of the group was causing 
the rect of the group to "jump around" hence there no fixed coord system to 
work from.

This is great… right we don't see this in the PI for groups… so definitely 
hidden! 

Another related mystery:

there is a new check box in the position for groups

[ ] resize when setting rect property

what does this do?

 BR

On 6/12/17, 7:45 PM, "use-livecode on behalf of Mark Waddingham via 
use-livecode"  wrote:

Another useful thing which I'm not sure is particularly visible (but is 
in the dictionary!) is the group 'clipsToRect' property.

When 'the clipsToRect' is set to true you get a group which acts like 
lockLocation is set, but is resizable. In  this case the group's size is 
determined purely by the rect it has set, and not the union of the 
rectangles of its children.

This might have been mentioned somewhere else in this thread, but its 
probably worth repeating if so as a group with clipsToRect true, and a 
resizeControl handler makes a good base for a custom control.

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Mark Waddingham via use-livecode]

On 2017-06-12 22:22, Richard Gaskin via use-livecode wrote:

For group controls you will find that it is. Try it.  It's quite handy.


Another useful thing which I'm not sure is particularly visible (but is 
in the dictionary!) is the group 'clipsToRect' property.


When 'the clipsToRect' is set to true you get a group which acts like 
lockLocation is set, but is resizable. In  this case the group's size is 
determined purely by the rect it has set, and not the union of the 
rectangles of its children.


This might have been mentioned somewhere else in this thread, but its 
probably worth repeating if so as a group with clipsToRect true, and a 
resizeControl handler makes a good base for a custom control.


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

Instantiaing Grouped Controls - Templates - Responsive

[Alejandro Tejada via use-livecode]

Hi,

Check if you could find useful this script that uses a single graphic
to calculate the new size of the rectangles from a group of controls
(in this example, graphics)

I am sure that it's possible to add scripts that constrain the size and
position of some rectangles, before changing size or position
of all controls:

Download from first message of this forum thread:
http://forums.livecode.com/viewtopic.php?f=10=28042

Al
___
use-livecode mailing list
use-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: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> On 6/12/17 1:19 PM, Richard Gaskin via use-livecode wrote:
>>  > a) if a stack is 414 X 736, and opens on a device that is 414 X
>> > 736 with full screen mode set to showAll… is the resizeStack
>> > handler fired?
>>
>> Supporting your interest in avoiding theory, I'm compelled to ask:
>> what happened when you tried it?
>
> If the stack is the same size as the mobile device screen, there will
> be no resizing because the stack already fits.
>
> Maybe a better message to trap in this case would be preOpenControl or
> openControl, which is sent to a group the first time it is accessed or
> when the card opens, depending on whether it's a background or card
> group.

Yep, those are good triggers too, still allowing the group to manage its 
own contents.


Orientation changes would still need resizeStack or orientationChanged 
to be handled, though, which is one convenience with using resizeStack 
for both.


My test devices here each have different screen dimensions, so I rarely 
save my stack in the exact dimensions of the next device I'll run it on.


So I ran a test before I made that last post, in which I set my stack to 
the screen dimensions of the phone nearest me, then ran it on that 
phone:  I got the resizeStack message anyway.


I thought I'd read a post here some time ago about this from one of the 
regulars who's shipped a lot of mobile apps, how on mobile the 
resizeStack message is sent when a stack is first opened in addition to 
when orientation changes.


That's what got me started down this path, and it's been working so 
reliably on Android that I hadn't considered perhaps I'm relying on a bug.


Either way, it would be great if the engine sent the resizeStack message 
under the same circumstances on both iOS and Android.


As it appears on Android right now, even if it's an exception to 
whatever rules are supposed to apply, it's a darn handy one, which was 
what led me to believe it was a design decision.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> Yes, I did try. and certainly any manual resizing fires the resize
> msgs as expect.

Excellent.  You now have one trigger point for the sequence of resizing 
actions when a stack is opened or the orientation is changed.


If you have multiple cards and you need to trigger that on each, you can 
do so from one handler in the stack:


   on preOpenCard
  resizeStack the width of this card, the height of this card
   end preOpenCard

Each card is responsible for the layout of its groups in its resizeStack 
handler, each group is responsible for itself in their respective 
resizeControl handlers.


There are many ways to handle resizing, but for me this works well, 
allowing me to keep the internals of a group handled by that group itself.



> But the interest was, initially, to get the resizeControl to fire from
> script. As resizeable it off of all stacks -- deliberately so team
> does not inadvertently break their rect with the slip of a drag/save.
>
> I was "pedal to the metal" on reading the dictionary.  but later found
>
> --
> The resizeControl message is only sent when the user resizes a
> control by dragging its handles. It is not sent if a handler changes
> the size of a control by changing its properties (width, height, and
> so on).
>
> The resizeControl message is sent after the resizing is finished.
> This means that you cannot prevent a control's size from being changed
> by trapping this message.
> --
>
> Hence the need for  custom handler to do the work as these commands
> appear to be dedicated to an actual "physical" user interaction,

Or so it might seem, had you and I not already spent considerable time 
in private email on this, where a few days ago I wrote:


 The messages added in the v4/5 series are especially useful -
 that's when behaviors started being taken seriously, and there
 was much interest in custom controls. We got things like "before *"
 and "after *" message options for behaviors, and "preOpenControl"
 and the less-commonly-needed "openControl".

 Another key change is when "resizeControl" is sent: historically
 that was only sent to controls when resized with the pointer tool,
 but in recent versions that message is sent to groups whenever
 anything changes their rect, even other scripts.


Those changes occurred before the standard practice the team uses today, 
in which language element changes are now not considered complete until 
the Dictionary has also been updated to reflect them.  Back then they 
were on a separate track, and a few additions fell through the cracks.


I caught this one a couple years ago, and filed a bug report for it:
http://quality.livecode.com/show_bug.cgi?id=17118

See also this request by Mark Waddingham, which will simplify the subset 
of cases involving disabled groups (would love to see this in v9):

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


> OTOH
>
> set the rect of group "responsiveAboutBox"  to 50,50,400,760
>
> also constitutes a "resize" event, so it would be "cool" if the
> resizecontrol msg were also handled.

For group controls you will find that it is. Try it.  It's quite handy.


> But custom responsive handlers also work. The method I worked out:
> using a single object's (member of the group) rect as the base
> coordinate system for all siblings in the group, seems pretty straight
> forward. The idea being not just to have the control change on stack
> orientation shift or different device screen, but to change to a
> custom rect on demand…

Yep, lots of ways to handle dynamic layouts.  Glad you found one that 
works well for you.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[J. Landman Gay via use-livecode]

On 6/12/17 1:19 PM, Richard Gaskin via use-livecode wrote:

 > 2) I like everything you are describing but I don't get this:
 > "resizeControl"  is never triggered if the resizeStack is "dormant"
 > that was my last "problem"  … so, how are we "trigger" the resizeStack
 > to "fire" when any stack is opened… even if the size doesn't change.
 >
 > a) if a stack is 414 X 736, and opens on a device that is 414 X 736
 > with full screen mode set to showAll… is the resizeStack handler
 > fired?

Supporting your interest in avoiding theory, I'm compelled to ask: what 
happened when you tried it?


If the stack is the same size as the mobile device screen, there will be 
no resizing because the stack already fits.


Maybe a better message to trap in this case would be preOpenControl or 
openControl, which is sent to a group the first time it is accessed or 
when the card opens, depending on whether it's a background or card group.


--
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: Instantiaing Grouped Controls - Templates - Responsive

[Alex Tweedly via use-livecode]

On 12/06/2017 18:30, Sannyasin Brahmanathaswami via use-livecode wrote:

2) I like everything you are describing but I don't get this: "resizeControl"  is never triggered if the resizeStack is 
"dormant"  that was my last "problem"  … so, how are we "trigger" the resizeStack to 
"fire" when any stack is opened… even if the size doesn't change.

I don;t know if it should be needed or not, but I often do

on opencard

resizestack

end opencard

This also covers you for desktop when stacks are not resizable.

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami via use-livecode]

Yes, I did try. and certainly any manual resizing fires the resize msgs as 
expect.

But the interest was, initially, to get the resizeControl to fire from script. 
As resizeable it off of all stacks -- deliberately so team does not 
inadvertently break their rect with the slip of a drag/save.

I was "pedal to the metal" on reading the dictionary.  but later found

--
The resizeControl message is only sent when the user resizes a
control by dragging its handles. It is not sent if a
handler changes the size of a control by changing its
properties (width, height, and so on).

The resizeControl message is sent after the resizing is finished.
This means that you cannot prevent a control's size
from being changed by trapping this message.
--

Hence the need for  custom handler to do the work as these commands appear to 
be dedicated to an actual "physical" user interaction,

which makes sense from one point of view; 

OTOH 

set the rect of group "responsiveAboutBox"  to 50,50,400,760

also constitutes a "resize" event, so it would be "cool" if the resizecontrol 
msg were also handled.

But custom responsive handlers also work. The method I worked out: using a 
single object's (member of the group) rect as the base coordinate system for 
all siblings in the group, seems pretty straight forward. The idea being not 
just to have the control change on stack orientation shift or different device 
screen, but to change to a custom rect on demand… 

Anyone else have other methods/examples/sample stacks of responsive GUI?

BR


On 6/12/17, 8:19 AM, "use-livecode on behalf of Richard Gaskin via 
use-livecode"  wrote:

Supporting your interest in avoiding theory, I'm compelled to ask: what 
happened when you tried it?


> b) how can we emulate this on the desktop during development if all
> your stacks are fixed size on the desktop and for deployment to
> mobile?

By default the engine creates a new stack as resizable.

Just leave it that way and you get what every web developer enjoys for 
testing responsive design: resize the stack and see that its contents 
are moving where you want them.



___
use-livecode mailing list
use-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: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> @ Richard
>
> 1) Again, all very nice theory
>
> Viz-a-viz my lament… "where are all the examples, sample code" We all
> don't live it the stratosphere of visionary LiveCode architecture like
> you doi. -☺

I'm relatively late to mobile development, actually.  I have two mobile 
apps in development, while many others here have shipped a great many 
apps for many years.


I just read their notes here, and the docs, and experiment with what I read.


> Can you post sample stacks with your resize handlers?

I don't have sample stacks, only production stacks.

I suppose I could produce some, but with so many people already shipping 
so many mobile apps it hadn't occurred to me they'd be needed.


If there's enough demand I'd be happy to consider a proposal for 
creating and documenting sample tutorial stacks.



> 2) I like everything you are describing but I don't get this:
> "resizeControl"  is never triggered if the resizeStack is "dormant"
> that was my last "problem"  … so, how are we "trigger" the resizeStack
> to "fire" when any stack is opened… even if the size doesn't change.
>
> a) if a stack is 414 X 736, and opens on a device that is 414 X 736
> with full screen mode set to showAll… is the resizeStack handler
> fired?

Supporting your interest in avoiding theory, I'm compelled to ask: what 
happened when you tried it?



> b) how can we emulate this on the desktop during development if all
> your stacks are fixed size on the desktop and for deployment to
> mobile?

By default the engine creates a new stack as resizable.

Just leave it that way and you get what every web developer enjoys for 
testing responsive design: resize the stack and see that its contents 
are moving where you want them.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami via use-livecode]

@ Richard

1) Again, all very nice theory

Viz-a-viz my lament… "where are all the examples, sample code" We all don't 
live it the stratosphere of visionary LiveCode architecture like you doi. -☺

Can you post sample stacks with your resize handlers?

2) I like everything you are describing but I don't get this: "resizeControl"  
is never triggered if the resizeStack is "dormant"  that was my last "problem"  
… so, how are we "trigger" the resizeStack to "fire" when any stack is opened… 
even if the size doesn't change. 

a) if a stack is 414 X 736, and opens on a device that is 414 X 736  with full 
screen mode set to showAll… is the resizeStack handler fired?

b) how can we emulate this on the desktop during development if all your stacks 
are fixed size on the desktop and for deployment to mobile?




On 6/12/17, 5:02 AM, "use-livecode on behalf of Richard Gaskin via 
use-livecode"  wrote:

The resizeStack message should be sent in response to anything that 
causes the stack to resize.

This should not be limited to the user action of resizing a stack as we 
often handle in desktop apps, but also whenever any script or the engine 
causes the stack to resize.

On mobile OSes, a stack can only fill the device screen size, so a 
resizeStack handler should be sent when a stack is first opened, and 
when orientation changes, two events that cause the stack to be resized.

If the resizeStack message is used to adjust the rects of component 
sections of the layout (groups), those groups should then be able to 
adjust their interior contents in a resizeControl handler.

With such a setup the layout-specific code only adjusts the rects of a 
relatively few groups, and from there the groups take care of 
themselves.  When any reusable groups are driven by behavior scripts, 
code in one place allows reuse across nearly any UI.

FWIW I just added an answer dialog in my test stack's resizeStack 
handler and indeed it triggers on both app open and device rotate as 
described above.  I'm using an engine for that testing built on v9.0dp4. 
Since I'm testing on Android right now, if you're not seeing resizeStack 
sent at app open and device rotate you may have found a bug specific to iOS.


It seems you've found a satisfying alternative here, so if it does what 
you need use it:

___
use-livecode mailing list
use-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: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> first: the resizeControl thing did not work out at all because it
> depends on the user resizing the stack.

The resizeStack message should be sent in response to anything that 
causes the stack to resize.


This should not be limited to the user action of resizing a stack as we 
often handle in desktop apps, but also whenever any script or the engine 
causes the stack to resize.


On mobile OSes, a stack can only fill the device screen size, so a 
resizeStack handler should be sent when a stack is first opened, and 
when orientation changes, two events that cause the stack to be resized.


If the resizeStack message is used to adjust the rects of component 
sections of the layout (groups), those groups should then be able to 
adjust their interior contents in a resizeControl handler.


With such a setup the layout-specific code only adjusts the rects of a 
relatively few groups, and from there the groups take care of 
themselves.  When any reusable groups are driven by behavior scripts, 
code in one place allows reuse across nearly any UI.


FWIW I just added an answer dialog in my test stack's resizeStack 
handler and indeed it triggers on both app open and device rotate as 
described above.  I'm using an engine for that testing built on v9.0dp4. 
Since I'm testing on Android right now, if you're not seeing resizeStack 
sent at app open and device rotate you may have found a bug specific to iOS.



It seems you've found a satisfying alternative here, so if it does what 
you need use it:


> So it seems more "rock solid" and less "snakey" just to use the
> largest enclosing object at the bottom of the group as the reference
> coords. After that it's simple math and no caveats because you are
> establishing a "coordinate system" from the group with one object and
> reference everything from there, Suddenly it became very easy:
>
> on updateMyRect pRect
>lock screen
>put the long ID of img "info-bkgnd-img" into tFrame
>set the rect of img "info-bkgnd-img" to pRect
>set the width of grc "info-field-bkgnd" to (the width of tFrame) * .87
>set the height of grc "info-field-bkgnd" to (the height of tFrame) 
* .87

>set the width of fld "info-text" to (the width of tFrame) * .80
>set the height of fld "info-text" to (the height of tFrame)  * .80
>set the loc of grc "info-field-bkgnd" to the loc of tFrame
>set the loc of  fld "info-text"  to the loc of tFrame
>set the right of widget "close-info" to (the right of grc 
"info-field-bkgnd" - 4)
>set the top   of widget "close-info" to the top of grc 
"info-field-bkgnd" + 10

>unlock screen
> end updateMyRect
>
>
> As for instantiation. We *do* use binary stacks as "views" so… just as
> we use a card to hold icons for buttons, that the user never sees.. so
> why not keep group controls in a stack and copy them… reserve the
> "dynamic creation from script" for a use case where this is your only
> option. or you *really* need to collaborate and want that all as text
> for GIT.
>
> so, then the last question is… where do you store the grouped
> controls… I guess you need a lib_template.livecode or something like
> that…. as long as it is in the stack files you will end up opening it
> as soon as you all it, the copy your assets out as needed ot the
> "current" GUI that needs them.

When I need one thing, I tend to store it where I use it.  If it exists 
once in a UI, I'll probably just build it there.


If I need multiple copies of things, scripts can copy faster than I can, 
so I tend to put those (and behaviors, icon images, and other such 
resources) in a substack or separate stack file named something like 
"AppNameRSRC". The benefit of appending "RSRC" isn't just for ResEdit 
nostalgia, but because the string both readily identifies the stack's 
role as a resource container, and the all-caps abbreviation serves as a 
clear reminder that it's not something we display to the user.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami via use-livecode]

OK well, continued working on this

first: the resizeControl thing did not work out at all because it depends on 
the user resizing the stack.

using that same handler but with "send" breaks everything because if you set 
the rect of the main enclosing object then the rect of the group "me" start to 
change because the child objects are our side, so sending a 4 values as a rect 
to the group with the "resizeControl" with reference to "me" starte production 
very odd results.

So it seems more "rock solid" and less "snakey" just to use the largest 
enclosing object at the bottom of the group as the reference coords. After that 
it's simple math and no caveats because you are establishing a "coordinate 
system" from the group with one object and reference everything from there, 
Suddenly it became very easy:

on updateMyRect pRect
   lock screen
   put the long ID of img "info-bkgnd-img" into tFrame
   set the rect of img "info-bkgnd-img" to pRect
   set the width of grc "info-field-bkgnd" to (the width of tFrame) * .87
   set the height of grc "info-field-bkgnd" to (the height of tFrame) * .87
   set the width of fld "info-text" to (the width of tFrame) * .80
   set the height of fld "info-text" to (the height of tFrame)  * .80
   set the loc of grc "info-field-bkgnd" to the loc of tFrame
   set the loc of  fld "info-text"  to the loc of tFrame
   set the right of widget "close-info" to (the right of grc "info-field-bkgnd" 
- 4)
   set the top   of widget "close-info" to the top of grc "info-field-bkgnd" + 
10
   unlock screen
end updateMyRect


As for instantiation. We *do* use binary stacks as "views" so… just as we use a 
card to hold icons for buttons, that the user never sees.. so why not keep 
group controls in a stack and copy them… reserve the "dynamic creation from 
script" for a use case where this is your only option. or you *really* need to 
collaborate and want that all as text for GIT.

so, then the last question is… where do you store the grouped controls… I guess 
you need a lib_template.livecode or something like that…. as long as it is in 
the stack files you will end up opening it as soon as you all it, the copy your 
assets out as needed ot the "current" GUI that needs them.  


still fishing… but getting there…

 

On 6/8/17, 9:20 AM, "use-livecode on behalf of Richard Gaskin via use-livecode" 
 wrote:

If I don't need to create an object I probably won't, adjusting an 
existing object instead.  It only saves one step, but its a savings just 
the same.

___
use-livecode mailing list
use-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: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 09/06/2017 00:40, Richard Gaskin via use-livecode wrote:
>> I don't understand.  A script-only stack contain no objects, so
>> even if you later copy them, they still need to be dynamically
>> instantiated at some point, no?
>>
>> Like a Zen koan: how can there be a binary object where there is no
>> binary object?
>>
> Hmmm - we're probably heading off into the weeds here 
>
> The script-only stack is used as a behaviour for controls within
> another stack - so it can copt hose controls without them bieng binary
> objects within the scrip-only stack.
>
> OR
>
> The script-only stack creates a set of objects the first time it is
> used (creating the template group).
> Subsequent uses of the script (in the same context) will (at most)
> copy that template group - so yes they are being created - but with
> minimal work because it's doing a copy rather than  "create and then
> set lots of properties".
>
> So not quite as much saving in the second case - but still less work
> than creating and setting lots of properties for the controls.

Thanks.  Glad to find there isn't some mysterious wormhole I'd never 
conceived of in which a script-only stack can contain things beyond a 
script.


But also disappointed. There are a few cases where such a thing may be 
useful.


I'll leave wormholes to theoretical physics, and just stick to my 
script-only stacks and NIB-like UI stacks for now.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Alex Tweedly via use-livecode]

On 09/06/2017 00:40, Richard Gaskin via use-livecode wrote:


I don't understand.  A script-only stack contain no objects, so even 
if you later copy them, they still need to be dynamically instantiated 
at some point, no?


Like a Zen koan: how can there be a binary object where there is no 
binary object?



Hmmm - we're probably heading off into the weeds here 

The script-only stack is used as a behaviour for controls within another 
stack - so it can copt hose controls without them bieng binary objects 
within the scrip-only stack.


OR

The script-only stack creates a set of objects the first time it is used 
(creating the template group).
Subsequent uses of the script (in the same context) will (at most) copy 
that template group - so yes they are being created - but with minimal 
work because it's doing a copy rather than  "create and then set lots of 
properties".


So not quite as much saving in the second case - but still less work 
than creating and setting lots of properties for the controls.


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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 08/06/2017 22:37, Richard Gaskin via use-livecode wrote:
>> Alex Tweedly wrote:
>>
>> > On 08/06/2017 20:20, Richard Gaskin wrote:
>> >> If you're committed to a script-only stack there's no decision to
>> >> make: every control must be instantiated dynamically, because a
>> >> script-only stack contains the stack script only, no objects.
>> >>
>> > Well, not quite "every control".
>> >
>> > You could :
>> >   - if the relevant template control/group exists - copy it
>> >   - if not, create it dynamically, and then copy it
>> >
>> > This way
>> >   - the stack can be script-only
>> >   - most instantiations take minimal time
>>
>> True, to the degree that your app uses non-script-only stacks, you
>> won't need to do everything in script only. :)
>>
>>
> No, I'm actually doing this all within a script-only stack.
> It's a behaviour stack, which is used as a behaviour attached to
> groups in the main app stack (which could be binary or script-only).
> The behaviour is defined to create controls (actually, groups) as
> requested by the main stack - which basically sets up a list of needed
> controls, and then calls a handler in the behaviour.
>
> So something vaguely like 
>
> on preOpenCard
>
>settheEditingMode ofgrp"grp1"ofmetoFALSE
>
> settheSpec ofgrp"grp1"ofmetogSpec
>
> dispatch"buildGroup"togrp"grp1"
>
> ...
>
> and within 'buildgroup' it does the
>   check for the template group existing, create it (from an internal
> default set of properties) if needed
>
> This also (I think) allows for the app stack to pre-define the
> template groups ahead of time, thereby pre-empting the creation of the
> groups within the behaviour stack. Haven't actually done that yet, or
> fully considered the problems doing so will create - but it's a
> loophole I'm leaving myself in case I need it :-)


I don't understand.  A script-only stack contain no objects, so even if 
you later copy them, they still need to be dynamically instantiated at 
some point, no?


Like a Zen koan: how can there be a binary object where there is no 
binary object?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Alex Tweedly via use-livecode]

On 08/06/2017 22:37, Richard Gaskin via use-livecode wrote:

Alex Tweedly wrote:

> On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
>> If you're committed to a script-only stack there's no decision to
>> make: every control must be instantiated dynamically, because a
>> script-only stack contains the stack script only, no objects.
>>
> Well, not quite "every control".
>
> You could :
>   - if the relevant template control/group exists - copy it
>   - if not, create it dynamically, and then copy it
>
> This way
>   - the stack can be script-only
>   - most instantiations take minimal time

True, to the degree that your app uses non-script-only stacks, you 
won't need to do everything in script only. :)



No, I'm actually doing this all within a script-only stack.
It's a behaviour stack, which is used as a behaviour attached to groups 
in the main app stack (which could be binary or script-only). The 
behaviour is defined to create controls (actually, groups) as requested 
by the main stack - which basically sets up a list of needed controls, 
and then calls a handler in the behaviour.


So something vaguely like 

on preOpenCard

  settheEditingMode ofgrp"grp1"ofmetoFALSE

settheSpec ofgrp"grp1"ofmetogSpec

dispatch"buildGroup"togrp"grp1"

...


and within 'buildgroup' it does the
 check for the template group existing, create it (from an internal 
default set of properties) if needed


This also (I think) allows for the app stack to pre-define the template 
groups ahead of time, thereby pre-empting the creation of the groups 
within the behaviour stack. Haven't actually done that yet, or fully 
considered the problems doing so will create - but it's a loophole I'm 
leaving myself in case I need it :-)


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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
>> If you're committed to a script-only stack there's no decision to
>> make: every control must be instantiated dynamically, because a
>> script-only stack contains the stack script only, no objects.
>>
> Well, not quite "every control".
>
> You could :
>   - if the relevant template control/group exists - copy it
>   - if not, create it dynamically, and then copy it
>
> This way
>   - the stack can be script-only
>   - most instantiations take minimal time

True, to the degree that your app uses non-script-only stacks, you won't 
need to do everything in script only. :)


Even simpler, as long as you're mixing binary and script-only stacks, 
just use binary stacks for the UI driven by behaviors defined in 
script-only stacks.


That's how I do most of my stuff these days.  I think of the UI stacks 
as somewhat akin to NeXT/Apple NIB files, with most of the code separate 
from them.


This lets me keep code where code is most productive (plain text), and 
lets me keep UI where UI is most productive (building the visual 
elements visually in the IDE).


I don't work in production teams large enough to require multiple 
developers crafting UIs in the same window at the same time, so keeping 
UI in binary stacks has worked well for me.  YMMV.



>> Which reminds me: before I run off an spend an afternoon writing one,
>> has anyone here written a tool that reads a stack laid out with
>> objects and produces the script needed to recreate it from a
>> script-only stack?
>
> Haven't done it - but I really should have done by now :-)

Please consider it. I could get it done, but it would be a long script. 
If you write it it'll be a three-liner done with some clever use of 
arrays. :)


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Alex Tweedly via use-livecode]

On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:

In general I try to "go to TOWN": Touch Only What's Needed.

If I don't need to create an object I probably won't, adjusting an 
existing object instead.  It only saves one step, but its a savings 
just the same.


If you're committed to a script-only stack there's no decision to 
make: every control must be instantiated dynamically, because a 
script-only stack contains the stack script only, no objects.



Well, not quite "every control".

You could :
 - if the relevant template control/group exists - copy it
 - if not, create it dynamically, and then copy it

This way
 - the stack can be script-only
 - most instantiations take minimal time



Which reminds me: before I run off an spend an afternoon writing one, 
has anyone here written a tool that reads a stack laid out with 
objects and produces the script needed to recreate it from a 
script-only stack?


Seems tedious to write, but less tedious than writing instantiation 
code for every property of every object of every card of every stack I 
might make script-only.



Haven't done it - but I really should have done by now :-)

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[Richard Gaskin via use-livecode]

Sannyasin Brahmanathaswami wrote:

> 1) does it make sense to build this dynamically as needed from script
> using "create" and then you put this "create control" script into a
> library? It has the advantage of no binary object, so you can keep it
> in your text only "stacks" .livecodescript, but could be slow?
>
> OR
>
> 2) is it faster (on Android or iOS especially)  to create it as a
> template group  then use
>
> copy grp "info-display"  of card 1 of stack "dialog-templates" to this
> card
>
> ??
>
> What has your experience led you to choose as your best practice and
> why and how do you do it?

In general I try to "go to TOWN": Touch Only What's Needed.

If I don't need to create an object I probably won't, adjusting an 
existing object instead.  It only saves one step, but its a savings just 
the same.


If you're committed to a script-only stack there's no decision to make: 
every control must be instantiated dynamically, because a script-only 
stack contains the stack script only, no objects.



Which reminds me: before I run off an spend an afternoon writing one, 
has anyone here written a tool that reads a stack laid out with objects 
and produces the script needed to recreate it from a script-only stack?


Seems tedious to write, but less tedious than writing instantiation code 
for every property of every object of every card of every stack I might 
make script-only.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Instantiaing Grouped Controls - Templates - Responsive

[J. Landman Gay via use-livecode]

I've done it both ways but usually only create controls on the fly when 
there are only a few objects (two or three usually.) Anything more complex, 
I use a template group and copy that instead. It's nearly instantaneous. I 
did a mobile app that copied a group dozens of times in a preOpenCard 
handler and there was no discernable delay.


I'd like to hear from the team about what's involved, but my theory is that 
it takes more time to create, place, and setup multiple controls than to 
just duplicate an existing group. The scripts are easier to read and much 
shorter too.


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



On June 7, 2017 11:44:55 PM Sannyasin Brahmanathaswami via use-livecode 
 wrote:


We are in need of an "info-text" control which we can use "everywhere" 
instead of reinventing this in each stack/ module in our app.  for Help | 
About |Instructions |Privacy Policy etc…  all to be dynamically loaded and 
shown on demand.


Different contexts require a different size.

Thanks to Richard's gentle prodding and logic I dove enthusiastically into 
the learning curve on responsive UI code for LC.. using the Sheep Herder lesson


Our use case is also very simple.  A control for displaying info/text

4 objects:

1) background image (wont' suffer visually from distortion)
2) bkgnd "mask" graphic (goes underneath a field)
3) info-text field
4) widget with SVG close "X out"path, top right..

I put this script in the group "info-display"… it works just fine. Yay! 
mission accomplished for a) responsive control


on resizeControl
lock screen
set the rect of img "info-bkgnd-img" to the rect of me
set the width of grc "info-field-bkgnd" to the width of me * .87
set the height of grc "info-field-bkgnd" to the height of me * .87
set the width of fld "info-text" to the width of me * .80
set the height of fld "info-text" to the height of me * .80
set the loc of img "info-bkgnd-img" to the loc of me
set the loc of grc "info-field-bkgnd" to the loc of me
set the loc of fld "info-text" to the loc of me
set the right of widget "close-info" to the right of fld "info-text"
set the bottom of widget "close-info" to the top of grc "info-field-bkgnd" - 5
set the loc of me to the loc of this card
unlock screen
end resizeControl

So far, I'm sure this is baby talk for most of you.

But the next question is

b)  about best strategy for instantiation.

1) does it make sense to build this dynamically as needed from script using 
"create" and then you put this "create control" script into a library? It 
has the advantage of no binary object, so you can keep it in your text only 
"stacks" .livecodescript, but could be slow?


OR

2) is it faster (on Android or iOS especially)  to create it as a template 
group  then use


copy grp "info-display"  of card 1 of stack "dialog-templates" to this card

??

What has your experience led you to choose as your best practice and why 
and how do you do it?


Similarly we have small "lists" Indices… that are typically rows of grouped 
controls. Using data grid would be overkill in most contexts… so the 
default is to create a "row" as a group, duplicate this and then group all 
those rows as a single scrolling group.
so this is a similar pattern: use a template and copy the group? or 
instantiate them dynamically from script? Which is better/faster? IYHO


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: Instantiaing Grouped Controls - Templates - Responsive

[Terry Judd via use-livecode]

Hi BR - for me it depends on how many instances of the control I’m likely to 
need on the screen. If I only ever display one at a time then I usually include 
it as a shared group and place it on any card that might require it and 
show/hide, populate and layer it dynamically as required. If I need multiple 
instances of it then then I do the copy thing and discard and instances when I 
leave the screen. I don’t usually create these sorts of multi-part controls 
from scratch and I haven’t used text only stacks so I don’t really have any 
advice there. I also love the flexibility of datagrids so I tend to use them 
(on both mobile and desktop) wherever I need a list-style control, no matter 
how simple it is.

HTH,

Terry...

On 8/06/2017 2:42 pm, "use-livecode on behalf of Sannyasin Brahmanathaswami via 
use-livecode"  wrote:

We are in need of an "info-text" control which we can use "everywhere" 
instead of reinventing this in each stack/ module in our app.  for Help | About 
|Instructions |Privacy Policy etc…  all to be dynamically loaded and shown on 
demand.

Different contexts require a different size.

Thanks to Richard's gentle prodding and logic I dove enthusiastically into 
the learning curve on responsive UI code for LC.. using the Sheep Herder lesson

Our use case is also very simple.  A control for displaying info/text

4 objects:

1) background image (wont' suffer visually from distortion)
2) bkgnd "mask" graphic (goes underneath a field)
3) info-text field
4) widget with SVG close "X out"path, top right..

I put this script in the group "info-display"… it works just fine. Yay! 
mission accomplished for a) responsive control

on resizeControl
lock screen
set the rect of img "info-bkgnd-img" to the rect of me
set the width of grc "info-field-bkgnd" to the width of me * .87
set the height of grc "info-field-bkgnd" to the height of me * .87
set the width of fld "info-text" to the width of me * .80
set the height of fld "info-text" to the height of me * .80
set the loc of img "info-bkgnd-img" to the loc of me
set the loc of grc "info-field-bkgnd" to the loc of me
set the loc of fld "info-text" to the loc of me
set the right of widget "close-info" to the right of fld "info-text"
set the bottom of widget "close-info" to the top of grc "info-field-bkgnd" 
- 5
set the loc of me to the loc of this card
unlock screen
end resizeControl

So far, I'm sure this is baby talk for most of you.

But the next question is

b)  about best strategy for instantiation.

1) does it make sense to build this dynamically as needed from script using 
"create" and then you put this "create control" script into a library? It has 
the advantage of no binary object, so you can keep it in your text only 
"stacks" .livecodescript, but could be slow?

OR

2) is it faster (on Android or iOS especially)  to create it as a template 
group  then use

copy grp "info-display"  of card 1 of stack "dialog-templates" to this card

??

What has your experience led you to choose as your best practice and why 
and how do you do it?

Similarly we have small "lists" Indices… that are typically rows of grouped 
controls. Using data grid would be overkill in most contexts… so the default is 
to create a "row" as a group, duplicate this and then group all those rows as a 
single scrolling group.
so this is a similar pattern: use a template and copy the group? or 
instantiate them dynamically from script? Which is better/faster? IYHO

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

Instantiaing Grouped Controls - Templates - Responsive

[Sannyasin Brahmanathaswami via use-livecode]

We are in need of an "info-text" control which we can use "everywhere" instead 
of reinventing this in each stack/ module in our app.  for Help | About 
|Instructions |Privacy Policy etc…  all to be dynamically loaded and shown on 
demand.

Different contexts require a different size.

Thanks to Richard's gentle prodding and logic I dove enthusiastically into the 
learning curve on responsive UI code for LC.. using the Sheep Herder lesson

Our use case is also very simple.  A control for displaying info/text

4 objects:

1) background image (wont' suffer visually from distortion)
2) bkgnd "mask" graphic (goes underneath a field)
3) info-text field
4) widget with SVG close "X out"path, top right..

I put this script in the group "info-display"… it works just fine. Yay! mission 
accomplished for a) responsive control

on resizeControl
lock screen
set the rect of img "info-bkgnd-img" to the rect of me
set the width of grc "info-field-bkgnd" to the width of me * .87
set the height of grc "info-field-bkgnd" to the height of me * .87
set the width of fld "info-text" to the width of me * .80
set the height of fld "info-text" to the height of me * .80
set the loc of img "info-bkgnd-img" to the loc of me
set the loc of grc "info-field-bkgnd" to the loc of me
set the loc of fld "info-text" to the loc of me
set the right of widget "close-info" to the right of fld "info-text"
set the bottom of widget "close-info" to the top of grc "info-field-bkgnd" - 5
set the loc of me to the loc of this card
unlock screen
end resizeControl

So far, I'm sure this is baby talk for most of you.

But the next question is

b)  about best strategy for instantiation.

1) does it make sense to build this dynamically as needed from script using 
"create" and then you put this "create control" script into a library? It has 
the advantage of no binary object, so you can keep it in your text only 
"stacks" .livecodescript, but could be slow?

OR

2) is it faster (on Android or iOS especially)  to create it as a template 
group  then use

copy grp "info-display"  of card 1 of stack "dialog-templates" to this card

??

What has your experience led you to choose as your best practice and why and 
how do you do it?

Similarly we have small "lists" Indices… that are typically rows of grouped 
controls. Using data grid would be overkill in most contexts… so the default is 
to create a "row" as a group, duplicate this and then group all those rows as a 
single scrolling group.
so this is a similar pattern: use a template and copy the group? or instantiate 
them dynamically from script? Which is better/faster? IYHO

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