Disabled or Hidden Control still has Focus

[JackKelly]

When a program is started, a disabled or hidden control can still have focus and be activated by the spacebar. Is it possible to fix this on the next release? Thanks. Jack

NoMainWin
StaticText #1.debug "debug line", 0, 0, 200, 25
Button #1.Button1 "Button1", CallSub, UL, 50, 60, 100, 50
open "Disable / Hide Demonstration" for window as #1
#1 "TrapClose [Quit]"
#1 "Font Ariel 12"

#1.Button1 "!Disable"
'#1.Button1 "!Hide"

wait

[Quit]
close #1: end

sub CallSub CallingHandle$
    #1.debug CallingHandle$
    call delay 1
    #1.debug ""
end sub

sub delay seconds
    timer seconds*1000, [delay]
    wait
[delay]
    timer 0
end sub

[guest]

Is it possible to fix this on the next release?

That's determined by Windows, not LBB. I'm not sure how practical, or desirable, it would be for LBB to override Windows' default behavior. What window should have the focus, in your view (there must be one)?

[JackKelly]

Maybe I don't explain things clearly. Run my demo program under LBB. It opens with a window containing only a disabled button. Press the spacebar, and the button behaves completely normally, not as if it were disabled. The same thing happens if you open the program with the button hidden, which is even more bizarre.

I wrote the demo program to be Just BASIC compatible, and it there it behaves as one would expect -- pressing the space bar has no effect on the disabled button. So how is this a "Windows" issue? Or do you just enjoy blowing me off?

Jack

[guest]

So how is this a "Windows" issue? Or do you just enjoy blowing me off?

Despite your wish to abuse me, it is a Windows issue:

https://devblogs.microsoft.com/oldnewth ... 0/?p=38243

One way of working around the problem is to disable the button using STYLEBITS so that it never acquires focus in the first place:

Code: Select all

Stylebits #1.Button1 _WS_DISABLED,0,0,0

For the record, I am not a liar. I do not deliberately set out to mislead. I reply to questions to the best of my ability, notwithstanding the steady deterioration in my cognitive function. When I am dead, you can have as much fun at my expense as you like. You can hold a 'good riddance' party and invite the other LB enthusiasts who look forward to that occasion so eagerly.

[JackKelly]

Relax Richard – nobody is wishing for your death. You have many friends in this forum, and you can count me as one of them. I consider LBB to be a great program, and it logically follows that I consider you to be a great software engineer. I use that term in awe and admiration. I'm sorry if you perceive your mental faculties to be slipping. My guess is that I'm only about five years behind you on the road to dementia – that pleasant place in La-La land, where everyone seems to end up nowadays.

What I hope for when I ask you a question, is that you will take a day or two to carefully consider the answer. and respond with how MUCH you can do to satisfy the user's concern. Rather than a hasty response about what you can't or won't do. I simply thought that if Carl Gundel could get around this small discrepancy, then certainly you could. LBB is much to be proud of. I discovered the issue while writing notes for an introductory course I hope to teach on BASIC programming using LBB.

Regards.
Jack

[guest]

I simply thought that if Carl Gundel could get around this small discrepancy, then certainly you could.

It's not a discrepancy, it's how Windows works. In the specific case of your program, I know of NO WAY to "get around it", because you are disabling every single control in a dialogue box, something which is expressly forbidden by the Windows UI guidelines (as my link to The Old New Thing confirms). If Carl Gundel's BASICs don't work the same way I have not the slightest idea how they achieve that different behavior, and your constant berating of me for failing to do the same isn't going to somehow provide me with a solution.

I asked you before, and I ask again: which window do you expect to have the input focus after you have 'disabled' the button? LBB could, in principle, detect that you are attempting to disable the only remaining enabled control (although that'a a lot of code for such a special case) and forcibly move the focus to that window. But which window? The only remaining window is the dialogue box itself but that should not normally ever have the input focus because it's only a 'container' for the other controls.

My personal opinion is that LBB should not attempt to be 'clever'. At the moment, the !disable command simply calls the EnableWindow() API, and the !hide command simply calls the ShowWindow() API. That's how I think it should be, and it results in those commands working how they do by default in Windows. If it was a good idea to automatically move the focus elesewhere on disabling the control, don't you think that would be the standard behavior of the EnableWindow() API? That it isn't suggests to me that there's a good reason why not, so LBB shouldn't attempt to do so either.

[JackKelly]

Thanks, Richard, for your thorough explanation. I accept your conclusions. It IS abnormal to have a window with only one control. It would only happen in a demo snippet. Please consider my berating as permanently stopped. Jack

[Aurel]

Jack
You made button which is disabled
this is done with SendMessage () win api .
So if you want enable this control you must use again SendMessage ()
with msg - EM_ENABLEBUTTON or something like that ...
also you need handler which work with keyboards vkSPACE to go that work.
I don't know how to to do that in LBB or LB
but is easy if you work directly on API level what i am doing in o2 compiler.

[net2014]

Jack,

Old post, but did you test Richard's suggestion (Stylebits #1.Button1 _WS_DISABLED,0,0,0) ? it works for me and can be followed by !enable when required.

Just asking!

[JackKelly]

Thanks for the follow up, Net2014. I appreciate your interest and support. The stylebits suggestion doesn't change the peculiarity that I observed, but I've put that discussion behind me, and am willing to let it go.

Thanks again, just the same...
Jack