How to set focus back on Access? (1 Viewer)

[KitaYama]

In after updated event of a text box, I use shell command to open a document (a pdf or drawing of the product) on a second monitor.
When the pdf is opened, Windows moves the focus to the recently opened document. So I have to click MS Access window again to set the focus on it and be able to continue inputting next text boxes.

Is there any way to bring back focus to Access window after opening a pdf file?

This is the code I'm using at present :

Declare PtrSafe Function apiShellExecute Lib "shell32.dll" Alias "ShellExecuteA" ( _
   ByVal hwnd As Long, _
   ByVal lpOperation As String, _
   ByVal lpFile As String, _
   ByVal lpParameters As String, _
   ByVal lpDirectory As String, _
   ByVal nShowCmd As Long) _
   As Long

Public Sub PrintFile( _
                 ByVal FileName As String, _
                 Optional PrintShow As String = "Open")
    
    Call apiShellExecute(hWndAccessApp, PrintShow, FileName, vbNormalNoFocus, vbNullString, vbNormalNoFocus)

End Sub

Thanks for any kind of advice.

 

[theDBguy]

Just guessing but have you tried using SetFocus? For example:

Call apiShellExecute(...)
Me.SomeControlName.SetFocus

 

[KitaYama]

Just guessing but have you tried using SetFocus? For example:

Call apiShellExecute(...)
Me.SomeControlName.SetFocus

Yes. But nothing changes.
From Access point of view, the focus is on the specified control. I can see it because the pointer is blinking in the text box.
But from Windows point of view, the pdf file has the focus. So how many times I press Enter or other keys, the keys are sent to active window (pdf in this case) and not to Access.

I think I must find a way to change the focus between applications rather than focus between controls in Access.

Thanks

 

[theDBguy]

Yes. But nothing changes.
From Access point of view, the focus is on the specified control. I can see it because the pointer is blinking in the text box.
But from Windows point of view, the pdf file has the focus. So how many times I press Enter or other keys, the keys are sent to active window (pdf in this case) and not to Access.

I think I must find a way to change the focus between applications rather than focus between controls in Access.

Thanks

I see. I just gave it a try by opening the PDF in a minimized window, and the focus stayed on Access.

 

[KitaYama]

I need to see the pdf while inputting data in the form. If the pdf is minimized, there's no point in opening it.

Thanks anyway.

 

[theDBguy]

I need to see the pdf while inputting data in the form. If the pdf is minimized, there's no point in opening it.

Thanks anyway.

Okay, one last try... I don't usually use APIs. Can you try using FollowHyperlink to open the pdf?

 

[KitaYama]

Okay, one last try... I don't usually use APIs. Can you try using FollowHyperlink to open the pdf?

I'm not a fun of APIs too. I simply used it for the sake of vbNormalNofocus parameter to keep focus on Access. But it seems that's meaningless.

I used :

Application.FollowHyperlink FindDrawings(OrderProductFK.Column(1))

Still the same result. Key strokes are sent to Adobe and not to Access.
FindDrawings is a function to return the Drawing saved address based on its PK.

 

[theDBguy]

I'm not a fun of APIs too. I simply used it for the sake of vbNormalNofocus parameter to keep focus on Access. But it seems that's meaningless.

I used :

Application.FollowHyperlink FindDrawings(OrderProductFK.Column(1))

Still the same result. Key strokes are sent to Adobe and not to Access.
FindDrawings is a function to return the Drawing saved address based on its PK.

Sorry to hear it didn't work. When I tested it, the focus stayed with Access. However, I only tested it using the Immediate Window. Could you please test it again using the Immediate Window and pass a literal path to the pdf file, just to verify if the behavior is different when running code from a Form?

 

[KitaYama]

Sorry to hear it didn't work. When I tested it, the focus stayed with Access. However, I only tested it using the Immediate Window. Could you please test it again using the Immediate Window and pass a literal path to the pdf file, just to verify if the behavior is different when running code from a Form?

I'm sorry for this stupid question. But how can I check it.
I typed Application.FollowHyperlink "Z:\Drawings\N\J\1\NJ11146BJ004.pdf" in immediate window and pressed the Enter key.
The drawing is opened. How can I test where the focus is? If I press Enter key, the cursor moves to the next line in immediate window.

I don't think it shows that Access has the focus.
Or even if this proves that Access keeps the focus after FollowHyperlink, how we can implement it in a afterUpdate event?

thanks again.

 

[theDBguy]

