| T O P I C R E V I E W |
| beylevem |
Posted - May 03 2007 : 12:09:19 PM
I upgraded to build 1555, and I am seeing an annoying "new feature". If I highlight and drag a variable to the watch window, the line that contains that variable gets positioned to the top or bottom of the edit window. This behavior also happens for certain other actions - i.e the active line gets moved to the edge of the edit window. |
| 30 L A T E S T R E P L I E S (Newest First) |
| feline |
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? |
| beylevem |
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 |
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 |
| DJH |
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 |
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. |
| DJH |
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 |
| feline |
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. |
| DJH |
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 |
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. |
| DJH |
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. |
| feline |
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. |
| beylevem |
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.
|
| beylevem |
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)
|
| DJH |
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 |
| feline |
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? |
| danpetitt |
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 |
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  |
| beylevem |
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 |
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. |
| beylevem |
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 |
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? |
| beylevem |
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 |
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. |
| beylevem |
Posted - Oct 15 2007 : 6:21:29 PM
When I experience the incremental search problem, it doesn't just happen once - I can repeat the cycle by hitting Ctrl+I again, and VA parses the file again....
|
| feline |
Posted - Oct 15 2007 : 6:16:22 PM
Incremental search, it is possible for VA to decide it needs to parse an unmodified file. For example if this is the first time VA has seen the file, it needs to parse it before it knows what to make of it.
You should mainly only see this problem after modifying the current file though. If you wait for a couple of seconds before triggering the incremental find (to give VA time to parse the file) then you should be fine.
Any clues that you can offer on the code dragging issue will be most useful. |
| beylevem |
Posted - Oct 15 2007 : 5:03:48 PM
With respect to the incremental search, the behavior you are seeing is the same as what I see. It happens to me sometimes even if the file associated with the current window has been saved. Other times, incremental search works fine - I have no idea how VAX gets itself in the broken mode, or why it thinks it needs to reparse the file. But the outcome is the same...
w.r.t. to the dragging code issue / screen repositioning, I had thought initially that the two phenomena were related. But it does not appear to be the case any more. The code dragging problem also only happens some of the time - I'll try to figure out what the common factor is as to when it happens.
|
| feline |
Posted - Oct 15 2007 : 4:49:04 PM
I can reproduce this problem with CTRL-I by doing the following:
Add a new local variable to a function, so there is an "interesting" code change that VA will want to know about
Press CTRL-I to start incrimental search mode very quickly, so before VA has reparsed the file
Now after a second or two I see what you describe, VA reparses the file, the status bar updates, and the incremental search is cancelled. I have put in a bug report for this:
case=9370
Does this seem to be what is happening for you?
If so then this is something, but I am not seeing any scrolling or screen repositioning going on. |
| beylevem |
Posted - Oct 14 2007 : 4:28:22 PM
The problem with incremental search is happening again. I don't know what triggers it, but when it happens, I hit Ctrl+I (which is bound to search incremental), and wait. Initially, the prompt for search incremental comes up, then I see a message saying VAX parsing "filename" - the name of the file that currently has focus, and then search incremental is gone and I have a ready status message in its place.
|
| feline |
Posted - Oct 09 2007 : 12:43:43 PM
We have had a few other reports of scrolling / jumping in VC6, but normally they are tied to very specific conditions and triggers.
Any further information you can provide would certainly be useful. |
| beylevem |
Posted - Oct 08 2007 : 5:56:30 PM
I have a number of other addins - cvsin, wndtabs, etc. I'll try and narrow it down and see if the problem occurs when they are disabled. Unfortunaletly, this is another intermittent problem, which makes it harder to nail... |
