Solved: How to center the display of a found text?

[Sebastian H]

When I search text, Word 2003 displays it at the very edge of the document window. (That is, right at the top, when searching downwards.) This is very inconvenient, because it deprives me of the context. I believe there is no way to change that behavior in Word, so I was thinking of writing a macro to automatically scroll the text so that the found text appears in the middle of the document window. In theory, that seemed easy: Get the position, and scroll accordingly. However, both are hard in practice:

Getting the position should be accomplished with GetCaretPos, but that doesn't work for me. Google "VBA GetCaretPos" lists only problems. I do get reasonably looking values, but they behave somewhat erratically. (Often, they don't change when I change the position. At least that happens when I move it in a macro.) Still, I might be able to make something useful with that, but then there is another problem:

How do you scroll by a certain amount of pixels? We have of course ActiveWindow.ActivePane.SmallScroll, but that would require me to know each line height, which seems like a big hassle for what should be a simple task. A less tedious way should be by using ActivePane.SmallScroll, but for that I'd need to know what percentage of the document is currently displayed.

I also tried LargeScroll Down:=0.5, but that just doesn't do anything. (Or scrolls down by 0 pages :giggles:. Of course, that was before I realized that that scrolls print pages, rather than screens, so it wouldn't be that helpful anyway.)

[Sebastian H]

Sorry, in the last sentence of the third paragraph above I meant "ActiveWindow.ActivePane.VerticalPercentScrolled", not "SmallScroll". A pity that it's not possible to edit posts as long as nobody replied!

[macropod]

Hi Sebastian,

Why not use something like:
ActiveWindow.SmallScroll -5
That should scroll the found text down by 5 lines.

[Sebastian H]

Why not use something like:
ActiveWindow.SmallScroll -5
That should scroll the found text down by 5 lines.
Because I had thought that the "lines" were the same as the lines in MoveDown Unit:=wdLine, Count:=5. That would have meant that when I have a picture on a page, or a headline, scrolling would be different.

However, I now realize that that is not the case; the scroll amount doesn't change a lot when the lines are spaced further apart. It does seem to change a bit, though. So, how is that scroll-line defined? Is there any way to get a conversion between that unit and pixels?

[macropod]

Pass.

[Sebastian H]

Anyone else who knows more about pixels?
:anyone:

[fumei]

From Help: "A "line" corresponds to the distance scrolled by clicking the down scroll arrow on the vertical scroll bar once."

Therefore the effect of smallscroll:=5 is the same as clicking the down arrow 5 times. In other words, there is no direct connection to pixels. The connections is to the action of clicking an arrow.

[Sebastian H]

Thank you for your reply. I did read the help, but I was still hoping that the scroll down arrow scrolled by a well defined distance. If you say so, I sadly have to give up that hope.

Is there any way to scroll the screen by a well defined distance?

[fumei]

No. Simply because "well-defined" is an impossibility within Word. Word is 100% driven by the installed printer driver. Further, what if you have zoomed in, or out?

This is the problem with doing anything dependent on the GUI. It all ends up as : it depends.

[Sebastian H]

Thank you - I finally understand why it can't be done. If Word itself doesn't even know how many pixels it's scrolling, then there's no hope. I guess that's why the scrolling problem exists in the first place; Apparently, Word just doesn't have control over where on the screen it displays the selected text. With a heavy heart, therefore, I'm marking this as resolved.

[fumei]

Well, true, you can not do what you wish to do, but to state that Word does not have control over where it displays anything is not accurate. It does. However, that does NOT mean this is exposed to VBA. There are a number of things that Word can do, but this is not exposed (allowed) to VBA.

Word passes instruction to the GUI (Windows). The issue is Windows, and the fact that Word is totally dependent on the printer driver.

Think it through though.

Say you have the "text" : Whatever.

OK, fine.

THAT text takes up X number of vertical pixels. BUT, X has different values depending on the zoom factor.

Yes, it has a "line", and in theory you can state it is ONE line.

"I had thought that the "lines" were the same as the lines in MoveDown Unit:=wdLine, Count:=5. "

And, unfortunately, no, it is not. It could be 2 vertical pixels, 10 vertical pixels, 50 vertical pixels.

So, what is X? It depends.

Sorry, but yes, I would abandon this. Is it in theory possible to do something like what you considered. Possibly. But it would take a much deeper access to the GUI system than you can get with VBA.

[Sebastian H]

Thank you for your clarification; I did indeed misunderstand your previous statement.

That misunderstanding, however, was not caused by not thinking things through, as you seem to imply. I always do that before I ask others for help. I just took your terms "impossibility" and "100% driven by the ... driver" literally. (If someone is 100% driven by someone else, they have no control.) There was nothing wrong with the logic of my statement: I didn't say that not knowing it is a sufficient condition for not exposing it; all I said was that knowing it would be a necessary condition for exposing it. If Word knows (or has a way to know) where the selection is on the screen, then it could in theory pass that on to VBA via some function like GetSystemMetrics. The decision to not do so is understandable, given that the mechanics are not trivial, but it is not necessary.

[fumei]

Sorry, I did not mean to sound critical.

[Sebastian H]

No problem; I'm sorry about my tetchy reply of yesterday, too. :friends:

[fumei]

We are agreed! Heading off into GetSystemMetrics may - may - make your desired effect possible, but it is likely to mean a huge investment for diminishing return.

I have often had wonderment at VBA. In some ways it is very powerful, and in others it is more like an idiot savant.

It has a lot to do with how Microsoft determines what is, and what is not, exposed. For example, I still do not undertsand why Microsoft removed FileSearch from 2007 VBA.

It also seems odd (but understandable in technical terms) that something you CAN do on screen ( via GUI), you can NOT do in code (via VBA).

You can action - say apply a Bold - to non-contiguous areas of text on screen. This is literally impossible in VBA. It can not be done.

[Sebastian H]

I agree with your latest post, too.

Re the non-contiguous area, you can (once you selected it manually with Alt-Mouse), action a non-contiguous area, e.g. withSelection.Font.Bold = wdToggle. But I wouldn't know how to select it with VBA in the first place; there seems to be no Union in Word, as there is in Excel.

Why FileSearch was cut, I don't know either. Maybe they were afraid of vulnerabilities, or maybe it's because Microsoft has moved towards not relying on the file system in general (think about managed code, e.g.). Well, one more reason for me to happily stick with Office 2003! :content:

[fumei]

You can not select non-contiguous areas with VBA.