Re: Changing array key text

[Mark Wieder via use-livecode]

On 6/25/19 8:46 PM, Brian Milby via use-livecode wrote:

Nothing gets put into limbo.  The pointer is deleted/removed from the array 
thus reducing the reference count held by the object containing the value.  In 
the above example, the only pointer left is the one held by tSubArray until a 
copy of the pointer is placed in the array as the new key which raises the 
reference count back to two.  The reference count never goes to 0 so garbage 
collection would not touch it.

I’m sure I don’t have the terminology 100% in line with the source, but I think 
the idea is close.


Doh! The hash is a collection of pointers.
Took a while to sink in, but it makes sense now.

--
 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: Changing array key text

[Brian Milby via use-livecode]

Nothing gets put into limbo.  The pointer is deleted/removed from the array 
thus reducing the reference count held by the object containing the value.  In 
the above example, the only pointer left is the one held by tSubArray until a 
copy of the pointer is placed in the array as the new key which raises the 
reference count back to two.  The reference count never goes to 0 so garbage 
collection would not touch it.

I’m sure I don’t have the terminology 100% in line with the source, but I think 
the idea is close.

Thanks,
Brian
On Jun 25, 2019, 9:40 PM -0400, Mark Wieder via use-livecode 
, wrote:
> On 6/25/19 4:31 PM, Brian Milby via use-livecode wrote:
> > Value object starts with a ref count of 1 in the array
> > The first put increases the ref count to 2
> > The delete takes it back to 1
> > The second put takes it back to 2
> > At the end of the handler it goes back to 1 since the local var goes away
>
> M... no...
>
> With that logic, in my example the contents of tSubArray and limbo would
> be the same. Zero-based logic instead of one-based doesn't help either.
>
> --
> Mark Wieder
> ahsoftw...@gmail.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Changing array key text

[Mark Wieder via use-livecode]

On 6/25/19 4:31 PM, Brian Milby via use-livecode wrote:

Value object starts with a ref count of 1 in the array
The first put increases the ref count to 2
The delete takes it back to 1
The second put takes it back to 2
At the end of the handler it goes back to 1 since the local var goes away


M... no...

With that logic, in my example the contents of tSubArray and limbo would 
be the same. Zero-based logic instead of one-based doesn't help either.


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

[Dar Scott Consulting via use-livecode]

There are a couple places in System Report (About this Mac --> System Report) 
that will show what apps are 32-bit: Software->Applications and 
Software->Legacy Software. I like the latter because it is more complete and 
covers more. For example all of the LiveCode 9 applications are 64-bit, but the 
autoupdater applications are not. I found an old application that is 64-bit but 
it has built-in versions of wine and wine-server that are not. Legacy Software 
also is shorter, so you are less likely to miss something.

> On Jun 25, 2019, at 2:01 PM, Richmond via use-livecode 
>  wrote:
> 
> I got macOS Catalina (10.15) beta "shoved up my nose" by my
> Mac's Software update thingy this afternoon.
> 
> While I, normally, go for Beta versions of software I am not going
> to touch this one: and may, indeed never upgrade to 10.15.
> 
> One of a whole slew of reasons is that I keep getting warning notices about
> LiveCode 9 + on my Macintosh running macOS 10.14.6 beta about LC not
> being a 64-bit app.
> 
> Now, as far as I understand things (?) LiveCode 9 + is a "fat" thing, having 
> both
> 32-bit and 64-bit code rolled into one package. However, whether that is true 
> or not
> I have a feeling that macOS 10,15 won't accept Fat apps.
> 
> I, also, wonder if LiveCode running on macOS 10.15 will be able to hive off
> 32-bit standalones?
> 
> Richmond.
> 
> ___
> use-livecode mailing list
> use-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: Changing array key text

[Brian Milby via use-livecode]

Value object starts with a ref count of 1 in the array
The first put increases the ref count to 2
The delete takes it back to 1
The second put takes it back to 2
At the end of the handler it goes back to 1 since the local var goes away

