Using Hyperlink click bypasses OnUpdate event of other controls

[Old Goat]

I have been tasked to replace command buttons in an Access 2003 application with label controls with a space in the hyperlink property to enable them as hyperlinks.



The problem is that our application has a lot of code that is written assuming the AfterUpdate event fires on a text box, for instance, before the hyperlink is clicked.

The OLD application used command buttons, and when clicked, the AfterUpdate event of the text box control fired before the command button code. When using a hyperlink, it does not fire at all.

Is there any way to force the AfterUpdate and other events that are bypassed when a hyperlink is clicked?

[RuralGuy]

Did you notice that there are very few Events in a Label. Like maybe none. That probably means it cannot take the focus away from another Control. Not a particularly good choice for your alternative. Keep looking. You're getting warm.

[Old Goat]

Did you notice that there are very few Events in a Label. Like maybe none. That probably means it cannot take the focus away from another Control. Not a particularly good choice for your alternative. Keep looking. You're getting warm.

Thanks, RuralGuy. I've been programming Access for almost 20 years, and know the label control was not intended for this purpose. I would much rather be rewriting the application in C#, but that's another discussion entirely. Until then, I have to attempt to make a 15-year-old Access application look like a web page.

There is an alternative...float a transparent command button over the label that calls the label's click event. That, however, eliminates the behavior of the the cursor turning into a hand when it is floated over the hyperlink. So, that is not a perfect solution, and I'm instead looking for maybe some command to put at the beginning of each hyperlink that would ensure all the normal events for the other controls fire just as if it was a command button.

I tried stuff like DoCmd.RunCmd acCmdSaveXXXXXXXXXXX (tried a couple of different ones) and none of them worked.

Oh, and in my original post, I misspoke. It is the LostFocus event of the text box control that fires when you click a command button, but not the hyperlink. As it turns out, I can get it to fire by adding a dummy text box, and setting focus to it when the hyperlink is clicked...so it looks like I've solved my problem. At least I hope so!

Anyway, thanks for the help!

[RuralGuy]

Good luck with that project. Should be interesting, if nothing else.

[Old Goat]

Thanks, it has been. Another programmer and I have been working on it for about four months. and code freeze is next week. Other than a couple little issues like this one, it has turned out to my satisfaction. More importantly, my manger, the CEO, and our sales team are all very happy. Accounts Payable and General Ledger apps deployed in a Citrix environment. There's somewhere around 500 facilities around the nation that use it.

Nothing against Access, but I look forward to the day when I get to program nothing but C#. :-)

[RuralGuy]

Understood.

[ItsMe]

How about replacing the old command buttons with unbound text boxes instead of using labels? You can control the unbound text boxes dynamically at the form level.

I didn't read the entire thread but, you mentioned you were after a website look. So format the text box to look and behave like a hyperlink within a webpage. At the form level, use the exit event on the bound control to dynamically update your new unbound text box/hyperlink.

[Old Goat]

How about replacing the old command buttons with unbound text boxes instead of using labels? You can control the unbound text boxes dynamically at the form level. I didn't read the entire thread but, you mentioned you were after a website look. So format the text box to look and behave like a hyperlink within a webpage. At the form level, use the exit event on the bound control to dynamically update your new unbound text box/hyperlink.

Provided the user uses a TAB or ENTER, that works just fine. The problem occurs when the user types something, and instead of tabbing or hitting enter, they grab the mouse and click the hyperlink. In that case, it bypasses the Lost Focus event. Really, the answer is using the Lost Focus event of a text box to do critical processing is poor form to state it politely as possible. For now, we're just adding a hidden text box called txtTabStop to the affected forms, and in the hyperlink calling the .SetFocus method of it. That fires the LostFocus event of the last control, so though it is a manual fix, we've solved it. Thanks for the help, folks!