Unexpected issue with disabled graphics style

[richmond62]

ANOTHER way to deal with signalling that a 'button' is disabled is to use a graphic with 2 images that can be used as backGroundPatterns:
-

[FourthWorld]

I sometimes think that those bug reports are mainly sops to keep users happy, rather than anything the developers bother to look at . . .

Ask yourself if your post might have been at least as productive without that paragraph.

This report was read, tested, and confirmed within days of submission. This is consistent with the overwhelming majority of reports I've submitted.

This issue has been around far longer than it was reported, and understandably prioritized accordingly. It's not like the devs are out of things to do, and most of the time when we need a button we use a button control, which doesn't have this issue.

Of course it's ideal to have disabling handled consistently across all object types. But in my own 25 years of using MC/LC the number of times I've needed to disable a graphic object that also had a visible label is exactly one. And as shown in this thread it wasn't hard to find a workaround for that edge case.

I have no doubt the team would like to address this. But the frequent changes from OS vendors consume a tremendous amount of time, requiring prioritization.

[richmond62]

This report was read, tested, and confirmed within days of submission.

Then why is that bug still present?

Ask yourself if your post might have been at least as productive without that paragraph.

Well, it is a sentence, but let's not quibble.

A customer of mine sent me a bug report re my 'Devawriter Pro', and I was at that time working on what I considered a significant upgrade of the thing.

My reaction was to shelve my upgrade work and go back to the source code and winkle around until I had sorted out the problem that the customer had found. When I had found the bug, I worked flat-out to sort it out, something I was lucky enough to do inwith a sennicht, and then released that bug-fix version before I could even consider returning to my "next big thing work" [Implementation of Grantha script].

In the circles I move in this is called "putting the customer first".

I ALWAYS reply to a customer who files a bug report with me, assuring them that I will do my level best to sort things out as quickly as possible.

I often find my rapid response to the customer calms them down far more than the actual bug fix.

[FourthWorld]

This report was read, tested, and confirmed within days of submission.

Then why is that bug still present?

Anticipated and already answered: see the other two-thirds of the comment you're replying to.

Well, it is a sentence, but let's not quibble.

It's a sentence separated by a double line breaks above and below. Quibble as you like.

A customer of mine sent me a bug report re my 'Devawriter Pro', and I was at that time working on what I considered a significant upgrade of the thing.

My reaction was to shelve my upgrade work and go back to the source code and winkle around until I had sorted out the problem that the customer had found. When I had found the bug, I worked flat-out to sort it out, something I was lucky enough to do inwith a sennicht, and then released that bug-fix version before I could even consider returning to my "next big thing work" [Implementation of Grantha script].

How many lines of C++ interfacing with three radically different underlying OS APIs did you write to fix that?

And how many employees did you need to pay to pull that off?

Low-level development is harder than scripting. Running a business doing it is even harder.

In the circles I move in this is called "putting the customer first".

LC's change logs also evidence much work, which in my circles as well is called "putting the customer first".

But presuming the ease of my scripting is anything close to what an engine team must do to make my scripting possible would be called "Dunning-Kruger Syndrome".

[richmond62]

Dunning-Kruger Syndrome

I have a feeling that at least 2 people round these parts have interesting syndromes.

[stam]

What prevented you from using roundRect buttons?

I’m creating a script widget that produces a login form as I pretty use such in all my apps. Because I want to give myself (and whoever else may use this) some flexibility, I have various options for the elements. For the login button, this can be roundRect but if changing it to a rectangle L produces unequal line thicknesses for bottom/right hiders and generally is more painful as you need to set topLeft and bottomRight border settings.

Try it: create a button, make it a bit taller than standard (one of the features of my widget is that elements scale with resizing of the widget). Then make the background white and set it to rectangle or standard. TERRIBLE… because the top/right borders and never exactly the same as the bottom/left borders no matter what settings you choose (and worse still, apparenaces change with changes in borderWidth). Only the roundRect button style behaves and one would expect, the other styles not so much!!

Graphics are better for this although you need to manage the mouse events…

Edit: you also can’t change the roundRadius of a roundRect button in the PI at least.

BUT, the why is less relevant. The Graphic object offers a disabled property but when disabled it makes the text ultra-black and drops a shadow, instead of a greying it out. This is a confirmed bug. And coding for a disabled state is different from other objects.

Understandably this may not be high on the bug-fixing-priority totem pole. But for those of us who do use graphics as more flexible button replacements it means we have to get/set a disabled flag, define the disabled foreground colouring and manage colour switching and correct reactions to mouse events in code, which adds a seemingly unnecessary layer of complexity.

I’m not sure what complexity implementing this in the engine would entail, but since there is already a disabled property implemented I suspect it might not be that big a job… but that’s me just guessing…