| Author |
 Topic  |
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
 Posted - Oct 17 2007 : 08:03:41 AM
|
That is most unexpected. I am only seeing incremental search get cancelled the first time, and only if I have modified the file before triggering it.
When this happens, and incremental search is cancelled by VA parsing the file, do you end up typing into the current file? That would make sense if you were typing the search string when this happened. If the file was modified again, that would explain why VA felt the need to reparse it. |
zen is the art of being at one with the two'ness |
 |
|
|
beylevem
Tomato Guru
102 Posts |
Posted - Oct 17 2007 : 09:21:34 AM
|
No. It happened last night on an IDL file. I opened the file, went to the top, and hit ctrl+I. Before I could type anything, the prompt had gone. So I tried a couple more times, with the same result. Then I hit ctrl+F and moved on :-)
As a subjective observation, it does seem to happen more on large files
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Oct 17 2007 : 09:35:24 AM
|
IDL... Do you normally see this problem in "other" file types? Or do you see the problem just as often in .h and cpp files?
When you say large files what sort of size are you talking about? 200 lines? 200,000 lines? |
zen is the art of being at one with the two'ness |
|
|
|
beylevem
Tomato Guru
102 Posts |
Posted - Oct 17 2007 : 10:48:26 AM
|
2300 lines - large is relative
I mostly see the probllem in cpp files, but I have one large h file (ca 2000 lines) that I often see the problem in. (But then, that may be simply because I often do incremental searches on that file)
I'm hoping that the case that you synthesized has the same root cause, and that when that gets fixed, the problem goes away.... |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Oct 19 2007 : 08:53:27 AM
|
I have tried this in 4 different code files (cpp and .h files) in VC6, and I am not seeing any problems at all. The largest file is just under 23,000 lines, and VC6 has been sitting in Incremental search mode, with me changing the search string and jumping around the file, for several minutes now.
At least for me file size alone does not seem to be a factor, or a trigger.
Do you have:
VA Options -> Advanced -> C/C++ -> watch for externally modified files and reparse when necessary
turned on? If VA thinks something else is modifying the files this might explain the effect you are seeing, since it would be triggering a reparse of the files. The major flaw with this idea is that if the files are being modified you should be seeing IDE dialog's asking you if you want to reload the file, since someone else has changed it. That would be rather hard to miss. |
zen is the art of being at one with the two'ness |
|
|
|
beylevem
Tomato Guru
102 Posts |
Posted - Oct 19 2007 : 09:19:58 AM
|
I admire your persistence 
Yes, I do have watch for externally modified files turned on (although it's under performance on the VA Dialog.
Often, like now, incremental search has no problem. When that is the case, as you've pointed out, you can wait however long, and tere is no problem. It seems, based on your analysis, that there are two issues:
1) Reparsing a file is killing incremental search (already logged as 9370)
2) Reparsing is occurring unexpectedly
However, if 1) gets solved, 2) is minor.
I just found an additional piece of information about the reparsing. Everything was stable, and I added an extra blank line in a source file, then hit save. Now, every time I try incremental search, the problem happens. It's as if VA isn't recognizing the fact that it has already reparsed the file.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Oct 19 2007 : 09:38:44 AM
|
Interesting, I think I have just reproduced this effect, using my very large test file. Adding several blank lines produced a second, unexpected file parse. Or possibly the end of the initial file parse, it does take VA quite a while to parse this 23,000 line monster.
case=9370 should fix most to all of your problems
I do see one possible edge case, if you start the incremental find while VA is parsing, the parsing ending might disrupt the search, but I don't think there is much we can do about that. Plus this should be a rare situation.
The options dialog, it has been updated in 16xx, so sometimes I am posting the 15xx options dialog location and sometimes the 16xx options dialog location. It will be easier when everyone moves over to the new dialog, and I won't have to stop and wonder which version to post |
zen is the art of being at one with the two'ness |
|
|
|
danpetitt
Senior Member
28 Posts |
Posted - Oct 23 2007 : 04:37:31 AM
|
I am using VC6 and VAX build 10.3.1561.0 and I am getting terrible, consistent and very annoying scrolling problems ... that appear to be related to some of the posts in this topic but as its still in the latest build I take it that its not fixed.
Basically, if I select some text and just wish to move the selection using Drag and Drop to a line above or even within the same line, the window scrolls to the right and also down so that I am dropping in completely the wrong place.
I am also getting big selection/copy issues that may be related in that I select some text and copy it, when i get to paste its pasting not the text i copied but a whole line below/above it. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Oct 23 2007 : 09:16:37 AM
|
How easily can you reproduce these scrolling problems? You say "consistent", so is this every time?
I have just tried some simple drag and drop tests on some comments in VC6, VA 1561, win2k, and I am not seeing any scrolling problems.
Can you please go to:
VA Options -> About -> Copy Info
and paste the details (from the clipboard) into this thread. This will give us the basic information about your setup.
Do you have any other plugin's installed? |
zen is the art of being at one with the two'ness |
|
|
|
DJH
New Member
5 Posts |
Posted - Nov 05 2007 : 10:09:14 AM
|
I too am getting this drag/drop "feature" in VC6 with the latest builds of VA, and can confirm that it is extremely annoying!
Also, with VA turned on, if I split the window, the bottom pane now starts at line 1 of the file, not the line where the split was made as before.
Further more, in split pane mode, incremental search no longer works as reported by someone else in this thread.
With VA turned off I don't get the above "features".
-- DJH |
|
|
|
beylevem
Tomato Guru
102 Posts |
Posted - Nov 05 2007 : 10:16:03 AM
|
But the weird part about the split window "feature" is that the scrollbar is still positioned "correctly". If you click on the scrollbar and release with out moving it, the windows re-positions again. (And yes, I am seeing the reposition to line 1 as well)
VA_X.dll file version 10.4.1614.0 built 2007.10.22
MSDev.exe version 6.0.9782.1
Devshl.dll version 6.0.9782.0
Devedit.pkg version 6.0.9782.0
Font: Bitstream Vera Sans Mono 13(Pixels)
Comctl32.dll version 5.82.6000.16386
Windows Vista 6.0 Build 6000
2 processors
Platform: Win32 (x86)
|
|
|
|
beylevem
Tomato Guru
102 Posts |
Posted - Nov 05 2007 : 10:22:55 AM
|
And if you split the window by dragging the split bar down, and then immediately drag the split bar back to the top, all the text up to the split/focus point is selected.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Nov 05 2007 : 2:04:06 PM
|
DJH how are you reproducing these drag and drop problems?
How easily can you reproduce them?
Using VC6 and VA 1614 I am not seeing any problems with incremental search and a split window.
I am seeing the same problem with the bottom split jumping to the top of the file:
case=9702
This is a regression, it does not happen in VA 1561. For now double click on the splitter bar to split the window instead of dragging it. The problem only shows up for me when dragging to split the window, not when double clicking.
I am also seeing code being selected when closing the splitter by dragging:
case=9704
beylevem as you have probably already worked out double clicking the splitter closes it without selecting any code. |
zen is the art of being at one with the two'ness |
|
|
|
DJH
New Member
5 Posts |
Posted - Nov 05 2007 : 5:47:13 PM
|
To reproduce my drag/drop problem, select some text and then, holding the control key down, try to drag it several lines down - the screen then starts shifting sideways making it hard or even impossible to see where you wanted to drop the text. With VA disabled, or for dragging *very* short distances, I don't get this behaviour.
The incremental search problem in split pane is still 100% reproducible for me (even with build 1614); try doing inc search while VAX is actually parsing - breaks search. |
Edited by - DJH on Nov 06 2007 07:23:17 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Nov 06 2007 : 07:58:46 AM
|
Drag and drop, are you selecting whole lines of text or just a few words in the middle of a line? I have tried drag and drop several times with the Control key held down, and so far I am not seeing any unexpected scrolling at all.
How far are you dragging code? 3 lines? 300 lines? 3,000 lines?
The incremental search problem is a known bug:
case=9370
This only happens when VA parses the file while you are in the middle of an incremental find. For now if you use CTRL-F instead of CTRL-I if you need to run a find before VA has parsed your latest file edits this will avoid the problem. |
zen is the art of being at one with the two'ness |
|
|
|
DJH
New Member
5 Posts |
Posted - Nov 06 2007 : 10:18:31 AM
|
| Dragging text about half a page is usually enough to trigger this - but it doesn't happen all the time; maybe it's linked to when VAX is refreshing itself? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Nov 06 2007 : 1:09:38 PM
|
Do you only see this in small files? large files? Or are you seeing this in all files?
If you wait a couple of seconds after your last file edit, to give VA time to parse the changes (you should see a message flash by on the IDE status bar) does this stop the problem from happening?
I can believe that VA parsing the file would cause problems, but I would not expect horizontal scrolling. |
zen is the art of being at one with the two'ness |
|
|
|
DJH
New Member
5 Posts |
Posted - Nov 15 2007 : 04:07:13 AM
|
I currently use VC6 & VAX 10.4.1616.
It's hard to replicate the drag/drop horizontal scrolling bug because it doesn't happen all the time, but often enough to very annoying. As far as I can tell, it doesn't matter how big the file is providing it has more lines than can be shown in one window.
The incremental search bug is still there with VAX 10.4.1616.
Someone in this thread said that there is workaround to the split pane problem, but I couldn't understand what (s)he said. Please could some kind soul explain carefully how to split the window horizontally without loss of cursor position in either top or bottom pane?
DJH |
Edited by - DJH on Nov 15 2007 04:44:36 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Nov 15 2007 : 09:18:09 AM
|
The incremental search bug has not been fixed yet. This thread will be updated when it is fixed, telling you which build the fix is in.
To split the window without dragging, at the top of the vertical scroll bar there is the small "nob" which you left click and drag to split the window. Instead of clicking and dragging on this, double click on it with the left mouse button. When I do this it jumps to the middle, splitting the code window in half, and I am not seeing the scrolling problem.
Does this make sense?
The scrolling when dragging and dropping, any clues you can offer would be most helpful.
Can you estimate how often this happens? 1 time in 10? 1 time in 200? 1 time in 3,000? It could be I have not tried enough dragging to trigger it. |
zen is the art of being at one with the two'ness |
|
|
|
DJH
New Member
5 Posts |
Posted - Nov 15 2007 : 10:29:41 AM
|
Ahh, now I understand where to double click to get the splitting to work - thanks!
The drag drop thing - it's not really a case of how often. For a given edit session it may not happen at all, or it happens all the time. It's more a case of one edit window in perhaps 5 that it happens at all, but when it does it happens all the time in *that* window, unless I turn off VAX, in which case it behaves normally. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Nov 15 2007 : 3:18:12 PM
|
Now that's interesting. Next time this starts happening can you turn on VA logging, reproduce the problem, then close VC6 and send us the log files please. Closing VC6 stops the log files from getting to big.
The log files might offer some clues about this, especially since it is window specific.
Please see this FAQ for details of turning on VA's logging, and sending us the log files
http://docs.wholetomato.com?W305 |
zen is the art of being at one with the two'ness |
|
|
|
beylevem
Tomato Guru
102 Posts |
Posted - Nov 16 2007 : 08:41:45 AM
|
I encountered the problem with the screen jump when dragging text. I enabled logging, waited until the next time it happened, then saved my work and exited. Sanning the log files, the only possible relevant entries (right date stamp) were:
EDL::264 11/16/2007 07:39:29 0xe64
EDL::60 11/16/2007 07:39:29 0xe64
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19024 Posts |
Posted - Nov 17 2007 : 1:04:26 PM
|
These log entries don't seem to be offering any clues. Just standard "passing through here" entries.
beylevem are you seeing this problem at random? Is it somehow file / window specific, like DJH described? |
zen is the art of being at one with the two'ness |
|
|
|
Topic |
|
Screen re-positioning
