Re: Controls in a stack

[Robert Sneidar]

Cheap education. ;-) A lunch is always worth learning something new. 

Bob


On Jan 22, 2013, at 3:17 PM, J. Landman Gay wrote:

> On 1/22/13 3:16 PM, Robert Sneidar wrote:
>> I don't think it will. Behaviors expect a long ID don't they? What
>> would the long ID of a non-placed background look like? I will bet
>> lunch the next time I see you at any LC conference it will not work.
> 
> I just tried it, and it works. You owe me lunch. :)
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: Controls in a stack

[J. Landman Gay]

On 1/22/13 3:16 PM, Robert Sneidar wrote:

I don't think it will. Behaviors expect a long ID don't they? What
would the long ID of a non-placed background look like? I will bet
lunch the next time I see you at any LC conference it will not work.


I just tried it, and it works. You owe me lunch. :)

--
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: Controls in a stack

[J. Landman Gay]

On 1/22/13 3:16 PM, Robert Sneidar wrote:

I don't think it will. Behaviors expect a long ID don't they? What
would the long ID of a non-placed background look like? I will bet
lunch the next time I see you at any LC conference it will not work.


The long ID doesn't change just because the background is not placed. 
Objects in unplaced backgrounds can be referenced normally.




Bob


On Jan 22, 2013, at 12:58 PM, J. Landman Gay wrote:


On 1/22/13 2:36 PM, Phil Davis wrote:

One more thing to note about unplaced BGs - they and their
contents are not in the message path. So any hidden handlers in
there won't respond to normal message-passing. I haven't tried
"dispatch" or "send" to them.


I haven't tried it, but an unplaced background might also be a good
place to store behavior buttons. It seems like it should work, and
we wouldn't need an invisible button on a card.

-- Jacqueline Landman Gay


___ use-livecode mailing
list use-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: Controls in a stack

[Robert Sneidar]

I don't think it will. Behaviors expect a long ID don't they? What would the 
long ID of a non-placed background look like? I will bet lunch the next time I 
see you at any LC conference it will not work. 

Bob


On Jan 22, 2013, at 12:58 PM, J. Landman Gay wrote:

> On 1/22/13 2:36 PM, Phil Davis wrote:
>> One more thing to note about unplaced BGs - they and their contents are
>> not in the message path. So any hidden handlers in there won't respond
>> to normal message-passing. I haven't tried "dispatch" or "send" to them.
> 
> I haven't tried it, but an unplaced background might also be a good place to 
> store behavior buttons. It seems like it should work, and we wouldn't need an 
> invisible button on a card.
> 
> -- 
> Jacqueline Landman Gay 

___
use-livecode mailing list
use-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: Controls in a stack

[Robert Sneidar]

Let's say you deleted the last card a background has been placed on. Would you 
want your background to then also be deleted? Some might, but a great many 
would not. It may be a quite complex group that took you days to get right. To 
have it inadvertently deleted by deleting the last card it was on (and probably 
no undo either) would be heartbreaking. 

Bob


On Jan 22, 2013, at 12:02 PM, Peter Haworth wrote:

> Thanks Phil.
> 
> As mentioned, I haven't really played with backgrounds very much so this
> may be a stupid question but why would you want to have a background that
> doesn't appear on any card?  I can see that might happen inadvertently when
> backgrounds get deleted but is there a practical use for unplaced
> backgrounds?
> 
> Pete
> 
> On Tue, Jan 22, 2013 at 11:02 AM, Phil Davis  wrote:
> 
>> Nope. But you can detect them like so:
>> 
>>repeat with x = 1 to (the number of backgrounds in this stack)
>>if the number of cards in bg x of this stack = 0 then -- it isn't
>> placed
>>place bg x of this stack onto this cd
>>getControlInfoFromHiddenBg x
>>remove bg x of this stack from this cd
>>end if
>>end repeat
>> 
> 
> 
> 
> Pete
> lcSQL Software 
> ___
> use-livecode mailing list
> use-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: Controls in a stack

[J. Landman Gay]

On 1/22/13 2:36 PM, Phil Davis wrote:

One more thing to note about unplaced BGs - they and their contents are
not in the message path. So any hidden handlers in there won't respond
to normal message-passing. I haven't tried "dispatch" or "send" to them.


