Create a button's icon with a part of a big image? - Beleaguered Castle

[Zax]

Well, in my specific case, the mouseControl is useless, as it always returns the dragged card.
I used richmond's solution with the mouseLoc and it works.

[richmond62]

I realised that the targets did NOT "unflush" blue if one moused over them with the 'card' and then moused out of them again, so
here is a modified version that sorts that out:
-

-

Code: Select all

on mouseDown
   grab me
   set the coloroverlay["opacity"] of grc "Target 1" to "0"
   set the coloroverlay["opacity"] of grc "Target 2" to "0"
end mouseDown

on mouseMove
   if the mouseLoc is within the rect of grc "Target 1" then
      set the coloroverlay["opacity"] of grc "Target 2" to "0"
      set the coloroverlay["color"] of grc "Target 1" to blue
      set the coloroverlay["opacity"] of grc "Target 1" to "100"
   else
      set the coloroverlay["opacity"] of grc "Target 1" to "0"
   end if
   if the mouseLoc is within the rect of grc "Target 2" then
      set the coloroverlay["opacity"] of grc "Target 1" to "0"
      set the coloroverlay["color"] of grc "Target 2" to blue
      set the coloroverlay["opacity"] of grc "Target 2" to "100"
   else
      set the coloroverlay["opacity"] of grc "Target 2" to "0"
   end if
end mouseMove

on mouseUp
   if the mouseLoc is within the rect of grc "Target 1" then
      set the coloroverlay["color"] of grc "Target 1" to blue
      set the coloroverlay["opacity"] of grc "Target 1" to "100"
      set the loc of me to the loc of grc "Target 1"
   end if
   if the mouseLoc is within the rect of grc "Target 2" then
      set the coloroverlay["color"] of grc "Target 2" to blue
      set the coloroverlay["opacity"] of grc "Target 2" to "100"
      set the loc of me to the loc of grc "Target 2"
   end if
end mouseUp

[bn]

How about:

Code: Select all

on mouseDown
   grab me
   set the coloroverlay["opacity"] of grc "Target 1" to "0"
   set the coloroverlay["opacity"] of grc "Target 2" to "0"
end mouseDown

on mouseMove
   if the loc of grc "Target 1" is within the rect of me then
      set the coloroverlay["opacity"] of grc "Target 2" to "0"
      set the coloroverlay["color"] of grc "Target 1" to blue
      set the coloroverlay["opacity"] of grc "Target 1" to "100"
   else
      set the coloroverlay["opacity"] of grc "Target 1" to "0"
   end if
   if the loc of grc "Target 2" is within the rect of me then
      set the coloroverlay["opacity"] of grc "Target 1" to "0"
      set the coloroverlay["color"] of grc "Target 2" to blue
      set the coloroverlay["opacity"] of grc "Target 2" to "100"
   else
      set the coloroverlay["opacity"] of grc "Target 2" to "0"
   end if
end mouseMove

on mouseUp
   if the loc of grc "Target 1" is within the rect of me then
      set the coloroverlay["color"] of grc "Target 1" to blue
      set the coloroverlay["opacity"] of grc "Target 1" to "100"
      set the loc of me to the loc of grc "Target 1"
   end if
   if the loc of grc "Target 2" is within the rect of me then
      set the coloroverlay["color"] of grc "Target 2" to blue
      set the coloroverlay["opacity"] of grc "Target 2" to "100"
      set the loc of me to the loc of grc "Target 2"
   end if
end mouseUp

Kind regards
Bernd

[richmond62]

As the target's rect is bigger than that of the 'card' I am not sure how that would work.

[bn]

Richmond,

The advantage of taking the loc of the target as reference is that it does not matter where the user "grabs" the card. Imagine the user grabs the card at the bottom of the card. The mouseLoc would have to go a long way to be within the rect of the target. etc.

The proof is in the pudding.

Try it and complain...

Kind regards
Bernd

[richmond62]

Try it and complain...

Why bother when what I have works?

[jacque]

Well, in my specific case, the mouseControl is useless, as it always returns the dragged card.
I used richmond's solution with the mouseLoc and it works.

Right, I was mis-remembering how my card games work. I took a look at my (very old) scripts and I see I was using mouseloc as well. I didn't use the grab command, I tracked the mouseloc with mousemove and compared that to a list of valid drop rectangles in a script local. Because it's all in memory, it's very fast.

[Zax]

I tracked the mouseloc with mousemove and compared that to a list of valid drop rectangles in a script local. Because it's all in memory, it's very fast.

Interesting. At this time, I only have a list of valid drop object's name in memory. It seems fast enough on a 2011 MacBook Pro but the app is far to be finished.

[jacque]

I think looking up the object rects as you go would be fine on today's computers. I wrote my first card game more than 15 years ago.

[richmond62]

Looking up the object rects on a 2006 iMac running 10.7.5
(LC 8.1.10) seems perfectly acceptable speedwise: especially if one runs a loop with sequentially named targets . . .

Chopping up tomatoes for the vegetable drier right now,
but, possibly later, I'll knock up a wee demo.

[Zax]

Chopping up tomatoes for the vegetable drier right now,

Right now, trying to deal with the cards dimensions when the board needs to be resized... I suppose I will have to resize all images one by one and the calculation is not simple

[richmond62]

Totally Relevant Picture

tomatoes.jpg (72.32 KiB) Viewed 13352 times

-

[richmond62]

Right now, trying to deal with the cards dimensions when the board needs to be resized...

1. the SIZE.

2. the POSITION.
-

-
Please note that each of the vector images has 2 custom properties . . .
-

[richmond62]

Of course you could use the Geometry Manager:

https://lessons.livecode.com/m/4071/l/1 ... k%20resize.

https://livecode.fandom.com/wiki/Geometry_manager

Personally I have found it almost impossible to use, that is why I'd far rather "roll my own."

[stam]

i often use both the GM and the resizeStack handler - typically i pick a key control that would dictate the size to the rest of the other controls resize/reposition all other controls relative to that - and because i'm lazy i usually resize the key control with the GM...
just remember to call revUpdateGeometry at the start of the resizeStack handler to ensure the GM updates at the right time...