| Author |
 Topic  |
|
|
domwise
New Member
United Kingdom
6 Posts |
 Posted - Sep 10 2004 : 08:51:01 AM
|
I have almost reached the end of my trial period of VA X and recently activated the product. Using the activated version (NOT the trial version) I get a problem whereby every 1/2 second to 1 second my IDE (VS.NET 2003 on XP SP1) stalls whenever the mouse or keyboard is used. This behaviour occurs in every context, not just within the text editor. For example, if I open a menu and hold down the down arrow key, the selected menu item changes a few times, then pauses for a bit then moves some more.
I need to get this resolved as it undoes any productivity gains offered by VA X and my only recourse is to revert to the trial version, which for me expires in 2 days. I have looked in the forums but cannot see anything that clearly relates to this issue.
I have no other VS.Net Add-Ins and am running on a 966MHz PIII with 512MB RAM.
I am aware that to ensure that a license is not accidentally exceeded, VA (at some point) scans the local subnet to check for other installations of VA. Could it be that this scan is happening every 1/2 second once the product is activated ?
Product details below:
VA_X.dll file version 10.0.1246.0
Licensed to:
VA X:
VA.NET 7.1:
VAOpsWin.dll version 1.0.0.44
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: Courier New 13(Pixels)
Comctl32.dll version 5.82.2800.1106
WindowsNT 5.1 Build 2600 Service Pack 1
Single processor
Platform:
Stable Includes:
c:\\program files\\microsoft visual studio .net 2003\\sdk\\v1.1\\include;
Library Includes:
Other Includes:
|
|
|
domwise
New Member
United Kingdom
6 Posts |
Posted - Sep 23 2004 : 06:22:59 AM
|
I have looked into this further and it looks as if the problem is related to SourceSafe integration of Developer Studio interacting with the licensed version of Visual Assist. The following explains my reasoning and may provide a means of reproducing the problem.
When the IDE is opened without any solution file opened all is well. While I only use projects without SourceSafe integration (all projects I have tried are VC++) everything works OK.
HOWEVER.... As soon as I open up a project (again, VC++) integrated with a SourceSafe database on a REMOTE machine then the problem appears and will not go away until I close the IDE. I have tried SourceSafe databases on two different remote machines (both on the same subnet as my PC) with the same result. Also, I have tried with a LOCAL sourceSafe database but here the problem does NOT occur.
The version of SourceSafe installed on my machine is 6.0c (Build 9238) I don't have any firewall softare running.
In the mean time, thanks must go to support for providing me with a temporary workaround |
Edited by - domwise on Sep 23 2004 06:24:50 AM |
 |
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Sep 23 2004 : 06:45:16 AM
|
Of course lots of people use VSS and VA. It isn't usually a problem. Have you got some unusual VSS settings? There's nothing that makes VSS do something every second, is there? (I thought it was only active when you deliberately queried the database).
Does the problem go away if you stay connected to the VSS database but disable VA (from the VA menu)? |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
WannabeeDeveloper
Tomato Guru
Germany
775 Posts |
Posted - Sep 23 2004 : 07:28:33 AM
|
I might be wrong here, but isn't VSS 6.0d the version known to be working with VS .NET 2003?
quote:
This service pack upgrades all previous installations of Visual SourceSafe 6.0 to 6.0d (Build 31222), fixing known issues such as automation incompatibilities in 6.0d (Build 9848). This update is recommended for all users of Visual SourceSafe 6.0, including those also running Microsoft Visual Studio .NET or Microsoft Visual Studio .NET 2003. The service pack also addresses known issues in Visual Basic 6.0 and Visual C++ 6.0.
Here's the Link:
http://msdn.microsoft.com/vstudio/previous/ssafe/
|
 |
|
|
|
domwise
New Member
United Kingdom
6 Posts |
Posted - Sep 23 2004 : 11:11:00 AM
|
The response from Stephen got me thinking about our SourceSafe configuration. We have two VSS add-ins that we use here, one written by us and the other by our parent company. It turns out that the one written by our parent company, though installed by default can be removed without losing much in the way of day-to-day functionality and doing this resolves the problem. The one written by us does not cause the problem.
I guess this explains why nobody else has seen this problem before and I have requested the source code in order that we can investigate and hopefully fix the incompatibility. Why it should only occur once VA X has been activated is a mystery I hope to get to the bottom of.
Thanks to everyone who has contributed to me getting to the stage where we now have a workable solution to the problem. If I do get the Source Code and work out what's going on I'll put the results up here for anyone interested
|
|
|
|
support
Whole Tomato Software
5566 Posts |
|
|
rblondeau
Tomato Guru
Canada
102 Posts |
Posted - Sep 23 2004 : 11:52:20 AM
|
| If I remember correctly, I thought I read somewhere that Microsoft goofed up a bit with VSS's version numbers. I could have sworn that when you download the latest version of VSS (which should have been 6.0d), you actually get 6.0c. |
|
|
|
domwise
New Member
United Kingdom
6 Posts |
Posted - Sep 29 2004 : 11:26:10 AM
|
A possible explanation ?
I have looked into this problem (much) more closely and it turns out that one of the VAX threads, I think one involved in scanning the network for other instances of VAX (because it has a window with the title "Socket Notification Sink") is sleeping periodically for 250ms. Under normal circumstances this is fine but if a thread calls EnumWindows with a function that calls GetWindowText (or any function that results in a message being sent to a window being enumerated) then it must wait for the thread that owns the window to call a function (such as GetMessage) that enables the message to be processed. Clearly if the target thread is in a sleep state this cannot happen until the sleep is finished.
It looks like this this is exactly what is happening with the problem SourceSafe add-in that I mentioned because when the add-in is activated in Visual Studio.Net, by opening a Solution held in SourceSafe, it tries to identify the top-level window of the application (VS.NET). It does this by calling EnumWindows once a second until it finds it (which it doesn't when running in VS.NET). Each time this happens, EnumWindows identifies "Socket Notification Sink" as a top-level window, and passes its handle to the enumeration function which calls (unnecessarily, as it happens) GetWindowText, resulting in the stalling described.
Admittedly our add-in probably ought not be working in this way but it seems to me that if the Sleep call is in VAX code (rather than MFC) it could (and probably should) perhaps be replaced by a Windows Timer and this would probably make my problem go away.
The above conclusions have been reached by judicious use of spy and the VS.NET debugger and may be completely wrong, but the explanation seems plausible so I thought I would pass it on.
|
Edited by - domwise on Sep 29 2004 11:29:15 AM |
|
|
| |
Topic |
|
Topic Locked
