Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 OFIW + keyboard focus stealing

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
mkujawa Posted - Oct 08 2007 : 1:55:28 PM
I do a lot of file switching by hitting the Open Files In Workspace hotkey, typing in the file I want to go to, and hitting enter. Often times the reason that I am opening up this file is to search for something in it. This is what happens to me every time I do this:

Steps to Reproduce: (must type quickly!)
Bring up the OFIW window
Choose a file that is not currently open
hit Enter, click ok.
Very quickly thereafter, Hit Ctrl+F
Again, very quickly, start typing something, say "iterator"

results:
The file opens up, the find window appears, "it" gets typed into the find window, focus switches back to the source file, and "erator" gets typed into the source file.

This has been driving me crazy! Visual Stuido 2005, 8.0.50727.762 (SP.050727-7600), VA_X 10.3.1561.0
7   L A T E S T    R E P L I E S    (Newest First)
feline Posted - Oct 09 2007 : 3:43:58 PM
*ah* you have something here

I can reproduce this very easily on a machine with 2 processors, but I was testing on a single processor machine, where it is a lot harder to trigger:

case=9279

For now CTRL-I sounds like a good work around. Personally I prefer it to CTRL-F, since you get instant feedback to tell you if the text is being found.
mkujawa Posted - Oct 09 2007 : 12:45:08 PM
15,626 files in the solution. I opened up a small solution (19 files), and I can still reproduce the problem.

Incremental find is an interesting thought, since it doesn't change focus. Indeed, I can't get Ctrl+I to break. The Ctrl+F window is a bit of a pain when I don't need the extra options; maybe changing my muscle memory from Ctrl+F to Ctrl+I is the way to go.

Threading issue? All of the computers I tried this on are multi-core and pretty fast; mine is a quad-core 2.66GHz.
feline Posted - Oct 09 2007 : 12:29:09 PM
I don't understand why you are seeing the problem so easily, and it is virtually impossible for me to reproduce it.

How many files do you have in your solution? The number is given in the title bar of the OFIS dialog. The fact this seems to be tied to using the OFIW dialog suggests there is something about this dialog, so perhaps the number of items is it.

Do you see the same problem if you use CTRL-I for incremental find, instead of the find dialog?
mkujawa Posted - Oct 08 2007 : 5:03:27 PM
quote:
Originally posted by feline

Where does the speed matter?



I very often spend a while in OFIW choosing the file; it's once you hit ok/enter in OFIW that the race is on. If I wait for all the colors to settle down before bringing up the find window, everything will proceed normally. If I bring the find window up immediately after hitting enter in OFIW, it will lose focus a short time later (<1s.)


I've tried reproducing this via other means of opening files as well. With Window->Windows it works fine. Double-clicking in the solution works fine. With File->Open, I can occasionally get it to ignore the Ctrl+F, but the find window will never lose focus if I can summon it.

That above suggested something else to try just now: I disabled "enhanced syntax coloring" and tried again, but I can still reproduce it. I disabled a bunch of other visual assist features and it still happens.

Then I decided to try some non-c files. I tried doing this with some .sql files that I have in the solution, and I can't reproduce it. Even if I thrash memory so I know the file open will take a little while, it still works as expected. I only have one other kind of file in the solution: .jam. So I tried those and they exhibit the broken behavior. They're tiny and just text, so that's really surprising.
feline Posted - Oct 08 2007 : 4:04:50 PM
Where does the speed matter?

Can you open the OFIW dialog and filter it slowly, only having to trigger the Find dialog and type very quickly after switching to a file? Or do you have to do everything very quickly?

I would not expect the solution size to matter here, only the size and complexity of the files you are opening.
mkujawa Posted - Oct 08 2007 : 4:01:01 PM
quote:
Originally posted by feline

Are you seeing this with all files, or only large files?

...
Closing that file and trying the steps again, the problem did not show up.



All files, even files currently open in the environment.

Still happens with 1609 (thanks for the link.) I tried on several other computers here with similar environments, and it happens there too.

The project is pretty large, around 70k lines
feline Posted - Oct 08 2007 : 3:00:20 PM
Are you seeing this with all files, or only large files?

So far I have only been able to reproduce this once, when using a 22,000 line file. Closing that file and trying the steps again, the problem did not show up.

Can you try upgrading to VA 1609 and see if this helps? It is possible I am not really seeing the problem due to the version of VA I am using:

http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=6743

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000