Thanks,
Brian
On Jun 25, 2019, 6:35 PM -0400, Mark Wieder via use-livecode 
, wrote:
> On 6/25/19 1:25 AM, Mark Waddingham via use-livecode wrote:
> > On 2019-06-25 04:18, Brian Milby via use-livecode wrote:
> > > My guess is that it has to do with the copy on write property of
> > > arrays.  If you used your method it may force an actual duplication.
> > >  The existing method just passes a pointer effectively.  I could be
> > > totally wrong though.
> > >
> > > On Jun 24, 2019, 10:11 PM -0400, Mark Wieder via use-livecode
> > > , wrote:
> > > > > put xArray[item 1 of pPath] into tSubArray
> > > > > delete variable xArray[item 1 of pPath]
> > > > > put tSubArray into xArray[pKey]
> > > >
> > > > Interesting. Wouldn't it be faster to do
> > > >
> > > > put xArray[item 1 of pPath] into xArray[pKey]
> > > > delete variable xArray[item 1 of pPath]
> > > >
> > > > i.e., why the extra copy?
> >
> > In terms of copies there are none happening in either case - only xArray
> > is being mutated - and referencing counting means that the 'puts' are
> > all free.
> >
> > The first will be 'on average' marginally more efficient but that's
> > because of the number of keys...
> >
> > In method (1) the number of keys goes from N -> N - 1 -> N
> >
> > In method (2) the number of keys goes from N -> N + 1 -> N
> >
> > Its much more likely that adding a key will cause the engine to have to
> > extend the internal vector of key-value pairs it uses to store the array
> > mapping then removing a key will cause it to shrink it - also expansion
> > is 'on average' slower than shrinking.
>
> Thanks. That helps. Mostly.
> If no copies are made then I'm still a bit weirded out by
>
> put xArray[item 1 of pPath] into tSubArray
> delete variable xArray[item 1 of pPath]
> put xArray[item 1 of pPath] into limbo
> put tSubArray into xArray[pKey]
>
> where limbo is empty and tSubArray still retains the contents.
> The quantum effect jokes write themselves.
>
> Is it the case the tSubArray retains a pointer to the contents but the
> entry in the hash is otherwise invalidated but not garbage collected
> until the reference count goes to zero?
>
> --
> Mark Wieder
> ahsoftw...@gmail.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Groups do not receive mouseEnter messages?

[dunbarxx via use-livecode]

i thought we are talking about ignoring the controls owned by the group. They
have real zest appeal.

Craig



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

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

Re: Changing array key text

[Mark Wieder via use-livecode]

On 6/25/19 1:25 AM, Mark Waddingham via use-livecode wrote:

On 2019-06-25 04:18, Brian Milby via use-livecode wrote:

My guess is that it has to do with the copy on write property of
arrays.  If you used your method it may force an actual duplication.
 The existing method just passes a pointer effectively.  I could be
totally wrong though.

On Jun 24, 2019, 10:11 PM -0400, Mark Wieder via use-livecode
, wrote:

> put xArray[item 1 of pPath] into tSubArray
> delete variable xArray[item 1 of pPath]
> put tSubArray into xArray[pKey]

Interesting. Wouldn't it be faster to do

put xArray[item 1 of pPath] into xArray[pKey]
delete variable xArray[item 1 of pPath]

i.e., why the extra copy?


In terms of copies there are none happening in either case - only xArray 
is being mutated - and referencing counting means that the 'puts' are 
all free.


The first will be 'on average' marginally more efficient but that's 
because of the number of keys...


In method (1) the number of keys goes from N -> N - 1 -> N

In method (2) the number of keys goes from N -> N + 1 -> N

Its much more likely that adding a key will cause the engine to have to 
extend the internal vector of key-value pairs it uses to store the array 
mapping then removing a key will cause it to shrink it - also expansion 
is 'on average' slower than shrinking.


Thanks. That helps. Mostly.
If no copies are made then I'm still a bit weirded out by

put xArray[item 1 of pPath] into tSubArray
delete variable xArray[item 1 of pPath]
put xArray[item 1 of pPath] into limbo
put tSubArray into xArray[pKey]

