LiveCode Forums.

dunbarx wrote: Sat Jul 11, 2020 9:33 pm First time I heard about this other functionality.

I think that is because he makes them up as he goes along. You all solved the initial query far too quickly and easily. Next time, hem and haw a lot, and make it look like you really can't decide, THEN spring it on him

jacque wrote: Sat Jul 11, 2020 7:28 pm A disabled image will allow the control under it to receive the mouse message.

You're right. I went back to the test I'd done this morning, and it seems the first attempt at running "disable the selobj" from LC's Message Box didn't take (reason #44 why I wrote my own Message Box replacement, and reason #12 why I should remember to always use my replacement). Trying it again yields the result consistent with other objects.

In fact, it's weirder than I expected. I had recalled that there was something else anomalous about images vs other controls beyond the non-graying (which seems sensible enough to me), but I can't recall what it is and so far we can find any so maybe I'm just not recalling that correctly.

But exploring this in action yielded unexpected results, at least for me:

Over the years I've disable many UI elements, but haven't had occasion to disable an image since I don't know when (ever?). So I was surprised to find that when a control is disabled, it's not just the mouse messages that act as though the object isn't there, it's ALL mouse tracking.

For example, on Ubuntu standard style buttons get a slight highlight when mouseover happens - and they happen when a button is covered by a disabled image. MouseEnter and mouseLeave are also triggered.

I suppose that's consistent with the design goal, but it feels weird: whether or not the control covering another disabled, it still exists, and is still visibly covering some or all of what's beneath it. I'm looking at a button "A" covering half of a button "B", and when I mouseover "A" then "B" highlights.

Where in any other software have we seen anything like that?

It's rare enough to have controls obscuring other controls that maybe it doesn't matter. But it seems super-weird to have a control that obscures another visually, but not behaviorially. Here, what you see is not what you get.

Did HyperCard do this? What might prompt such a design descision so different from The xTalk Way in which programming is made simpler through WYSIWYG?

I don't think I ever had to overlap controls in HC so I'm not sure how it behaved. I do know the control itself didn't respond to any messages. Craig might know, he still has a working HC setup.

The anomaly you can't remember about images might be the inability to set various color properties, like bordercolor. This has been the case since MC. I was told back then that you actually could set those colors but only if the colors were in the color palette of the image. I tried that but was never able to get it to work, even back then.

Edit: The issue may be a documentation error. It refers to mouse clicks and keyboard presses but should probably refer to all mouse messages instead.

Disabled buttons are drawn with gray borders and text to indicate that they cannot be clicked. Controls whose disabled property is true do not trigger messages such as mouseUp or mouseEnter, but they can respond to messages sent with the send command. If a disabled control is on top of an enabled control, the disabled control is transparent to clicks, and clicking sends the appropriate messages to the enabled control underneath.

jacque wrote: Sun Jul 12, 2020 6:40 pm Edit: The issue may be a documentation error. It refers to mouse clicks and keyboard presses but should probably refer to all mouse messages instead.

Disabled buttons are drawn with gray borders and text to indicate that they cannot be clicked. Controls whose disabled property is true do not trigger messages such as mouseUp or mouseEnter, but they can respond to messages sent with the send command. If a disabled control is on top of an enabled control, the disabled control is transparent to clicks, and clicking sends the appropriate messages to the enabled control underneath.

Good find. It goes beyond even LC's messaging to include all mouse behaviors. It acts as though the thing you're looking at right in front of you doesn't exist at all.

Probably way too late to change it, but not a design decision I would have made.