Setting focus

[StephenUK]

I like to run up and down the explorer tree (using arrow keys)with notes and items displaying as I do so, but with the focus remaining in the tree.

I have set Options / Misc / "Set focus to active selection pane when going to an item".

Nonetheless, when running up and down the tree, if there is a pdf or a Word document for example, the focus gets diverted away from the tree, and there can also be a delay if a Word document loads. I then have to refocus on the tree, which is a nuisance.

With rtf notes and directories, for example, this problem does not arise and the focus remains in the tree.

Is there any way to ensure that the focus is always on the tree regardless of what type of document is involved and regardless as to whether documents are set to display in native format?

[zargron]

If think that is already in the Roadmap:

Prevent browser/detail pane from stealing focus

[StephenUK]

Zargron - many thanks. At least I know I'm not doing something wrong....

[Taxi]

I also like to run up and down the explorer tree (using arrow keys) as described in the first post. I would therefore like to offer a big thank you for Version 3.2, which fixes this problem.

However, I have noticed some rather quirky behaviour when navigating a Data Explorer tree containing a mix of linked MSWord documents and other internal items. When I move off a linked document onto another item, the cursor movement keys, (not just Up and Down, but PageUp, PageDown, Home, End, etc) stop working. I have to use the mouse to select another item to release these keys!

It has fixed itself in two of my URD files, one after editing a note, and one after a compact and repair. But it has re-occured after closing and later re-opening the fixed files. I cannot reproduce this fix in these or other affected URD files

Initally the problem only affect my Desktop, but after copying files from my Desktop to my laptop I notice the problem on that machine as well!

[StephenUK]

Taxi - I hadn't realised the improvement in v 3.2 and have just tried it out. I find on my machine that the focus is not now diverted away from the tree for Word documents which it was before. (Many thanks Kinook). Nor is it for saved web pages and notes. But, like you, I still have some problems. Mhtl files created elsewhere, and more importantly, pdf files still steal the focus and I then need to refocus which I do with the mouse.

So we are not quite there yet on this issue. I have not noticed anything get worse than before, so v3.2 for me is a welcome improvement.

[kinook]

Originally posted by Taxi
I also like to run up and down the explorer tree (using arrow keys) as described in the first post. I would therefore like to offer a big thank you for Version 3.2, which fixes this problem.

However, I have noticed some rather quirky behaviour when navigating a Data Explorer tree containing a mix of linked MSWord documents and other internal items. When I move off a linked document onto another item, the cursor movement keys, (not just Up and Down, but PageUp, PageDown, Home, End, etc) stop working. I have to use the mouse to select another item to release these keys!

It has fixed itself in two of my URD files, one after editing a note, and one after a compact and repair. But it has re-occured after closing and later re-opening the fixed files. I cannot reproduce this fix in these or other affected URD files

Initally the problem only affect my Desktop, but after copying files from my Desktop to my laptop I notice the problem on that machine as well!
I wasn't able to reproduce this problem. Does using Ctrl+1 to refocus the DE pane or Alt+Tabbing away and back help?

[kinook]