where limbo is empty and tSubArray still retains the contents.
The quantum effect jokes write themselves.

Is it the case the tSubArray retains a pointer to the contents but the 
entry in the hash is otherwise invalidated but not garbage collected 
until the reference count goes to zero?


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

[Tore Nilsen via use-livecode]

This is easily remedied. Just choose LC 9 in the Finder, choose Show Info and 
make sure you run it in 64 bit mode. I don’t have an English OS setup right 
know, but you should opt out of running the application in what in Norwegian is 
called "low resolution mode". Once you do, you will not get these warnings 
anymore.

Best regards 
Tore Nilsen 

> 25. jun. 2019 kl. 22:01 skrev Richmond via use-livecode 
> :
> 
> I got macOS Catalina (10.15) beta "shoved up my nose" by my
> Mac's Software update thingy this afternoon.
> 
> While I, normally, go for Beta versions of software I am not going
> to touch this one: and may, indeed never upgrade to 10.15.
> 
> One of a whole slew of reasons is that I keep getting warning notices about
> LiveCode 9 + on my Macintosh running macOS 10.14.6 beta about LC not
> being a 64-bit app.
> 
> Now, as far as I understand things (?) LiveCode 9 + is a "fat" thing, having 
> both
> 32-bit and 64-bit code rolled into one package. However, whether that is true 
> or not
> I have a feeling that macOS 10,15 won't accept Fat apps.
> 
> I, also, wonder if LiveCode running on macOS 10.15 will be able to hive off
> 32-bit standalones?
> 
> Richmond.
> 
> ___
> use-livecode mailing list
> use-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: Groups do not receive mouseEnter messages?

[Bob Sneidar via use-livecode]

As I understand it, a group will be the FIRST object to get a mouse message, IF 
you click on an actual object in the group. So you can have a mouseUp handler 
in the group script that handles clicks in other objects, simpy by using the 
target to determine what was clicked. 

Bob S


> On Jun 25, 2019, at 10:23 , Ralph DiMola via use-livecode 
>  wrote:
> 
> This bit me a few times. I would have a group with some controls but was not 
> able to get the mouseUp when you clicked in the group but not on any of the 
> child controls. I now know I have to put some transparent object that fills 
> the group and is also behind all the other controls. It never made any sense 
> to me why this is. I thought as others that the group is a control and would 
> get mouse messages. If this was so then the group would only get the message 
> if 1) you clicked in the group but not on a child 2) You clicked in the group 
> and on a child control and the control passed the message.
> 
> Ralph DiMola


___
use-livecode mailing list
use-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: Groups do not receive mouseEnter messages?

[dunbarxx via use-livecode]

Devin.

"That is what the "target" is for."

"Right, but when you click on an empty space in a group, it is the target,
and if you only want to script the child objects you would have to
specifically exclude the parent group."

The target in this case is the card. Assuming, of course, that no "real"
control underlies the group. You can always filter out any targets that have
the word "card" in them.

I can appreciate that we do not want to introduce anything that would break
existing stacks. So it is a point that we not simply change the way a group
works by merely modifying an existing property. A new one would be called
for.

We can agree to disagree on the structure of the use-list. 

Craig



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

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

Catalina

[Richmond via use-livecode]

I got macOS Catalina (10.15) beta "shoved up my nose" by my
Mac's Software update thingy this afternoon.

While I, normally, go for Beta versions of software I am not going
to touch this one: and may, indeed never upgrade to 10.15.

One of a whole slew of reasons is that I keep getting warning notices about
LiveCode 9 + on my Macintosh running macOS 10.14.6 beta about LC not
being a 64-bit app.

Now, as far as I understand things (?) LiveCode 9 + is a "fat" thing, 
having both
32-bit and 64-bit code rolled into one package. However, whether that is 
true or not

I have a feeling that macOS 10,15 won't accept Fat apps.

I, also, wonder if LiveCode running on macOS 10.15 will be able to hive off
32-bit standalones?