I'm sorry for this stupid question. But how can I check it.
I typed Application.FollowHyperlink "Z:\Drawings\N\J\1\NJ11146BJ004.pdf" in immediate window and pressed the Enter key.
The drawing is opened. How can I test where the focus is? If I press Enter key, the cursor moves to the next line in immediate window.

I don't think it shows that Access has the focus.
Or even if this proves that Access keeps the focus after FollowHyperlink, how we can implement it in a afterUpdate event?

thanks again.

After the pdf opened, I pressed the Alt key to see which menu would activate. With the API, the Acrobat menu was highlighted. With the FollowHyperlink method, the Access VBA menu activated.

 

[KitaYama]

After the pdf opened, I pressed the Alt key to see which menu would activate. With the API, the Acrobat menu was highlighted. With the FollowHyperlink method, the Access VBA menu activated.

Well, mine is the same. ALT key highlights VBE's menu.
But if I move the exact command to after update of any textbox, pdf responds to key strokes.

 

[The_Doc_Man]

How can I test where the focus is?

Consider before you start this app to change the Windows theme, perhaps to a custom scheme that emphasizes the active window border. Some of the more modern themes are a bit bland.

 

[theDBguy]

Well, mine is the same. ALT key highlights VBE's menu.
But if I move the exact command to after update of any textbox, pdf responds to key strokes.

Okay, thanks. That's all I was trying to confirm. So I guess Access behaves differently when running code from the VBA window.

 

[theDBguy]

By the way, I think there is an API for Bring Window to Front, but I have no experience with that. Good luck!

 

[theDBguy]

I just had one last thought before going to bed. If it's just for pdf files, perhaps another approach is to use a web browser control in a popup form to view the pdf file in Access.

 

[Solo712]

I just had one last thought before going to bed. If it's just for pdf files, perhaps another approach is to use a web browser control in a popup form to view the pdf file in Access.

The point to get here is that when you execute the Shell command the focus is passed to that program, and Access has no control over the display run under Windows. My guess is that with the web browser control you could take the focus elsewhere but I have not tested this.

Jiri.

 

[KitaYama]

The point to get here is that when you execute the Shell command the focus is passed to that program

I had a feeling vbNormalNoFocus parameter is there to keep the focus on current application. Not the opened one.
But I'm afraid you are correct.

 

[The_Doc_Man]

Searching for an answer, I ran across a reply that reminded me of a Windows Security issue. In general, if you do not possess elevated privilege, you might not be able to do this. In the middle of that post there is a cut/paste from MSDN documentation on the BringToFront method. Some of the methods discussed in the link require you to know the hWnd handle (which is a form property). However, it is possible that you would have to navigate a bit using .Parent properties to find the Access "parent window" to bring it to the front. Bringing a form to the front (by itself) would have the effect of bring the form to the front of the Access window but wouldn't move the Access window as a whole.

How to bring my application to the front?

I know all the reasons why it is a bad idea. I dislike it if an application steals input focus, but this is for purely personal use and I want it to happen; it will not disturb anything. (for the

stackoverflow.com

Here is another discussion from the Excel VBA side of things, but that should work about the same.

VBA API declarations. Bring window to front , regardless of application

I am trying to bring and Excel window to the front of all applications running regardless. Current code, Private Declare Function SetForegroundWindow _ Lib "user32" _ ...

stackoverflow.com

Finally, here is a different thread regarding the problem from C++.

Win32 ::SetForegroundWindow() not working all the time

I'm working on a messenging tool. The messaging window is part of a whole application. I need the window to go to the front when there are some messages coming. I'am using this code : if( m_hw...

stackoverflow.com

In all cases, Windows has these pesky little internal security rules about who can do something to another process - which is what you are doing when you try to bring an app to the front. They seem to all point back to the Win32 API for that purpose, and from your discussion, your REAL problem is that the rule that put your shelled program in front isn't reversible. The shelled program could release the window or exit, but until one of those events occurs, it owns the front position.

EDIT: For clarity... using SHELL creates a new process, not a child process. That is a contributor to the difficulty. If it had been a child process, then Access DOES have sufficient control regarding BringToFront among its child windows (i.e. individual forms).

 

[KitaYama]

Million thanks Doc for your effort to help.
I'll go through your links this evening when I have a little bit free time and see if I can find a solution.

 

[arnelgp]

you have same dilemma in this thread:
Solved - Open a file without moving the focus | Access World Forums (access-programmers.co.uk)