forum.vdsworld.com

[ShinobiSoft]

Here's the context menu command ids for IE and the VDS browser object:

[jwfv]

Thanks for checking this out, Bill. If I have time today, perhaps I will study the @window() family of commands (never have used them much) and try to figure a way to cycle through each window and child window until I find the browser ...

Joe

[ShinobiSoft]

I'm glad I could help Joe . I checked into doing something similar with
the Adobe Acrobat reader and man does it have some child windows! Trying
to enumerate all those child windows is gonna be a task.

BTW, in an earlier post in this thread you mentioned something about an
edit that said "1 of 2", that is the page being displayed. Meaing that you were
viewing page "1" of "2" pages.

[jwfv]

Yes, Acrobat Reader has lots of child windows, and child-child and children of children...

I knew what the "1 of 2" was, I just want to see if there is a reliable way for me to read that information. (If the user clicks a button on my app, I can see what page they are viewing, and do something with it.)

Thanks -

I'll let you know if I make progress.

Joe

[jwfv]

Does anyone know how "Window Spy" gets all the windows and child windows in a list? If my program could recreate that list, then I can sequentially send a certain key combination to each one until I found which one I needed.

Jules - were you involved with the development of that?

[jules]

Yes I was. I don't know if this will help. It's hacked from the window spy code, but I haven't tested it as such.

[jwfv]

Thanks Jules -

I tried the code (the only thing I had to do was put "1" in place of the %%list variable in :AddItem.)

I got an error saying that the code was nested too deep. Apparently it doesn't like it when the :Breaksub code says to "gosub Breaksub". Is that allowed in VDS 5 - for a piece of code to "gosub" to itself?

[jwfv]

I am having some luck.

I found that I can send keystrokes to a window with the class #AVL_AVVIEW and the window text "AVPageView".

This window seems to be nested several child levels deep and I have no idea how to get the window handle reliably, but I will work on it.

[jules]

That code has worked since VDS 1, or whenever the Window Spy was written. The only problem with recursively gosubbing is that each call will use the same variables, and you have to stop recursing before you hit the limit. If an application's window structure is so deeply nested that you hit the limit then the Window Spy will probably have the same trouble.

[jwfv]

Jules -

I tried again and got the code working well. It does exactly what I need - returns a list of all windows, including child-child-child windows, for my app. Thanks! (The problem I had before was related to the %%list variable.)

I think with this code, I will be able to find the correct window (with text "AVPageView") and send all my keystrokes to it.

Thanks again!

[jwfv]

Here is an update:

I was able to use the code from Jules to reliably get the correct windows identifier that I needed to send the keystrokes to. When the PDF viewer has focus, it works perfectly.

I have run into a strange problem, however. If any other dialog element has focus (a list or button), then it seems to intercept the keys I am sending to the PDF viewer.

For instance, I have a button that sends a @key(Left) to the PDF viewer, which causes it to go back one page. If the viewer has focus, then it works great. But if a list on my dialog has focus, the list moves up one item, intercepting the @key(left). Even though I am using WINDOW SEND to send it to the window identifier of the Acrobat Viewer. And I can't set the focus to the browser window either - maybe due to the same problem that won't let it be a TAB stop...?

Strange.

[jules]

WINDOW SEND generates keystrokes. Keystrokes always go to the control that has focus. It hooks into the same mechanism used when you type on the keyboard, The help file isn't specific enough, but I think that the second parameter of the WINDOW command is meant to be an application main window. All it does is bring that window to the foreground so that it, and not some other app, will receive the keystrokes, but it doesn't determine which control within the window has the focus.

[jwfv]

I see. And it doesn't seem that I am able to set the focus to the browser element. (I just tested using a DIALOG FOCUS, BROWSER1 and then @FOCUS() still showed "List1".)

Jules - you mentioned in an earlier thread that the browser element was compiled with the Tab property set to false. Is that related to this? Is that something that could be changed in VDS6? I'm thinking that using the browser element opens up some very nice possibilities for VDS, but it sure would be handy to be able to set focus to it and easily send it keystrokes.

[jules]

Yes, this may have something to do with it. There is ambiguity in the use of the tab key. With the EDIT element you have to add a TAB style if you want to be able to insert tabs in the text, instead of using it to go to the next element that can have focus. With the BROWSER element the tab key always takes you to the next element. I presume that this could easily be changed for VDS 6, and a TAB style added. In the meantime, didn't I read here that someone else has produced a browser element DLL that doesn't have this problem?

[marty]

Well my VDSSURFX has the same issue. And I tried with a component to enable the TAB and other keys that dont work in the browser element.

Altho the component I used is suppose to work, I never managed to make the TAB enabled..