Richmond.

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

Question about 64 bit builds

[Tom Glod via use-livecode]

Hey folks,

On a 64 bit build, can groups be bigger than  -32768 to 32767? pixels?

Don't ask why one would want it bigger.  :D

Thanks,

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

Re: Groups do not receive mouseEnter messages?

[Devin Asay via use-livecode]

> On Jun 25, 2019, at 11:53 AM, dunbarxx via use-livecode 
>  wrote:
> 
> "I would suggest an enhancement to LiveCode to add a property to Groups 
> that toggle between: "
> 
> Setting the "opaque" of the group ought to be the property that permits
> mouse messages.

*** End of quote. Here is my comment.***

But changing that would break many existing stacks.

*** End of my comment. Resuming quote.***

> 
> "If the group did get mouse click messages, it would complicate things in
> situations where you want to know which child object was clicked on."
> 
> That is what the "target" is for.

*** End of quote. Here is my comment.***

Right, but when you click on an empty space in a group, it is the target, and 
if you only want to script the child objects you would have to specifically 
exclude the parent group. 

*** End of my comment. Resuming quote.***

> 
> This all may be an edge case. After all, it only recently came up. It just
> seems to me an anomaly.

*** End of quote. Here is my comment.***

I think folks have always just coded around it. I am so accustomed to it that I 
don’t even think about it. My preference is the current behavior, but I 
wouldn’t be opposed to a property that toggled it on and off, as long as the 
current behavior was the default.

*** End of my comment. Resuming quote.***

> 
> --
> On another note, I find it difficult to use the use-list. One cannot tell
> who is writing, there is no easy way to isolate handlers, there is no easy
> way to isolate quotes. All this just happened.  The forum is SO much more
> accessible and useful.

*** End of quote. Here is my comment.***

Right!? What gives? Quoted text used to come through without any problem.


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: Groups do not receive mouseEnter messages?

[dunbarxx via use-livecode]

"I would suggest an enhancement to LiveCode to add a property to Groups 
that toggle between: "

Setting the "opaque" of the group ought to be the property that permits
mouse messages.

"If the group did get mouse click messages, it would complicate things in
situations where you want to know which child object was clicked on."

That is what the "target" is for.

This all may be an edge case. After all, it only recently came up. It just
seems to me an anomaly.

--
On another note, I find it difficult to use the use-list. One cannot tell
who is writing, there is no easy way to isolate handlers, there is no easy
way to isolate quotes. All this just happened.  The forum is SO much more
accessible and useful.

Craig



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

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

Re: Groups do not receive mouseEnter messages?

[Devin Asay via use-livecode]

This is  a great idea, Paul. I was just thinking that might be a good solution, 
especially with the addition of the (relatively) new clipsToRect property of 
fields. When that property is true, a group’s boundaries do not automatically 
snap to the area defined by its child objects. Instead the group’s boundaries 
remain where the developer set them. Given that groups can now have an 
arbitrarily larger area than their child objects, it makes sense that we might 
want the option of treating them more like full-fledged objects than simply a 
container for other objects.

Devin


On Jun 25, 2019, at 11:30 AM, Paul Dupuis via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

There are clearly use cases where it makes sense for a group (such as it it 
just being used to contain or enclose a set of other controls) NOT to received 
mouse event messages.

There are also use cases where it DOES make sense of a group to received mouse 
event messages, such as if you are using a group as a drawing canvas.

Yes, wonderfully in Livecode, most things that can't be done one way, can be 
coded around to work another way.

I would suggest an enhancement to LiveCode to add a property to Groups that 
toggle between:

behave as a container: current group behavior regarding mouse event messages 
[default]
OR
behave as an object: cause the group to received mouse event message (and other 
routine object messages) following the usual rules (i.e. if there is a button 
in the group that has a mouseEnter handler it gets the message when the button 
is entered, but the group gets a message when it is entered, just as if you 
have a small button on top of a large button)