I haven't tried it, but an unplaced background might also be a good 
place to store behavior buttons. It seems like it should work, and we 
wouldn't need an invisible button on a card.


--
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: Controls in a stack

[Phil Davis]

One more thing to note about unplaced BGs - they and their contents are 
not in the message path. So any hidden handlers in there won't respond 
to normal message-passing. I haven't tried "dispatch" or "send" to them.


Phil


On 1/22/13 12:22 PM, J. Landman Gay wrote:

On 1/22/13 2:02 PM, Peter Haworth wrote:

Thanks Phil.

As mentioned, I haven't really played with backgrounds very much so this
may be a stupid question but why would you want to have a background 
that
doesn't appear on any card?  I can see that might happen 
inadvertently when

backgrounds get deleted but is there a practical use for unplaced
backgrounds?


One excellent use is for storage. All referenced controls can go there 
without taking up room on any card. In fact, when you import a 
HyperCard stack, all the icon images are put into an unplaced 
background automatically as part of the process.




--
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: Controls in a stack

[J. Landman Gay]

On 1/22/13 2:02 PM, Peter Haworth wrote:

Thanks Phil.

As mentioned, I haven't really played with backgrounds very much so this
may be a stupid question but why would you want to have a background that
doesn't appear on any card?  I can see that might happen inadvertently when
backgrounds get deleted but is there a practical use for unplaced
backgrounds?


One excellent use is for storage. All referenced controls can go there 
without taking up room on any card. In fact, when you import a HyperCard 
stack, all the icon images are put into an unplaced background 
automatically as part of the process.


--
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: Controls in a stack

[Peter Haworth]

Thanks Phil.

As mentioned, I haven't really played with backgrounds very much so this
may be a stupid question but why would you want to have a background that
doesn't appear on any card?  I can see that might happen inadvertently when
backgrounds get deleted but is there a practical use for unplaced
backgrounds?

Pete

On Tue, Jan 22, 2013 at 11:02 AM, Phil Davis  wrote:

> Nope. But you can detect them like so:
>
> repeat with x = 1 to (the number of backgrounds in this stack)
> if the number of cards in bg x of this stack = 0 then -- it isn't
> placed
> place bg x of this stack onto this cd
> getControlInfoFromHiddenBg x
> remove bg x of this stack from this cd
> end if
> end repeat
>



Pete
lcSQL Software 
___
use-livecode mailing list
use-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: Controls in a stack

[Robert Sneidar]

I've been thinking about this from the perspective of creating a compact stack 
definition. You obviously must check for duplicate controls if you are going to 
loop through the controls of every card, as a shared background will appear to 
belong to any card you are on that it is placed on. 

So then one final step to getting all the backgrounds of the stack (including 
the ones not placed anywhere) would be to create a new card and loop through 
the number of backgrounds of this stack, placing each one, then recording the 
controls, checking for their existence first before adding them to your array. 
When done delete the card. You can even mark the group as not belonging to any 
card because if you have already gone through all the cards of a stack and a 
group has not been placed, then you encounter one that is not in your array 
yet, this is obviously one that has not been placed on any card. 

I hope that is not too convoluted. It makes sense in my head, but that is no 
guarantee that it doesn't appear to be babbling to others. ;-)

Bob


On Jan 22, 2013, at 10:11 AM, Peter Haworth wrote:

