Author |
Topic |
|
dsternberg
New Member
5 Posts |
Posted - Apr 27 2007 : 06:40:26 AM
|
Hi, I'm using VA 10.3.1549.0 with VC6 on a project that uses the codejock toolkit (ToolkitPro1042). When the project is loaded VA begins parsing the headers and get's stuck in the toolkit headers of the calendar control. In the status line one can see that VA is parsing the same headers over and over again - increasing memory usage until VC is closed. Installed an older version of VA with no success. Still looping. I had no choice other than to deinstall VA, since the files are parsed even if VA is diabled. Besides of this bug: Is there any way to exclude directories from being parsed? If so, I will exclude the whole CodeJock toolkit from beeing seen by VA.
Regards Dieter Sternberg
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Apr 27 2007 : 10:11:22 AM
|
I am a little concerned by the statement that this happens even when VA is disabled. I would not expect it to be doing any code parsing while disabled.
I have found the website:
http://www.codejock.com/downloads/
which appears to be the right site, and installed the trial "ToolkitProEval.MFC60.v11.1.0"
Using VC6 I then added the following lines to a cpp file:
#include <Calendar/XTPCalendarADO.h>
#include <Calendar/XTPCalendarEvent.h>
Just picking a couple of the files at random from the Calendar directory. I have used alt-g to move into these files and VA is not having any problems with them. This is with VA 1555.
Have I found the right website? Can you tell me which header files seem to be causing the problem?
Do you have any other plugin's installed? |
zen is the art of being at one with the two'ness |
Edited by - feline on Apr 27 2007 10:11:40 AM |
|
|
dsternberg
New Member
5 Posts |
Posted - May 02 2007 : 06:17:45 AM
|
This seems to be a problem with CodeJock being addressed over a network share with UNC path. I've copied the whole CodeJock directory to my local computer to D:\\CodeJock Made a very simple AppWizard project and included the following line into stdafx.h: #include "D:\\CodeJock\\MFC\\Xtreme ToolkitPro1042\\Source\\XTToolkitPro.h" Loaded the project and VA parsed all files without a problem.
Then made the CodeJock dir available as a network share named "CodeJock" and changed the line in stdafx.h accordingly: #include "\\\\DSt-nb\\CodeJock\\MFC\\Xtreme ToolkitPro1042\\Source\\XTToolkitPro.h" Upon loading the project, VA runs into a loop constantly parsing the following files: XTPCalendarUtils.h XTPCalendarRecurrencePattern.h XTPCalendarDefines.h XTPCalendarEvent.h Order of files may vary.
Hope that helps.
>I am a little concerned by the statement that this happens even when VA is disabled. >I would not expect it to be doing any code parsing while disabled. I've thought, disabling VA would be persistent (which it isn't). Sorry.
Regards Dieter Sternberg
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - May 02 2007 : 10:00:54 AM
|
*ah* now I recognise this. This is currently a known problem, but until now we have only had it reported when accessing files from a Linux machine:
http://docs.wholetomato.com?W316
Out of interest is the machine \\\\DSt-nb\\ running some form of Linux, or is it a windows machine? |
zen is the art of being at one with the two'ness |
|
|
dsternberg
New Member
5 Posts |
Posted - May 02 2007 : 11:12:15 AM
|
\\\\DSt-nb\\ is a Dell notebook running WinXP Pro SP2. It's member of a domain. No sort of Samba Server or Linux or other UNIX derivates are involved. Everything is running local in the afore mentioned example. Just accessing CodeJock via a share on the same machine. Well, I've removed the network cable now and VA is still looping but there seems to be more files involved now. Killed msdev.exe after it consumes more than 1GB of memory usage. Strange...
Regards |
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - May 02 2007 : 12:24:49 PM
|
Are all paths local? If I understand correctly you are now seeing this problem without any \\\\machine_name\\ path's involved, in which case this is a different problem.
Have you used subst to map any local drive letters to specific directories? I am wondering if something "odd" is happening, or if this is purely down to something in the code confusing VA's parser. |
zen is the art of being at one with the two'ness |
|
|
dsternberg
New Member
5 Posts |
Posted - May 02 2007 : 12:48:53 PM
|
The line in stdafx.h is still #include"\\\\DSt-nb\\CodeJock\\MFC\\Xtreme ToolkitPro1042\\Source\\XTToolkitPro.h" but \\\\DSt-nb\\CodeJock is a share that points to D:\\CodeJock on the same machine. Simply in windows explorer right mouse on D:\\CodeJock then share folder as CodeJock. The network cable is unplugged, so no external network stuff in involved now.
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - May 02 2007 : 6:03:24 PM
|
Which OS are you running? I am trying to setup a suitable test system here. |
zen is the art of being at one with the two'ness |
|
|
dsternberg
New Member
5 Posts |
Posted - May 03 2007 : 03:53:40 AM
|
XP Professional SP2 with the latest updates.
I've played around again a bit. In some rare cases VA indeed completes parsing, sometimes it get's stuck in the Calendar directory. Seems, this depends on the "Rebuild Database on Project load" setting. If it rebuilds the DB it get's stuck always. However if it completes, it uses a lot of memeory, 265MB for my little project. |
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - May 04 2007 : 3:38:09 PM
|
I am seeing the same effect here. I needed the network card enabled for this to work, if I disabled it the machine would not let me access the files via the share.
case=6396
For now the work around is to map a drive letter and use that instead of the \\\\machine_name\\ path. |
zen is the art of being at one with the two'ness |
|
|
support
Whole Tomato Software
5566 Posts |
Posted - May 31 2007 : 12:49:17 AM
|
fixed in build 1557 |
|
|
|
Topic |
|