I don't know what to call the proposed property, and I certainly would not, at 
this time, prioritize it. I've submitted nearly 20 bugs in the last 60 days and 
I'd much rather see more of those fixed that a new feature added. That said, a 
property like this could be s solution for both use cases of groups.


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

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: Groups do not receive mouseEnter messages?

[J. Landman Gay via use-livecode]

Another easy workaround if you want a group with a transparent background 
is to put a group-sized graphic behind other objects as mentioned, but set 
the blendlevel of the graphic to 99. Visually it won't be seen but it will 
still trap messages.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 25, 2019 12:31:55 PM Paul Dupuis via use-livecode 
 wrote:



There are clearly use cases where it makes sense for a group (such as it
it just being used to contain or enclose a set of other controls) NOT to
received mouse event messages.

There are also use cases where it DOES make sense of a group to received
mouse event messages, such as if you are using a group as a drawing canvas.

Yes, wonderfully in Livecode, most things that can't be done one way,
can be coded around to work another way.

I would suggest an enhancement to LiveCode to add a property to Groups
that toggle between:

behave as a container: current group behavior regarding mouse event
messages [default]
OR
behave as an object: cause the group to received mouse event message
(and other routine object messages) following the usual rules (i.e. if
there is a button in the group that has a mouseEnter handler it gets the
message when the button is entered, but the group gets a message when it
is entered, just as if you have a small button on top of a large button)

I don't know what to call the proposed property, and I certainly would
not, at this time, prioritize it. I've submitted nearly 20 bugs in the
last 60 days and I'd much rather see more of those fixed that a new
feature added. That said, a property like this could be s solution for
both use cases of groups.


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

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





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

Re: Groups do not receive mouseEnter messages?

[Paul Dupuis via use-livecode]

There are clearly use cases where it makes sense for a group (such as it 
it just being used to contain or enclose a set of other controls) NOT to 
received mouse event messages.


There are also use cases where it DOES make sense of a group to received 
mouse event messages, such as if you are using a group as a drawing canvas.


Yes, wonderfully in Livecode, most things that can't be done one way, 
can be coded around to work another way.


I would suggest an enhancement to LiveCode to add a property to Groups 
that toggle between:


behave as a container: current group behavior regarding mouse event 
messages [default]

OR
behave as an object: cause the group to received mouse event message 
(and other routine object messages) following the usual rules (i.e. if 
there is a button in the group that has a mouseEnter handler it gets the 
message when the button is entered, but the group gets a message when it 
is entered, just as if you have a small button on top of a large button)


I don't know what to call the proposed property, and I certainly would 
not, at this time, prioritize it. I've submitted nearly 20 bugs in the 
last 60 days and I'd much rather see more of those fixed that a new 
feature added. That said, a property like this could be s solution for 
both use cases of groups.



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

RE: Groups do not receive mouseEnter messages?

[Ralph DiMola via use-livecode]

This bit me a few times. I would have a group with some controls but was not 
able to get the mouseUp when you clicked in the group but not on any of the 
child controls. I now know I have to put some transparent object that fills the 
group and is also behind all the other controls. It never made any sense to me 
why this is. I thought as others that the group is a control and would get 
mouse messages. If this was so then the group would only get the message if 1) 
you clicked in the group but not on a child 2) You clicked in the group and on 
a child control and the control passed the message.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net

-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of 
Devin Asay via use-livecode
Sent: Tuesday, June 25, 2019 12:48 PM
To: How to use LiveCode
Cc: Devin Asay
Subject: Re: Groups do not receive mouseEnter messages?

I have always thought of a group as a container object, like a card, but 
without a “canvas” that constitutes a part of the object. It’s always made 
sense to me that a group doesn’t get mouse messages, except as they are passed 
from child objects. If the group did get mouse click messages, it would 
complicate things in situations where you want to know which child object was 
clicked on.

A group of audio playback buttons, as it stands now:

on mouseUp
   play audioClip (the short name of the target) end mouseUp

A group of audio playback buttons, as it would be if the group received mouse 
click messages:

on mouseUp
   if the owner of me is not me then
  play audioClip (the short name of the target)
   end if