> Thanks Kay and Phil.
> 
> I've gone back to using the original handler since obviously getting the
> controls of a stack isn't reliable.  I feel like missing random controls in
> multi card stacks is a bug, but my opinion on what is a bug and what isn't
> seems to differ from others on this list so what do you think?  I doubt
> there's any chance of it being fixed but I don;t think that's a reason to
> not report it.
> 
> Phil, thanks for the array tip - turns out I am using an array although not
> for the reason you mentioned.  Sometimes you just get lucky I guess!  Not
> sure how to deal with the backgrounds that aren't on any cards.  I have
> rarely used backgrounds but out of interest, does the IDE Application
> Browser show these unplaced backgrounds?
> 
> 
> Pete
> lcSQL Software 
> 
> 
> On Mon, Jan 21, 2013 at 9:48 PM, Phil Davis  wrote:
> 
>> Another twist in the pursuit of truth:
>> Backgrounds not placed on any card are included in "the number of
>> backgrounds in this stack" but nowhere else. (Neither are their controls)
>> You have to place them onto a card to count their controls.
>> 
>> You could cycle through all the cards and do this:
>>put the name of control x of this cd into tControlArray[ the short id
>> of control x of this cd ]
>> 
>> When you're done, the array structure itself will have eliminated
>> duplicate references. tControlArray contains all control names keyed by
>> their unique IDs. Except for those pesky 0 ID controls. And the controls in
>> any unplaced BGs.
>> 
>> Phil Davis
>> 
>> 
>> 
>> On 1/21/13 9:14 PM, Kay C Lan wrote:
>> 
>>> On Tue, Jan 22, 2013 at 3:29 AM, Peter Haworth  wrote:
>>> 
 Looking at the controls that are missed, they are almost all from stacks
 that contain multiple cards, seemingly randomly missing a few from each
 card.  There are also a handful that have an id of zero which I didn't
 think was possible but that's another topic.
 
>>> Quick test:
>>> 
>>> 1) New Main Stack
>>> 2) Add a button,
>>> 3) Add a new card
>>> 4) Add a button
>>> 5) Go back to cd 1 and group the single btn and turn it into a background
>>> 6) Add a Card (this should come with the  bkgnd btn)
>>> 7) Add to this a normal btn.
>>> 
>>> So you should have a 3 card stack with 1 card that has a bkgnd btn on
>>> it, a 2nd card with a bkgnd btn + a normal btn, and a 3rd card with
>>> just a normal btn.
>>> 
>>> Total number of controls for the stack is 4 (a group for the bkgnd, a
>>> btn in the bkgnd group, and two normal btns.
>>> 
>>> In the msg box if I enter:
>>> 
>>> put the number of controls of stack "test"
>>> 
>>> the answer I get back is always the number of controls of the current
>>> front most card of the stack, I can not get 4 as the answer.
>>> 
>>> So if I happen to be on the card with only the normal btn, then the
>>> answer is 1, the answer you want is 4, and if I loop through the cards
>>> the answer I get is 6.
>>> 
>>> As you've already figured, the problem is associated with multi-card
>>> stacks, from what I can tell 'the number of controls of this stack'
>>> will never give the correct answer for a multi-card stack, and if you
>>> loop through all the cards you'll end up duplicating the process for
>>> any background controls.
>>> 
>>> HTH
>>> 
>>> __**_
>>> use-livecode mailing list
>>> use-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:

Re: Controls in a stack

[Phil Davis]

On 1/22/13 10:11 AM, Peter Haworth wrote:

Thanks Kay and Phil.

I've gone back to using the original handler since obviously getting the
controls of a stack isn't reliable.  I feel like missing random controls in
multi card stacks is a bug, but my opinion on what is a bug and what isn't
seems to differ from others on this list so what do you think?  I doubt
there's any chance of it being fixed but I don;t think that's a reason to
not report it.

Phil, thanks for the array tip - turns out I am using an array although not
for the reason you mentioned.  Sometimes you just get lucky I guess!  Not
sure how to deal with the backgrounds that aren't on any cards.  I have
rarely used backgrounds but out of interest, does the IDE Application
Browser show these unplaced backgrounds?


Nope. But you can detect them like so:

repeat with x = 1 to (the number of backgrounds in this stack)
if the number of cards in bg x of this stack = 0 then -- it 
isn't placed

place bg x of this stack onto this cd
getControlInfoFromHiddenBg x
remove bg x of this stack from this cd
end if
end repeat

Phil




Pete
lcSQL Software 


On Mon, Jan 21, 2013 at 9:48 PM, Phil Davis  wrote:


Another twist in the pursuit of truth:
Backgrounds not placed on any card are included in "the number of
backgrounds in this stack" but nowhere else. (Neither are their controls)
You have to place them onto a card to count their controls.

You could cycle through all the cards and do this:
 put the name of control x of this cd into tControlArray[ the short id
of control x of this cd ]

When you're done, the array structure itself will have eliminated
duplicate references. tControlArray contains all control names keyed by
their unique IDs. Except for those pesky 0 ID controls. And the controls in
any unplaced BGs.

Phil Davis



On 1/21/13 9:14 PM, Kay C Lan wrote:


On Tue, Jan 22, 2013 at 3:29 AM, Peter Haworth  wrote:


Looking at the controls that are missed, they are almost all from stacks
that contain multiple cards, seemingly randomly missing a few from each
card.  There are also a handful that have an id of zero which I didn't
think was possible but that's another topic.


Quick test:

1) New Main Stack
2) Add a button,
3) Add a new card
4) Add a button
5) Go back to cd 1 and group the single btn and turn it into a background
6) Add a Card (this should come with the  bkgnd btn)
7) Add to this a normal btn.

