| Author |
 Topic  |
|
|
willdean
Tomato Guru
134 Posts |
 Posted - Feb 18 2004 : 1:59:25 PM
|
I don't know if you want me to post this for every build, but reparse still doesn't work properly in 1216 (VS2003, unmanaged C++)
E.g. I define a new variable, then rename it immediately (it goes black), then scroll away from that area of the file before VA colours the variable. New references to that new variable will not be coloured. No amount of waiting or reparsing seems to do anything. Scrolling (possibly back to the var definition, but I'm not 100% certain if you need to do that) seems to fix things.
Something similar happens if you un-comment a definition (or a #define) which has been commented out - references elsewhere don't get coloured, and reparse doesn't work.
Personally, I'd much rather you fixed the manual reparse *before* you fixed whatever other minor bugs are stopping the autoparser. I realise that might not by the WT agenda, though.
1216 is definitely starting to get good, though.
Will
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Feb 19 2004 : 04:21:35 AM
|
I had one instance yesterday where reparse didn't appear to work. It was actually a file that was already open at the time I first launched the solution. None of the identifiers were in identifier colour, and they remained uncoloured when I pressed the reparse button.
However, I noticed that reparse was actually working because a message flashed in the status bar as described by support in the previous thread. And when I selected a block of text with the mouse, that region was then coloured correctly.
Re-reading the previous thread, I suspect this is probably not the same as your problem. And I couldn't reproduce it. But I thought I'd throw it into the mix.
|
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
 |
|
|
willdean
Tomato Guru
134 Posts |
Posted - Feb 19 2004 : 09:39:41 AM
|
I'm starting to think that this isn't a reparse problem, but a repaint one.
Most of the time I have this type of problem, causing the edit window to redraw (e.g. ALT-TABbing away from VS and back again) is enough to fix it.
Could you make manual reparse do a repaint of the edit window, please?
|
|
|
|
PatLuja
Tomato Guru
Belgium
416 Posts |
Posted - Feb 20 2004 : 02:32:26 AM
|
Hello all,
I have the same feeling as Will about this. I've seen the repainting thing many times. But there's something strange about it. When I ALT-TAB to another full screened application, and I return to Visual Studio, the colours are right. But when I then scroll the page to another location, and than back to the same spot, the colours have changed again.
So it doesn't only seems to be a redrawing problem.
With kind regards,
Patrick Luja
P.S. And I also second Will's opinion that VA X is definitely starting to get good.  |
Edited by - PatLuja on Feb 28 2004 09:25:30 AM |
|
|
|
gstelmack
Ketchup Master
USA
76 Posts |
Posted - Mar 02 2004 : 10:11:11 AM
|
| This seems much worse in 1218. I now regularly have files opened in my IDE without the advanced syntax coloring happening. I don't know if it's a coloring issue, a painting issue, or a reparse issue. |
-- Greg Stelmack, Red Storm Entertainment |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Mar 02 2004 : 4:10:22 PM
|
When the problem happens, does all coloring stop, or just certain symbols defined in the file?
Are you all using VS.NET? East Asian Languages installed? Black backgrounds? Any other clues?
|
Whole Tomato Software, Inc. |
|
|
|
kschaab
Tomato Guru
USA
118 Posts |
Posted - Mar 02 2004 : 5:56:24 PM
|
VA_X.dll file version 10.0.1218.0
Licensed to: [email protected] (1-user license)
VA4 License: [email protected] (1-user license)
VAOpsWin.dll version 1.0.0.40
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Courier New 12(Pixels)
Comctl32.dll version 5.82.3790.0
WindowsNT 5.2 Build 3790
2 processors
Platform: Win32
Stable Includes:
c:\\program files\\microsoft visual studio .net 2003\\vc7\\include;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\include;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\PlatformSDK\\include\\prerelease;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\PlatformSDK\\include;
c:\\program files\\microsoft visual studio .net 2003\\sdk\\v1.1\\include;
Library Includes:
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\src\\mfc;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\src\\atl;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\crt\\src;
Other Includes:
For me only certain symbols stop coloring properly. I actually had one item (STDMETHODIMP) lose color while I was scrolling, so that the symbol was colored then the the part that had scrolled off lost color leaving part of the symbol colored and part not colored. Losing focus and then switching back fixed the problem. This wasn't exactly a parsing issue (or shouldn't be because STDMETHODIMP is in stable includes). |
|
|
|
gstelmack
Ketchup Master
USA
76 Posts |
Posted - Mar 03 2004 : 09:08:37 AM
|
quote:
Originally posted by support
When the problem happens, does all coloring stop, or just certain symbols defined in the file?
Are you all using VS.NET? East Asian Languages installed? Black backgrounds? Any other clues?
In my case all advanced coloring stops, I only get the basic VS.NET coloring (e.g. comments are colored, but no members/variables/classes).
VS.NET 2003, default color settings. |
-- Greg Stelmack, Red Storm Entertainment |
|
|
|
gstelmack
Ketchup Master
USA
76 Posts |
Posted - Mar 03 2004 : 3:50:09 PM
|
| I can add a bit more. If I have a file that is colored properly, starting the debugger seems to uncolor it. If I have a file opened that is not colored, starting the debugger will color it properly. |
-- Greg Stelmack, Red Storm Entertainment |
|
|
| |
Topic |
|
Topic Locked