end mouseUp

So at least for most of my use cases, the current situation makes the most 
sense to me.

My $.02.

Devin

On Jun 25, 2019, at 9:24 AM, dunbarxx via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

I suppose as long as one knows how it works, it can be dealt with.

But there is an issue here, in that a group is not really a control, despite 
what the dictionary says. A group has a rect, and one can tell if the mouseLoc, 
say, is within that rect (and not necessarily within the rect of a child 
control), but one cannot rely on any "ordinary" LC thinking to hold at all.

I understand that a group is merely a group of controls. If it was a ghostLike 
object that only did that, then well and good.

But since it interacts with those controls intrinsically (as, for example, the 
way radio buttons behave "natively") and owns most "ordinary" control 
properties, well then, dammit, if one makes it opaque and green, it ought to 
respond to mouse events.

Craig



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

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

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: Groups do not receive mouseEnter messages?

[Devin Asay via use-livecode]

I have always thought of a group as a container object, like a card, but 
without a “canvas” that constitutes a part of the object. It’s always made 
sense to me that a group doesn’t get mouse messages, except as they are passed 
from child objects. If the group did get mouse click messages, it would 
complicate things in situations where you want to know which child object was 
clicked on.

A group of audio playback buttons, as it stands now:

on mouseUp
   play audioClip (the short name of the target)
end mouseUp

A group of audio playback buttons, as it would be if the group received mouse 
click messages:

on mouseUp
   if the owner of me is not me then
  play audioClip (the short name of the target)
   end if
end mouseUp

So at least for most of my use cases, the current situation makes the most 
sense to me.

My $.02.

Devin

On Jun 25, 2019, at 9:24 AM, dunbarxx via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

I suppose as long as one knows how it works, it can be dealt with.

But there is an issue here, in that a group is not really a control, despite
what the dictionary says. A group has a rect, and one can tell if the
mouseLoc, say, is within that rect (and not necessarily within the rect of a
child control), but one cannot rely on any "ordinary" LC thinking to hold at
all.

I understand that a group is merely a group of controls. If it was a
ghostLike object that only did that, then well and good.

But since it interacts with those controls intrinsically (as, for example,
the way radio buttons behave "natively") and owns most "ordinary" control
properties, well then, dammit, if one makes it opaque and green, it ought to
respond to mouse events.

Craig



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

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

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: Groups do not receive mouseEnter messages?

[doc hawk via use-livecode]

bob belabored,
> 
> You are probably right. But the workaround is so simple, putting an opaque 
> green graphic in the group behind all the other objects, that it would be a 
> lot of work to implement just so we didn't have to put a graphic in a group. 

I actually use that background rectangle to change colo as the mouse enters and 
leaves, to hi light the active row (a group).

However, I *do* have issues with not always catching mouseLeave, especially 
when the cursor is moving quickly.

___
use-livecode mailing list
use-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: Groups do not receive mouseEnter messages?

[Bob Sneidar via use-livecode]

You are probably right. But the workaround is so simple, putting an opaque 
green graphic in the group behind all the other objects, that it would be a lot 
of work to implement just so we didn't have to put a graphic in a group. 

Bob S


> On Jun 25, 2019, at 08:24 , dunbarxx via use-livecode 
>  wrote:
> 
> I suppose as long as one knows how it works, it can be dealt with.
> 
> But there is an issue here, in that a group is not really a control, despite
> what the dictionary says. A group has a rect, and one can tell if the
> mouseLoc, say, is within that rect (and not necessarily within the rect of a
> child control), but one cannot rely on any "ordinary" LC thinking to hold at
> all.
> 
> I understand that a group is merely a group of controls. If it was a
> ghostLike object that only did that, then well and good.
> 
> But since it interacts with those controls intrinsically (as, for example,
> the way radio buttons behave "natively") and owns most "ordinary" control
> properties, well then, dammit, if one makes it opaque and green, it ought to
> respond to mouse events.
> 
> Craig


___
use-livecode mailing list
use-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: Groups do not receive mouseEnter messages?