So you should have a 3 card stack with 1 card that has a bkgnd btn on
it, a 2nd card with a bkgnd btn + a normal btn, and a 3rd card with
just a normal btn.

Total number of controls for the stack is 4 (a group for the bkgnd, a
btn in the bkgnd group, and two normal btns.

In the msg box if I enter:

put the number of controls of stack "test"

the answer I get back is always the number of controls of the current
front most card of the stack, I can not get 4 as the answer.

So if I happen to be on the card with only the normal btn, then the
answer is 1, the answer you want is 4, and if I loop through the cards
the answer I get is 6.

As you've already figured, the problem is associated with multi-card
stacks, from what I can tell 'the number of controls of this stack'
will never give the correct answer for a multi-card stack, and if you
loop through all the cards you'll end up duplicating the process for
any background controls.

HTH

__**_
use-livecode mailing list
use-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


___
use-livecode mailing list
use-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: Controls in a stack

[Peter Haworth]

Thanks Kay and Phil.

I've gone back to using the original handler since obviously getting the
controls of a stack isn't reliable.  I feel like missing random controls in
multi card stacks is a bug, but my opinion on what is a bug and what isn't
seems to differ from others on this list so what do you think?  I doubt
there's any chance of it being fixed but I don;t think that's a reason to
not report it.

Phil, thanks for the array tip - turns out I am using an array although not
for the reason you mentioned.  Sometimes you just get lucky I guess!  Not
sure how to deal with the backgrounds that aren't on any cards.  I have
rarely used backgrounds but out of interest, does the IDE Application
Browser show these unplaced backgrounds?


Pete
lcSQL Software 


On Mon, Jan 21, 2013 at 9:48 PM, Phil Davis  wrote:

> Another twist in the pursuit of truth:
> Backgrounds not placed on any card are included in "the number of
> backgrounds in this stack" but nowhere else. (Neither are their controls)
> You have to place them onto a card to count their controls.
>
> You could cycle through all the cards and do this:
> put the name of control x of this cd into tControlArray[ the short id
> of control x of this cd ]
>
> When you're done, the array structure itself will have eliminated
> duplicate references. tControlArray contains all control names keyed by
> their unique IDs. Except for those pesky 0 ID controls. And the controls in
> any unplaced BGs.
>
> Phil Davis
>
>
>
> On 1/21/13 9:14 PM, Kay C Lan wrote:
>
>> On Tue, Jan 22, 2013 at 3:29 AM, Peter Haworth  wrote:
>>
>>> Looking at the controls that are missed, they are almost all from stacks
>>> that contain multiple cards, seemingly randomly missing a few from each
>>> card.  There are also a handful that have an id of zero which I didn't
>>> think was possible but that's another topic.
>>>
>> Quick test:
>>
>> 1) New Main Stack
>> 2) Add a button,
>> 3) Add a new card
>> 4) Add a button
>> 5) Go back to cd 1 and group the single btn and turn it into a background
>> 6) Add a Card (this should come with the  bkgnd btn)
>> 7) Add to this a normal btn.
>>
>> So you should have a 3 card stack with 1 card that has a bkgnd btn on
>> it, a 2nd card with a bkgnd btn + a normal btn, and a 3rd card with
>> just a normal btn.
>>
>> Total number of controls for the stack is 4 (a group for the bkgnd, a
>> btn in the bkgnd group, and two normal btns.
>>
>> In the msg box if I enter:
>>
>> put the number of controls of stack "test"
>>
>> the answer I get back is always the number of controls of the current
>> front most card of the stack, I can not get 4 as the answer.
>>
>> So if I happen to be on the card with only the normal btn, then the
>> answer is 1, the answer you want is 4, and if I loop through the cards
>> the answer I get is 6.
>>
>> As you've already figured, the problem is associated with multi-card
>> stacks, from what I can tell 'the number of controls of this stack'
>> will never give the correct answer for a multi-card stack, and if you
>> loop through all the cards you'll end up duplicating the process for
>> any background controls.
>>
>> HTH
>>
>> __**_
>> use-livecode mailing list
>> use-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
>
___
use-livecode mailing list
use-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: Controls in a stack

[Phil Davis]

Another twist in the pursuit of truth:
Backgrounds not placed on any card are included in "the number of 
backgrounds in this stack" but nowhere else. (Neither are their 
controls) You have to place them onto a card to count their controls.


