Disable ALL controls on form (1 Viewer)

pdanes

Registered User.
Local time
Today, 00:46
Joined
Apr 12, 2011
Messages
211
I've run into a weird one. I have a form that had NO controls that could take focus. All was controlled from the ribbon, and the form only displayed things in response to procedures called from the ribbon. Recently, I tried an experiment, and add a few controls to the form. They work, but when I reset the form, I cannot disable the ALL the controls.

I have to shift focus away from a control before disabling it, and since there are NO controls on my form except for these new ones, I cannot shift focus to something else in order to disable ALL the controls. I tried shifting focus to the form as whole, to various sections - no luck.

It is a little strange - in my dev machine, I have a newer version of Access, and there it works. I can disable a control even though it has focus, but the target user still has 2007, and there it does not work. I have to do pre-release tests on a special machine I have squirreled away with 2007 on it for this user.

In the new machine, I test ActiveControl after disabling everything, and it throws error 2474 - ActiveControl does not have focus, which makes sense - all my new controls are disabled and there is nothing else that can take focus. But in 2007, this seems to just not be possible.

I can bypass it by putting a hidden dummy control somewhere on the form and shifting focus to it, but it seems a clunky way of doing it, so I thought I'd see if anyone has a better idea.
 
if you hide it I don't believe it will accept the focus. But you can set the height, width, left, top properties to 0 so it is effectively hidden
 
@pdanes
I have always used either a close button or a hidden control to receive focus when a form loads precisely for the reason you state
I wasn't aware until now that the latest versions of Access behaved differently to e.g. A2007 so thank you for enlightening me.
I tested in both A365 & A2007 and can confirm your findings.
For info, A2010 behaves the same as A365

Also in A365 I've just found you can add code to the On_Click event of a textbox to disable it (though you can't hide it!)
I'm baffled that this works at all . . .
 
if you hide it I don't believe it will accept the focus. But you can set the height, width, left, top properties to 0 so it is effectively hidden
Yeah, sorry - I meant hidden as in behind something else that's already on the form. There is a huge graphic image that is manipulated by the ribbon, so I could just put it under that.
 
@pdanes
I have always used either a close button or a hidden control to receive focus when a form loads precisely for the reason you state
I wasn't aware until now that the latest versions of Access behaved differently to e.g. A2007 so thank you for enlightening me.
I tested in both A365 & A2007 and can confirm your findings.
For info, A2010 behaves the same as A365

Also in A365 I've just found you can add code to the On_Click event of a textbox to disable it (though you can't hide it!)
I'm baffled that this works at all . . .
I do that as well, but this form never closes. There are three in the app, and the ribbon controls select which one is on top, among other tasks, but once opened, they stay that way. The overhead involved in constantly opening and closing would be excessive, and the way the app is designed, there are any number of things that can cause it to switch to one of the other two forms. In fact, there are no close buttons at all in this main set of three. There are small auxiliary forms, servicing auxiliary tables, and they are opened and closed, but the main operation is among these three forms that just take turns being on top. The app opens with one form, and when the others are first called, they are opened, but from there on they stay that way. The only way to close them is to close the entire app, and I didn't even put a close button for that. The user just shuts Access down entirely with the X in the upper right corner. It's a bit non-standard, but this is a rather non-standard app, and the user likes it that way.

I also didn't know until now that Access had this new capability. I've run up on the error in the past, ,when I tried to disable a control while it still had focus, and usually solved it by switching focus to the close button, since it was always available. I never noticed that I stopped encountering that error, and only realized it now, when I delivered the latest version of the app and it bombed on the user, because I hadn't tested that particular combination of circumstances on my 2007 machine.

Well, I think it's an improvement. When I want to disable a control, I don't really care what Access does about its focus, and I was always slightly irked that I had to first intentionally set focus to something specific elsewhere, even though I had no real interest in that control having focus. I guess the boyz in Redmond do listen, at least sometimes.
 
Even more strange: The behaviour was changed for the Enabled and Locked properties but not the Visible property which stlll shows error 2165
 
Even more strange: The behaviour was changed for the Enabled and Locked properties but not the Visible property which stlll shows error 2165
Did you try disabling it before you make it invisible? It makes a certain amount of sense - having it invisible while still having focus would be a little weird. Maybe the disabling will shift the focus away, and then you can make in invisible.
 
Doh! No I hadn't.
Disabling first DOES allow you to hide the control even if it is the only control on the form - so it must still have focus ?????
 
Doh! No I hadn't.
Disabling first DOES allow you to hide the control even if it is the only control on the form - so it must still have focus ?????
Well, yes- but at least in the newer versions, that no longer prevents you from removing that focus by disabling it. You CAN disable it, even if it has focus. But I can understand why making it invisible when it has focus throws an error. Having it enabled and having the focus remain on it while being invisible seems like it might cause all sorts of problems. I'm not claiming it's necessarily right or wrong, but I can understand the reasoning behind it. I suppose they could have incorporated the disabling into the invisibility, but I can also see why you would not want to force people to set the extra property of Enable when you had not disabled it earlier. People might want to leave it enabled, but by making it invisible, it is completely unreachable. Then making it visible again brings it back, fully functional.
 
Sorry but I can't follow your logic.
Controls that don't have focus can be hidden whether or not they are enabled or unlocked.
Then, in your words...
Then making it visible again brings it back, fully functional.
 
Sorry but I can't follow your logic.
Controls that don't have focus can be hidden whether or not they are enabled or unlocked.
Then, in your words...
Yes - if they don't have focus, you can do anything you want.
If they do have focus, you are limited. You can make it disabled (which you could not do in 2007, but you can now).
You can NOT make it invisible while it has focus. You must remove focus, by switching focus elsewhere, OR making it disabled.

If you leave it enabled, but make it invisible, you can bring it back to life by simply making it visible again.
If you first make it disabled, then make it invisible, there are TWO properties that must be toggled back before the control can be used again.

But again, making it invisible while leaving it as the ActiveControl seems like it could lead to problems, and apparently the designers also saw it that way, since they did not make this possible.
 
Last edited:
Partly playing devil's advocate here, but if you lock the control on form load or control click event you cannot then hide it.
So disabling also has the effect of removing the focus but locking doesn't

Anyway, its quite a neat trick - click me and I disappear
 

Attachments

Pretty neat. Unforeseen and unintended consequences are a regular occurrence in all sorts of complex systems. Software is no exception. Part of what makes the field challenging, I guess.
 
I've had a reply from the Access team. The change was originally made in connection with web databases but had wider effects as noted.
I'll let you know if I can pass on other info
 
@pdanes
I've just created a web article about this with a link back to this thread

 
@pdanes
I've just created a web article about this with a link back to this thread

Nice - thanks for taking the time to do this.
 
You're welcome. Thanks for bringing this modified feature to a wider audience
 

Users who are viewing this thread

Back
Top Bottom