[dunbarxx via use-livecode]

I suppose as long as one knows how it works, it can be dealt with.

But there is an issue here, in that a group is not really a control, despite
what the dictionary says. A group has a rect, and one can tell if the
mouseLoc, say, is within that rect (and not necessarily within the rect of a
child control), but one cannot rely on any "ordinary" LC thinking to hold at
all.

I understand that a group is merely a group of controls. If it was a
ghostLike object that only did that, then well and good.

But since it interacts with those controls intrinsically (as, for example,
the way radio buttons behave "natively") and owns most "ordinary" control
properties, well then, dammit, if one makes it opaque and green, it ought to
respond to mouse events.

Craig



--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

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

Re: Groups do not receive mouseEnter messages?

[Bob Sneidar via use-livecode]

What would happen if you had a background image set for the group? 

Bob S


> On Jun 24, 2019, at 17:24 , dunbarx--- via use-livecode 
>  wrote:
> 
> Confirmed here.
> I have never really tried any of the things you mentioned, but no messages at 
> all are sent to the group I just made.  Interestingly, and consistent so far, 
> double clicking within the group boundary, but not in any child control, 
> opens the inspector for the card.
> So although the dictionary talks about many properties of groups, and states 
> that it is a control in its own right, it does not seem to have much body 
> outside of its children. This even though one can make the group red as a 
> beet. The "object" certainly exists, and has a multitude of properties. It 
> just doesn't seem to be quite there.
> Craig


___
use-livecode mailing list
use-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: Changing array key text

[Bob Sneidar via use-livecode]

:-)

> On Jun 24, 2019, at 20:55 , J. Landman Gay via use-livecode 
>  wrote:
> 
> I love when you guys talk geek to me.  "Tell me more about my 
> arrays."
> 
> https://youtu.be/dEaFFZpfxLU
> 
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com


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

Re: Groups do not receive mouseEnter messages?

[Paul Dupuis via use-livecode]

On 6/25/2019 4:11 AM, Mark Waddingham via use-livecode wrote:
The behavior of groups re mouse messages (and the lack there of) has 
been the same as long as I can remember (which is back to around 
version 2.0).


Warmest Regards,

Mark. 


As always Mark, thank you.

I have becomes so use to most mouse messages working for every object, I 
guess this was just the first time I have tried them with a group and it 
took me by surprise!



___
use-livecode mailing list
use-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: "Drawing" is a reserved stack name?!?

[Paul Dupuis via use-livecode]

On 6/25/2019 7:03 AM, panagiotis merakos wrote:
There is the drawing library, which is an IDE stack. However its name 
is "com.livecode.library.drawing", not just "drawing". So this sounds 
like a bug in the IDE :)


https://quality.livecode.com/show_bug.cgi?id=22205

___
use-livecode mailing list
use-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: "Drawing" is a reserved stack name?!?

[panagiotis merakos via use-livecode]

Hello Paul,

There is the drawing library, which is an IDE stack. However its name is
"com.livecode.library.drawing", not just "drawing". So this sounds like a
bug in the IDE :)

Kind regards,
Panos
--

On Mon, 24 Jun 2019 at 23:54, Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> So before I report this as a "bug", I would appreciate if someone could
> confirm. Using LC9.0.4 and LC 9.0.5rc under Windows
>
> Open LC
> Make a new stack
> Make the stack name "Drawing"
> Save the stack as "Drawing.livecode"
> Make sure that your have View > Show IDE Stacks in Lists set to Off
> Exit LiveCode
>
> Open Drawing.livecode back up in LiveCode.
> Look in the Project Browser -> no "Drawing" stack
>
> Turn View > Show IDE Stacks in Lists to On
> Observe you can see the "Drawing" stack in the Project Browser
>
> LC thinks "Drawing" is part of the IDE. If you open LiveCode with NO
> stacks and view the IDE stacks in the Project Browser, there is no
> "Drawing" stack, so it is not a conflict.
>
> I though the "reserved" stack names were rev*, Home, Message Box, and
> com.livecode.* (oh and recently tsNetLubURL)
>
> I do not recall seeing the name "Drawing" as a reserved stack name for
> the IDE, so this is either a documentation bug or a IDE bug. Can someone
> confirm?
>
>
>
>
> ___
> use-livecode mailing list
> use-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: Quotient