You could cycle through all the cards and do this:
put the name of control x of this cd into tControlArray[ the short 
id of control x of this cd ]


When you're done, the array structure itself will have eliminated 
duplicate references. tControlArray contains all control names keyed by 
their unique IDs. Except for those pesky 0 ID controls. And the controls 
in any unplaced BGs.


Phil Davis


On 1/21/13 9:14 PM, Kay C Lan wrote:

On Tue, Jan 22, 2013 at 3:29 AM, Peter Haworth  wrote:

Looking at the controls that are missed, they are almost all from stacks
that contain multiple cards, seemingly randomly missing a few from each
card.  There are also a handful that have an id of zero which I didn't
think was possible but that's another topic.

Quick test:

1) New Main Stack
2) Add a button,
3) Add a new card
4) Add a button
5) Go back to cd 1 and group the single btn and turn it into a background
6) Add a Card (this should come with the  bkgnd btn)
7) Add to this a normal btn.

So you should have a 3 card stack with 1 card that has a bkgnd btn on
it, a 2nd card with a bkgnd btn + a normal btn, and a 3rd card with
just a normal btn.

Total number of controls for the stack is 4 (a group for the bkgnd, a
btn in the bkgnd group, and two normal btns.

In the msg box if I enter:

put the number of controls of stack "test"

the answer I get back is always the number of controls of the current
front most card of the stack, I can not get 4 as the answer.

So if I happen to be on the card with only the normal btn, then the
answer is 1, the answer you want is 4, and if I loop through the cards
the answer I get is 6.

As you've already figured, the problem is associated with multi-card
stacks, from what I can tell 'the number of controls of this stack'
will never give the correct answer for a multi-card stack, and if you
loop through all the cards you'll end up duplicating the process for
any background controls.

HTH

___
use-livecode mailing list
use-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: Controls in a stack

[Kay C Lan]

On Tue, Jan 22, 2013 at 3:29 AM, Peter Haworth  wrote:
> Looking at the controls that are missed, they are almost all from stacks
> that contain multiple cards, seemingly randomly missing a few from each
> card.  There are also a handful that have an id of zero which I didn't
> think was possible but that's another topic.

Quick test:

1) New Main Stack
2) Add a button,
3) Add a new card
4) Add a button
5) Go back to cd 1 and group the single btn and turn it into a background
6) Add a Card (this should come with the  bkgnd btn)
7) Add to this a normal btn.

So you should have a 3 card stack with 1 card that has a bkgnd btn on
it, a 2nd card with a bkgnd btn + a normal btn, and a 3rd card with
just a normal btn.

