LiveCode Forums.

Hi everyone

What if you come from a tool like Sketch, or Photoshop, and you have, e.g., built a mock up UI with clickeable areas that don't match neat "sqare buttons", which for that reason don't lend themselves to custom skinning? In fact, anything non-square doesn't really.

Maybe I'm missing something, but if you have any non-square clickeable controls in LiveCode, you still, and always, get a rectangular bounding box. This leads to rather awkward hilite and hover behaviour, when you approach, say, a round control and it highlights before you've actually entered its visible border.

SVG support is a feature that users have requested a while ago, and I realize that's somehow part of the upcoming Widget update to LC 8, so that may help, but still:

Just being able to make use of the Alpha Channel of a PNG control seems to my simple not impossibly complex to implement, and it would mean a tremendous liberation for the UI designer.

If there were a control property that lets you deactivate the 100% transparent part of a PNG from being clickable - that would be huge improvement. There needs to be way, IMHO, to use the visible area of a control, rather than its (invisible) bounding box, for interaction design.

Long story short: can anyone tell me if there is a way around this issue? Or will there soon be...? I've know RunRev / LiveCode for years, but only recently started to get serious with it. The straightforwardness, the quick results, the modular approach - it all makes for joyful development. But when it comes to UI design, cookie cutter controls may put many designers off. And it seems so unecessary - all you'd need is full control over the PNG alpha channel. The data is there already - so is there, will there be a way to access this?

Thanks for any help, thoughts, info!
Maurice

Hi.

This has been an ongoing discussion for years. But I want to understand your post. For example, if I make a round graphic, the bounding rect is square. But if I place this in the card script: I only get a "hit" if I touch the actual visible perimeter of the circle, not when I enter its boundary. Similarly, if the control is opaque, I will get feedback in the interior, but not if the control is not opaque. What are you seeking?

Craig Newman

As Craig said, graphics do this automatically. You can control it for images in script. There are two versions of the "within" function. If you use "is within" the whole image is recognized. But if you use the form "within()" you can specify that only non-transparent areas are active. With this form your handler can check whether the mouse is over an opaque area before it takes any action.

See "within" in the dictionary for the parameter options.

What Jacque said.

"Is within" is an operator. "Within" is a function. The two do indeed work differently, and that is a good thing.

Craig

Thanks Jacqueline and Craig! I think that's just what I need.

I'd only approached this from trying to bend the built-in button control and its functionality to my purpose.
But if I want a custom-shaped button (or other control, for that matter) it seems I'll have to - but can - build it myself.

Hi.

But if I want a custom-shaped button (or other control, for that matter) it seems I'll have to - but can - build it myself.

Can you say "widgets"?

Craig

Since all buttons are rectangles you shouldn't have the problem with those. Or maybe you mean transparent buttons with icons? For those, you can use images instead.

Yeah.... wwwwwidgets. But building one is a bit more involved than simple drag and drop, I take it. But it'll be exciting, once we get to LC 8, I'm sure.

Further to Jacque's point: I am indeed talking about transparent buttons with icons. Was hoping I could use all the btn functionality, minus the restrictive, rectangular bounding box of the button. Round buttons, or even just rect buttons with rounded corners... all still get the hilite behavior (mousing over them) of a button with a rect clicking area. That's just not pretty!

Yeah, you're kind of stuck there. That would make a good feature request in the QCC. You can't be the only one who needs that functionality.

There was a thread about 200 years ago where a kluge was suggested. If the mouseColor was not to ones liking, messages were not sent. This could easily determine whether whitespace or anything but whitespace was under the cursor. I suppose the underlying color does not even have to be whitespace.

Craig