How to move the search in VBA

[twgonder]

When searching for variables (or other) in a VBA project, the search box sits in the top left corner.

While there, it covers up important information in the title bar.
I can move it down to the bottom right, but after the next or replace it snaps back up to the top left.
Does anyone know how to stop this behavior of moving back and not staying where put?

 

[Pat Hartman]

Access moves the dialog to wherever it thinks it will be out of the way. It doesn't always get it right. Mine is rarely that far to the upper left. I just opened a search and the box opened With its top just below the top row of icons and just to the right of the "help" item on the menu. Maybe it depends on whether you are using one monitor or two. I use two. Or whether the VBA window is maximized or not.

looking at your picture, the left edge of my dialog would be an inch to the right of the ln 17, col 11 . Also, my first and second lines in the ribbon are the opposite of yours. The File, Edit, View is on row 2 and the icons are no the top row. Not sure when that happened or how.

 

[CJ_London]

mine open inline with the top of the immediate window and central to the monitor. This assumes the immediate window is open and docked in the vba window and the vba window is full screen. If VBA window is not full screen or the immediate window is closed or not docked it can open up anywhere.

I have a widescreen monitor split to 2 and a smaller one set to portrait. I get the above behaviour regardless of which monitor. If I spread the vba window across two monitors the find/replace aligns centrally to the left hand one.

A quick scan of the web indicates the above is what is expected but issues can occur if you have multiple monitors - and it is a system issue, nothing to do with vba or access.

A tip I found is If you are using multiple monitors is to go to display settings and align monitors at the bottom. See this link for more info, there is a bit more to it

VBA find dialog appears off screen

social.msdn.microsoft.com

 

[KitaYama]

This is what I do.
1- ctrl+F to bring up search
2- Type your search keyword and click Find Next button
3- Close the search dialogue. you don't need it any more.
4- Press F3 to continue search. Each time you press F3 the next item is searched

Edit: Don't forget that Access remembers the last searched keyword. If you searched for a keyword and an hour 2 later you want to search the same keyword again, you don't need to bring up the search dialogue. Just pressing F3 will continue the search.

 

[The_Doc_Man]

The trick here is that the little search "form" is a type of pop-up. (You know that it is a window because you can drag it around without moving what is under it and you don't push anything aside in doing so.) That suggests that you could use Win32 API routines to find the child windows of Access, one of which will be your search pop-up. Damned if I know what it would be called off-hand, but if you can find it, you can control its position through the window handle hWnd and suitable API calls. My question is whether you want to take on that kind of programming. You asked for how to do it, but to me it isn't worth that effort.

 

[twgonder]

The trick here is that the little search "form" is a type of pop-up. (You know that it is a window because you can drag it around without moving what is under it and you don't push anything aside in doing so.) That suggests that you could use Win32 API routines to find the child windows of Access, one of which will be your search pop-up. Damned if I know what it would be called off-hand, but if you can find it, you can control its position through the window handle hWnd and suitable API calls. My question is whether you want to take on that kind of programming. You asked for how to do it, but to me it isn't worth that effort.

You're right, but I would like to see what module and procedure I'm working in M$. Don't they test what they create?

 

[The_Doc_Man]

You're right, but I would like to see what module and procedure I'm working in M$. Don't they test what they create?

There are times when I wonder, but generally I think they do. The problem I have found is that the BEST tester of any software package is the end user, who will stress it in ways that the designer would never have considered.

Short anecdote: LONG before my Navy job, I used to work for a company that made systems to monitor and control oil & gas pipelines. We would have intermediate "acceptance testing" every so often to prove progress. So came the day of the day-shift operator's acceptance. The guy set the keyboard on the edge of a desk and then sat on the desk. Essentially an early form of "butt dialing." Crashed our system in a matter of about 4 seconds. After that, we had to put in special limiting code in the device driver (because it was an over-extended keyboard with special keycaps and a lot of extended functionality, like over 200 keys, and so couldn't use the standard keyboard driver.)

 

[CJ_London]

Don't they test what they create?

Sure they did when originally created the vbe. It would be a different team to access and you have been provided with two very simple workarounds.

 

[Minty]

I just tried mine and it comes up smack in the middle just below the toolbar? I have three monitors and the windows are set to overlapping;

Exactly the same position in Word, and Excel, so I don'tthink it's specifically an Access issue.

 

[CJ_London]

as with mine - its aligned to the top of the immediate window bar - my immediate window is at the bottom. Just to reiterate VBE window needs to be full screen

 

[NauticalGent]

First world problems...