[Pi Digital via use-livecode]

In short form then:

Put 23 into tX;  Put 8 into tY;

Put tX & “/“ & tY && “=“ && (tX div tY) && (tX mod tY) & “/“ & tY into 
tCalcString

Sean Cole
Pi Digital Prod Ltd

> On 25 Jun 2019, at 09:09, Mark Waddingham via use-livecode 
>  wrote:
> 
> Q := X div Y
>  R := X mod Y
> 
> Then you have that:
> 
>  X/Y = Q + R/Y
___
use-livecode mailing list
use-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: Changing array key text

[Mark Waddingham via use-livecode]

On 2019-06-25 04:18, Brian Milby via use-livecode wrote:

My guess is that it has to do with the copy on write property of
arrays.  If you used your method it may force an actual duplication.
 The existing method just passes a pointer effectively.  I could be
totally wrong though.

On Jun 24, 2019, 10:11 PM -0400, Mark Wieder via use-livecode
, wrote:

> put xArray[item 1 of pPath] into tSubArray
> delete variable xArray[item 1 of pPath]
> put tSubArray into xArray[pKey]

Interesting. Wouldn't it be faster to do

put xArray[item 1 of pPath] into xArray[pKey]
delete variable xArray[item 1 of pPath]

i.e., why the extra copy?


In terms of copies there are none happening in either case - only xArray 
is being mutated - and referencing counting means that the 'puts' are 
all free.


The first will be 'on average' marginally more efficient but that's 
because of the number of keys...


In method (1) the number of keys goes from N -> N - 1 -> N

In method (2) the number of keys goes from N -> N + 1 -> N

Its much more likely that adding a key will cause the engine to have to 
extend the internal vector of key-value pairs it uses to store the array 
mapping then removing a key will cause it to shrink it - also expansion 
is 'on average' slower than shrinking.


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: Groups do not receive mouseEnter messages?

[Mark Waddingham via use-livecode]

On 2019-06-25 03:07, Paul Dupuis via use-livecode wrote:

On 6/24/2019 8:24 PM, dunbarx--- via use-livecode wrote:

Confirmed here.
I have never really tried any of the things you mentioned, but no 
messages at all are sent to the group I just made.  Interestingly, and 
consistent so far, double clicking within the group boundary, but not 
in any child control, opens the inspector for the card.
So although the dictionary talks about many properties of groups, and 
states that it is a control in its own right, it does not seem to have 
much body outside of its children. This even though one can make the 
group red as a beet. The "object" certainly exists, and has a 
multitude of properties. It just doesn't seem to be quite there.

Craig



Thanks for the confirmation.

However, what I'd really like is someone from the mothership to chime 
in?


The behavior of groups re mouse messages (and the lack there of) has 
been the same as long as I can remember (which is back to around version 
2.0).


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

[Mark Waddingham via use-livecode]

On 2019-06-24 21:26, Richmond via use-livecode wrote:

But it is not much cop when it comes to finding
the quotient of some long and complicated bit of Mathematics.


Perhaps not, but it is what you asked for...

  28 div 3 = 9
  28 mod 1 = 1

  28 / 3 = 9 + 1/3

  301 div 10 = 30
  301 mod 10 = 1

  301/10 = 30 + 1/10

  44 div 6 = 7
  44 mod 6 = 2

  44/6 = 7 + 2/6 = 7 + 1/3

More generally given X and Y you can rewrite X/Y as a 'quotient and a 
remainder' by defining:


  Q := X div Y
  R := X mod Y

Then you have that:

  X/Y = Q + R/Y

Just as when a human does such a computation R/Y can be often be reduced 
(if R and Y have any common factors) - i.e. by eliminating their 
greatest common divisor.


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