Total number of controls for the stack is 4 (a group for the bkgnd, a
btn in the bkgnd group, and two normal btns.

In the msg box if I enter:

put the number of controls of stack "test"

the answer I get back is always the number of controls of the current
front most card of the stack, I can not get 4 as the answer.

So if I happen to be on the card with only the normal btn, then the
answer is 1, the answer you want is 4, and if I loop through the cards
the answer I get is 6.

As you've already figured, the problem is associated with multi-card
stacks, from what I can tell 'the number of controls of this stack'
will never give the correct answer for a multi-card stack, and if you
loop through all the cards you'll end up duplicating the process for
any background controls.

HTH

___
use-livecode mailing list
use-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: Controls in a stack

[Peter Haworth]

Hi Monte,
Certainly in my original handler, there's nothing to prevent controls in
shared groups being counted twice so I should fix that.

But I don't think there are any shared groups in the stack I used to test
this.  I got myself a list of all the controls from the original handler
that weren't discovered by the alternative handler and most of them that
aren't in groups of any sort.

Pete
lcSQL Software <http://www.lcsql.com>


On Mon, Jan 21, 2013 at 11:48 AM, Monte Goulding <
mo...@sweattechnologies.com> wrote:

> Hmm... have you checked to see if your original handler doesn't parse
> controls in shared groups more than once?
>
> I tend to use a recursive function for this kind of thing.
>
> On 22/01/2013, at 6:29 AM, Peter Haworth  wrote:
>
> > I have a handler that I think uses a pretty standard way of getting a
> list
> > of all the controls in a stack with nested repeat loops on the
> > stack/substacks, then the cardIDs in each stack, then the controls in
> each
> > card.
> >
> > It works fine but trying to see if there's a more efficient way to do it
> > and noticed that I can eliminate the loop on the cards within a stack
> with
> > "repeat with x=1 to the number of controls in stack tStack".  However,
> when
> > doing this, I get a count of controls that is around 1000 less than doing
> > it the original way, on a total count of a little over 16,000 controls.
> >
> > Looking at the controls that are missed, they are almost all from stacks
> > that contain multiple cards, seemingly randomly missing a few from each
> > card.  There are also a handful that have an id of zero which I didn't
> > think was possible but that's another topic.
> >
> > It turns out that the time it takes to get the controls this way is no
> > better than repeating through the cards so I won't be changing my
> handler,
> > but I'm wondering if there's a logical reason for controls being missed
> > like this.
> >
> > Pete
> > lcSQL Software <http://www.lcsql.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
>
> --
> Monte Goulding
>
> M E R Goulding - software development services
> mergExt - There's an external for that!
>
>
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Controls in a stack

[Monte Goulding]

Hmm... have you checked to see if your original handler doesn't parse controls 
in shared groups more than once?

I tend to use a recursive function for this kind of thing.

On 22/01/2013, at 6:29 AM, Peter Haworth  wrote:

> I have a handler that I think uses a pretty standard way of getting a list
> of all the controls in a stack with nested repeat loops on the
> stack/substacks, then the cardIDs in each stack, then the controls in each
> card.
> 
> It works fine but trying to see if there's a more efficient way to do it
> and noticed that I can eliminate the loop on the cards within a stack with
> "repeat with x=1 to the number of controls in stack tStack".  However, when
> doing this, I get a count of controls that is around 1000 less than doing
> it the original way, on a total count of a little over 16,000 controls.
> 
> Looking at the controls that are missed, they are almost all from stacks
> that contain multiple cards, seemingly randomly missing a few from each
> card.  There are also a handful that have an id of zero which I didn't
> think was possible but that's another topic.
> 
> It turns out that the time it takes to get the controls this way is no
> better than repeating through the cards so I won't be changing my handler,
> but I'm wondering if there's a logical reason for controls being missed
> like this.
> 
> Pete
> lcSQL Software <http://www.lcsql.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

--
Monte Goulding

M E R Goulding - software development services
mergExt - There's an external for that!





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

Controls in a stack

[Peter Haworth]

I have a handler that I think uses a pretty standard way of getting a list
of all the controls in a stack with nested repeat loops on the
stack/substacks, then the cardIDs in each stack, then the controls in each
card.

It works fine but trying to see if there's a more efficient way to do it
and noticed that I can eliminate the loop on the cards within a stack with
"repeat with x=1 to the number of controls in stack tStack".  However, when
doing this, I get a count of controls that is around 1000 less than doing
it the original way, on a total count of a little over 16,000 controls.

Looking at the controls that are missed, they are almost all from stacks
that contain multiple cards, seemingly randomly missing a few from each
card.  There are also a handful that have an id of zero which I didn't
think was possible but that's another topic.

It turns out that the time it takes to get the controls this way is no
better than repeating through the cards so I won't be changing my handler,
but I'm wondering if there's a logical reason for controls being missed
like this.

Pete
lcSQL Software <http://www.lcsql.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