Transparency to a button icon background

[richmond62]

As a heart attack survivor whose life was saved by the hard work of some wonderful
surgeons I have only admiration for your work.

[richmond62]

[richmond62]

there is no problem knowing which graphic was clicked on

Well, Yes, BUT, what about penguins?
-

[dunbarx]

Richmond.

I was too hasty, and deleted my post. Oval graphics won't work. I thought it would be simple to manage the rects of a pile of them, but it is not.

Polygon graphics work fine, but are tedious to create with smooth inner and outer curves.

Craig

[stam]

Well after a bit more sleep i've redesigned everything. PNG images are the only way to go.

I used Affinity Designer (vector graphics app) to create each segment accurately (60°arcs, correct ring widths etc) with transparent backgrounds.
i exported these as both SVG and PNG.

The SVGs are a definite problem when importing as image control - the transparent space still acts as clickable area. If instead of importing SVGs as controls i create an SVG widget and copy the path to the widget, the same problem still occurs. Changing the layering does not produce fix the issue completely.

Importing the images as PNG with transparent background respects the transparent bits and no there is no overlapping of clickable areas (and the 'effective' keyword isn't needed).

I also fine-tuned this as a gadget that hold's its scoring internally, triggers popups to allow scoring of each individual segments, provides a useable API so i can reuse and uses 'inner glow' to colour each segment according to score (previously i fudged tis by exporting multiple .png files with various colours and hiding the ones i didn't want... very kludgy). Much smoother now...

[dunbarx]

I said:

Polygon graphics work fine, but are tedious to create with smooth inner and outer curves.

It turns out that making polygon graphic portions of a circle are not so tedious. In the script of a 500 sided regular polygon:

Code: Select all

on mouseUp
   repeat with y = 126 to 250 -- or 1 to 125, 251 to 375, whatever
      put line y of the effective points of  grc "base" into line y of pointList
   end repeat
   put the loc of grc "base"  & return before  line 1 of pointList
   put return & the loc of grc "base" after last line of pointList
   
   create grc
   set the style of last grc to "polygon"
   set the  points of last grc to pointList
   set the left of last grc to the right of me + 10
   set the opaque of last grc to "true"
end mouseUp

These can be tailored with any "radius" and arcAngle, and stacked together to create the OP's cool bullseye, more recent small ones on top of the older and larger. No overlapping rects to interfere with the clickLoc. LC is not a drafting program, and I fool around with this to fool both it and myself.

Stam said:

PNG images are the only way to go.

Whether my little ditties are too old fashioned, with all these new fangled PNG's and SVG's, is another story.

Craig

[richmond62]

How you generate your "wedges of cheese" is entirely up to you.

I would still favour using PNG images over graphic objects unless you are prepared to do all the "monkeying around"
to have them scale properly.

LC is not a drafting program

No, it isn't.

It is an easily accessible GUI + programming language.

But as all drafting programs are 'just' piles of clever code, there is no
earthly reason that one cannot have piles of clever code inwith LiveCode to do
some drafting with.

[FourthWorld]

But as all drafting programs are 'just' piles of clever code, there is no
earthly reason that one cannot have piles of clever code inwith LiveCode to do
some drafting with.

Only one: available time.

[richmond62]

Tangentially messing around:
-

[stam]

Hey Richmond, neat trick - will definitely remember that one.

Don't think i would be able to use something like this though... it would require twice the number of controls (2 ovals per segment) - and lining 32 controls up neatly would be a pain, not to mention the issue with clicking overlapping rects would probably multiply rather than diminish.

Even if there is there a way to just draw arcs/lines directly to make the shape of a segment in my bullseye, it's probably going to be much more time consuming that what i'm doing now. Affinity Designer (and i imagine most/all vector graphics apps) has a 'donut' tool that makes this a synch. I generated the vector graphics for all segments and exported as .png in about 15-20 mins, and i don't have to worry at all about layering overlapping rects
Just a pity there isn't a similar donut tool for LC! (admittedly use cases would really be limited but i would definitely have use for a robust donut )

[bogs]

Just a pity there isn't a similar donut tool for LC! (admittedly use cases would really be limited but i would definitely have use for a robust donut )

You mean like this? (2 minutes)

[FourthWorld]

Just a pity there isn't a similar donut tool for LC! (admittedly use cases would really be limited but i would definitely have use for a robust donut )

Doable, but with so few use cases not yet done.

I had a similar need for a simple isometric polygon extrusion tool this weekend. Can't say when I'll finish it, since I don't even really need it myself.

[FourthWorld]

Just a pity there isn't a similar donut tool for LC! (admittedly use cases would really be limited but i would definitely have use for a robust donut )

You mean like this? (2 minutes)

How does that handle hit testing for each region?

[stam]

it's not just handling clicks for each segment - each segment has to be able to maintain an independent state, in simplest terms a colour indicating a score. So each segment has to be an independent object or group really.

You can see this in my previous post, where the yellow segment is more abnormal that the surrounding green segments. The group has a custom property array to store all scores and colours each segment accordingly.

The only issue i'm having now is speed - simply colouring the segments is very quick, but doing a per-segment database update (or even a data grid update) slows the process quite a bit. I'm sure i can get it faster.......

[bogs]

How does that handle hit testing for each region?

By itself, it doesn't, however, I doubt it would take much to make it do so at least as good as a transparent png, since you could export each quadrant as one then re-import the pieces of it pretty easily. I'm thinking set the png export as the corner (in turn) to the loc of the graphic (4 points), on re-import set the various corners to the loc of the graphic.

If the above isn't clear, or you think there is a hole in my theory somewhere, lemme know and I'll work up a stack.

it's not just handling clicks for each segment - each segment has to be able to maintain an independent state, in simplest terms a colour indicating a score. So each segment has to be an independent object or group really.

That may push back a demo a little hee hee, but again, I'm pretty sure it is doable.