Originally posted by StephenUK
Taxi - I hadn't realised the improvement in v 3.2 and have just tried it out. I find on my machine that the focus is not now diverted away from the tree for Word documents which it was before. (Many thanks Kinook). Nor is it for saved web pages and notes. But, like you, I still have some problems. Mhtl files created elsewhere, and more importantly, pdf files still steal the focus and I then need to refocus which I do with the mouse.
We found Adobe Acrobat Reader to be rather insistent about keeping the focus and Foxit Reader (http://www.kinook.com/Forum/showthread.php?threadid=2430) to be more accommodating in this regard.

[Taxi]

Originally posted by kinook
I wasn't able to reproduce this problem. Does using Ctrl+1 to refocus the DE pane or Alt+Tabbing away and back help?

Ctrl+1 also non-functioning but Alt+Tabbing away (interestingly) shows MSWord as the first icon in the Task Switching dialog (with UR as the second pre-selected icon, so releasing the Alt+Tab keys also allows me to continue moving around the DE Pane in UR using the cursor keys).

I've also noticed that, if I already have MSWord open in another window, that window will jump to the front when I move off a linked document onto another item. This suggests that MSWord is somehow continuing to grab my keystrokes when I try to move away from it. (Although I can quite happily browse a list of MSWord documents with focus staying in the DE pane - and it does fix itself at random intervals!

[StephenUK]

Kinook - yes I was using Acrobat. But I find Acrobat 8 much faster loading than Acrobat 7 and nearly as fast as Foxit, and the type faces look better formed in Acrobat than Foxit. Apart from the loss of focus issue I like Acrobat v8.

Maybe I can live with the loss of focus for pdfs!

[quant]

Originally posted by StephenUK
Kinook - yes I was using Acrobat. But I find Acrobat 8 much faster loading than Acrobat 7 and nearly as fast as Foxit, and the type faces look better formed in Acrobat than Foxit. Apart from the loss of focus issue I like Acrobat v8.

Maybe I can live with the loss of focus for pdfs!

ufff, seeing your post, I thought I'd give Reader 8 a try ... maybe my laptop is getting old (1.7 pentium centrino, 1GB RAM), but Reader 8 is sooooooooo slooooooow, both first opening, and also the page scrolling takes ages ... back to Foxit Reader ...

[StephenUK]

Quant - I did read that Acrobat loads much faster if the add-ins are excluded. Maybe that is the difference. Just a thought.

[Taxi]

Originally posted by Taxi
I've also noticed that, if I already have MSWord open in another window, that window will jump to the front when I move off a linked document onto another item.

The behaviour mentioned above also occurs when I am using a urd file that is working properly. It is only noticeable when the MSWord window is hidden behind the UR window, (not if MSWord is minimised)!

What happens is that, when I move away from a linked MSWord document in the Data Explorer tree, the MSWord window, which hold a completely different document, jumps to the front. However, this MSWord window is inactive, the focus is still in the Data Explorer tree. So, I can continue moving around the Data Explorer tree, using the cursor keys or any other Keyboard Shortcuts in UR. I can also use the mouse to select anything visible in the UR window with the inactive MSWord window remaining stubbornly on top of it.

The only way I can get rid if it is to switch to MSWord then switch back again!

[kinook]

I'm not seeing this on Win XP SP2 w/ Word 2003 SP2, but it sounds like a Word quirk (UR itself would not activate Word unless explicitly editing a Word document item externally [Ctrl+J]).

[Taxi]

I also have Win XP SP2 w/ Word 2003 SP2.

On investigating my systems to identify what it might be about my set-up that is causing this "Word quirk", I have been monitoring the Processes tab in the Windows Task Manager while navigating the Data Explorer tree with the Up and Down arrow keys. (With MSWord not running at all).

I have noticed a (system) process named WINWORD.EXE that does not appear until I select a linked MSWord document. At which point this process starts and takes a chunk of CPU for a few seconds. When I move away from the linked document, the WINWORD.EXE process takes another chunk of CPU for a few more seconds. Subsequently, this process remains in memory until I exit UR, even if I never select another linked document.

I have confirmed this behaviour on both my Desktop and Laptop as well as a colleague's laptop running from a USB stick!

As you say:

Originally posted by kinook
UR itself would not activate Word unless explicitly editing a Word document item externally [Ctrl+J].

Have I found three quirky MSWord installations or is this normal UR behaviour that you do not consider to be "activating Word"?

[quant]

Originally posted by Taxi
Have I found three quirky MSWord installations or is this normal UR behaviour that you do not consider to be "activating Word"?

I think the key here is, do you open the documents externally? Or do you "open" it inside the UR, that uses the fact the word can be embedded in IE? Just drag your word file to IE, and even if your close it, winword will still be running ... complain to M$!

[Taxi]

quant: - In response to your question, I was, for the purpose of my investigation, "opening" a Word document inside UR, using the fact the Word can be embedded in IE. MSWord was not running at all during this investigation.

I assume from your observations about the behaviour of Word when you drag a Word file to IE, that what I am seeing is normal behaviour that is not considered to be "activating Word"? And so I must look elsewhere for the "Word quirk" that could be the cause of my problem.

Which is, as you will recall, that when MSWord is running in the background as a separate task, the (inactive) MSWord window appears on top of UR when I move away from a linked document that is visible in the version of Word embedded in the Browser/Item Details pane of UR.

[kinook]

Originally posted by Taxi
I also have Win XP SP2 w/ Word 2003 SP2.

On investigating my systems to identify what it might be about my set-up that is causing this "Word quirk", I have been monitoring the Processes tab in the Windows Task Manager while navigating the Data Explorer tree with the Up and Down arrow keys. (With MSWord not running at all).

I have noticed a (system) process named WINWORD.EXE that does not appear until I select a linked MSWord document. At which point this process starts and takes a chunk of CPU for a few seconds. When I move away from the linked document, the WINWORD.EXE process takes another chunk of CPU for a few more seconds. Subsequently, this process remains in memory until I exit UR, even if I never select another linked document.

I have confirmed this behaviour on both my Desktop and Laptop as well as a colleague's laptop running from a USB stick!
That is to be expected -- when Word documents are edited internally in UR (UR hosts IE, which in turn hosts Word), a winword.exe process (where the Word functionality resides) will be created if it doesn't already exist. That's just how OLE embedding works.

Have I found three quirky MSWord installations or is this normal UR behaviour that you do not consider to be "activating Word"?
To be more specific, UR will not activate an external Word instance/window. I'm not sure why an external Word instance is being activated/redrawn in your case, but UR itself is not doing it.