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

[Zax]

Many thanks richmond and jeff, it's really christmas before christmas

I'll have to look at your respective codes and try to understand this SVG stuff, but I think I will have no more excuses not to finish this project !

[richmond62]

Personally I would favour SVG vector files (but, obviously NOT ones like the ones I found with embedded fonty bits) if I wanted to scale things.

As I generally develop for desktop delivery where scaling is a non-event, I have "had a thing" about PNG images after I got fed up with the GIF format.

[Zax]

richmond, a question about "moving the queen":

Your script uses grab command, which is fine, but I would like a visual effect (maybe with overlay property) when the dragged card intersects a valid rectangle (the green area in your example stack).
So I tried to replace grab command with:

Code: Select all

on mouseStillDown
   --grab me
   set loc of me to the mouseLoc
  focusControl "btn1", intersect(me, btn "btn1", 3)
end mouseStillDown

on mouseUp
   focusControl "btn1", false
end mouseUp

on focusControl controlName, bool
   if (bool) then
      set the colorOverlay["color"] of btn controlName to yellow
      set the colorOverlay["opacity"] of btn controlName to 60
   else
      --set the colorOverlay["color"] of btn controlName to white
      set the colorOverlay["opacity"] of btn controlName to 0
   end if
end focusControl

It works with the mouvement is *very* jerky

[richmond62]

Here's a thought:
-

[Zax]

Great!
I modified your script in order to have what I wanted:

Code: Select all

on mouseDown
   grab me
end mouseDown

on mouseMove
   if intersect(img "QUEEN", grc "cPLACE", 3) then
      set the coloroverlay["color"] of me to white
      set the coloroverlay["opacity"] of me to "100"
   end if
end mouseMove

on mouseUp
   if intersect(img "QUEEN", grc "cPLACE", 3) then
      set the loc of img "QUEEN" to the loc of grc "cPLACE" ----------- FINAL POSITION HERE
   else
      set the coloroverlay["opacity"] of img "QUEEN" to "0"
      move img "QUEEN" to 113, 151
   end if
end mouseUp

[jmk_phd]

stam --

You wrote:

Personally I would favour SVG vector files ... if I wanted to scale things. As I generally develop for desktop delivery where scaling is a non-event, I have "had a thing" about PNG images after I got fed up with the GIF format.

Isn't there an important exception to scaling being a "non-event" for desktop delivery? Namely, accommodating Retina/high-rez screens for desktops/laptops.

About a decade ago I had to convert my vector graphics to 300ppi PNGs because at the time LC didn't do SVG. Not ideal, but "good enough" -- that is, until I ran my app on a Retina Mac. Ugly! So with SVG now available in LC, I redrew all 237 images as SVGs. Tedious and time-consuming, but these look noticeably better on my standard-rez screens and terrific on the Retina screens. (As a bonus, it's reduced the size of my app quite a bit.)

I've seen SVGs characterized as "future-proof," inasmuch as we know that -- sooner or later -- there will be super-high-rez screens. So I look at it as an investment in the future.

jeff k

[richmond62]

Of course, Jeff, you are quite right.

And to that end it would behoove LC to improve SVG
import so 'fonty bits' are imported successfully as well as the pictorial components.

GIMP manages that without a hitch . . .

[stam]

stam --

You wrote:

Personally I would favour SVG vector files ... if I wanted to scale things. As I generally develop for desktop delivery where scaling is a non-event, I have "had a thing" about PNG images after I got fed up with the GIF format.

Isn't there an important exception to scaling being a "non-event" for desktop delivery? Namely, accommodating Retina/high-rez screens for desktops/laptops.

About a decade ago I had to convert my vector graphics to 300ppi PNGs because at the time LC didn't do SVG. Not ideal, but "good enough" -- that is, until I ran my app on a Retina Mac. Ugly! So with SVG now available in LC, I redrew all 237 images as SVGs. Tedious and time-consuming, but these look noticeably better on my standard-rez screens and terrific on the Retina screens. (As a bonus, it's reduced the size of my app quite a bit.)

I've seen SVGs characterized as "future-proof," inasmuch as we know that -- sooner or later -- there will be super-high-rez screens. So I look at it as an investment in the future.

jeff k

Jeff, I’m pretty sure I said nothing of the sort… are you sure you weren’t responding to Richmond?

If quoting people it may be best to include the reference to the post to avoid any confusion….

Best regards
Stam

[richmond62]

Yes, he was replying to me, as it was me he was quoting.

That is why I replied to him.

[stam]

Thanks Richmond.

It struck me as odd as even though I’m writing stuff for desktop, I’m very definitely catering for scaling.

My users are on windows 10 on a variety of machines which not only have vastly different resolutions but also different “magnifications” - yes, very unhelpfully, win10 offers both a resolution and a magnification setting, which even in the same machine may change significantly, as many have work laptops that dock into a 27’ screen and both of these settings change. Some users prefer full-screen while others do not. Some set the resolution extremely low as the like things “big”.

Safe to say this takes a big chunk of time for me and I would definitely not say that scaling on desktop is a non-event!

[jmk_phd]

My deepest apologies to stam for the misattribution.

jeff k

[stam]

no worries, just led to a lot of head scratching, but Richmond cleared that up

[Zax]

I don't think I will be able to complete this project because I have a big problem with the order of the elements: I forgot that the number of a control cann't be set by script

Desired board after the cards have just been dealt (found on the net):

My board after the cards have just been dealt:

I could find a solution for the distribution of the cards during a new game but the order problem will stay each time a card is manually moved: only the cards at the bottom of each column can be moved, they must be in the foreground (above all others). When a card is moved, it will risk "sliding" below another when it should remain in the foreground (until it is possibly covered by a future move).

Anyway, it allowed me to discover SVG images, and I confirm that it is the right choice for this kind of project which requires a change in image dimensions.
Thanks again for your help.

[richmond62]

the order problem will stay each time a card is manually moved: only the cards at the bottom of each column can be moved, they must be in the foreground (above all others). When a card is moved, it will risk "sliding" below another when it should remain in the foreground (until it is possibly covered by a future move).

That all seems very mysterious.
-

-
https://www.dropbox.com/s/fozn5ubfufyn4 ... e.zip?dl=0

[bn]

I don't think I will be able to complete this project because I have a big problem with the order of the elements: I forgot that the number of a control cann't be set by script

Have you looked at the layer of an object? You can relayer the objects. It is a bit more difficult if the objects are within groups.
Changing the layer of an objects will also affect its number.

If you set two objects to the same number the other object with the same number will change its number.

Also look at set the layer of object to top/bottom

Similar what Richmond did in very basic form in his stack.

Kind regards
Bernd