| Author |
 Topic  |
|
|
joracine
Senior Member
36 Posts |
 Posted - Jul 08 2008 : 08:35:00 AM
|
Good morning,
I encounter, fairly regularly, this problem when I write, in my header (C++), the prototype for a (some) method(s). It seems those methods just won't register as such. So when I try to refactor/document or refactor/implement, it won't work.
Attached is a screenshot of what I am talking about: notice the RegisterDocManager and UnregisterDocManager methods which we're not detected as methods by VAX.
(Sorry if the screenshot is limited, but it's proprietary code...)
I don't know how to reproduce it exactly but I'll be glad to give you more information if you need it.
VS Version: 8.0.50727.864 (vsvista.050727-8600)
OS: Vista 64
VAX: 10.4.1640.0 built 2008.05.22
Thanks! |
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 08 2008 : 08:40:50 AM
|
Update:
- It seems to be related to the return type of the method being bool. If I change bool for int/void/anything in any of the two methods, they are detected as methods.
- The position of the declaration has no importance.
- The fact that there are two does not change anything.
- I tried to document the InitializePlugins() method above and couln't, unless I changed the return type...
- Eventually, the color of the methods changed but I still can't do any operations on them and they are underlined as errors in the .cpp file.
- Closing and restarting VS or reparsing file does not fix the problem. |
Edited by - joracine on Jul 08 2008 09:08:55 AM |
 |
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 08 2008 : 3:05:22 PM
|
If you show VA Outline does it list the problem functions correctly?
The fact that reparsing the file does not fix the problem bothers me.
Are you using a lot of macro's in this header file?
Is this a localised OS? I am wondering if you have non English characters in the file
Is the file stored on a local drive, or some form of network drive?
I am looking for anything "odd" that might explain these problems. |
zen is the art of being at one with the two'ness |
|
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 08 2008 : 3:56:00 PM
|
Outline: Yes, it does show it.
Macros: Not, not really. A few forward declarations and two includes, plus the classic ifndef wrapping. Class is exported with a (simple) macro, but that's all.
Localized: No, it's a US English Vista 64. I looked quickly in the comments and it doesn't look like there's any accents of any kind (still, we are in Quebec so it could have happened but no).
Storage: On a local drive ):
- I'd really like to put the emphasis on the 'bool' return type... It really, really seems to be related to that.
- Even if I go to previously defined method that has a bool return type and are of the "method color", I still can't refactor them. So it's really a whole file problem where the mis-coloring is only applicable to newly written methods.
- I tried removing all includes and the export macro, saving, reparsing and still same behavior.
Important note: I have deep macro enabled |
Edited by - joracine on Jul 08 2008 4:08:24 PM |
|
|
|
Dany
Senior Member
Germany
41 Posts |
Posted - Jul 09 2008 : 01:25:05 AM
|
| The last time I had a similar effect in C# I just cleared the "History, cache and temporary files" of VAX (1640), which corrected the problem... And it where enum return types and int parameters. |
Dany
// using VAX in C# of VS2010 SP1 (en), Win 7 SP1 (de)
|
|
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 09 2008 : 11:48:08 AM
|
I just tried, no luck. And I just created a completely new class and it happened again. Here's the code:
/**
* \\file Project HumanCAD Project File (hcadx) Wrapper Public Header File
*
* Copyright (C) 2003-2007 NexGen Ergonomics Inc.
*
* $Id$
* $Author$
* $Revision$
* $Date$
*
**/
#ifndef _NEXGEN_CORE_PROJECT_H
#define _NEXGEN_CORE_PROJECT_H
namespace nexgen
{
namespace core
{
/**
* \\class Project Project
* \\brief HumanCAD Project File (hcadx) Wrapper Interface Class.
* \\ingroup core
*
* The hcadx wrapper class is responsible for handling access to the
* project file in a uniform and manner. It is a wrapper that hides
* the complexity of the file format.
*/
class Project
{
public:
/**
* Default constructor.
*
* Access: public
**/
Project();
/**
* Default destructor.
*
* Access: public
**/
~Project();
bool LoadProject();
bool CreateProject();
protected:
private:
};
} // namespace core
} // namespace nexgen
#endif
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 09 2008 : 6:53:17 PM
|
If you open this file on its own, with no solution open in the IDE, do you still see the problem?
I have tried creating a new header file, and copy / pasting this code into it, and the two functions are coloured correctly for me. I am wondering if something else in your solution is a factor. |
zen is the art of being at one with the two'ness |
|
|
|
Dany
Senior Member
Germany
41 Posts |
Posted - Jul 10 2008 : 01:39:01 AM
|
joracine, I copied and pasted your example into a file named t.hpp. Opening VS2005 (without a solution) and dragging the file into it, (almost) all the text was black (except for the keywords and comments). VAX started to scan the include directories, because I'm using mainly C#. While scanning I typed in some other methods where x() went gray, a() in italics orange (orange is my setting for methods, though not italics), all the rest stayed in black letters (the strange coloring may come from the VS headers). Fields where shown italics gray.
After closing VS (it was the first run today) and reopening without solution, dragging the unchanged t.hpp into the empty workspace just showed the correct highlighting (de-/constructor in blue, methods in orange)! I don't know what is happening here, but this seems very strange, as if VAX has been loaded just halfway through.
My experience in C# is, that running VS2005 after system start an opening a solution leaves some VAX features turned off. I mean the button bar on popup boxes (suggestions) to filter for class, enum etc. is missing. Also the shortcut suggestions are not working then. Though coloring works. Only closing VS and reopening it after some seconds corrects this problem.
feline, I hope this helps you somehow?
Edit:
I tried it again after a reboot. Now even the first start does the correct coloring. I performed another reboot, after I cleared the history and cache of VAX. Again VAX is parsing the VS headers and the methods are black! When VAX finishes, the contents stay as they where. Clicking on the VAX button "Reparse Current file", shows "VA X: Parsing \\\\share\\path\\t.hpp" until I change to the "Start Page" tab, but without the desired effect of coloring correctly. Closing the temporary solution and opening t.hpp again has no effect on coloring. I opened a C# solution and checked for the suggestions, with the same "broken" VAX functionality as described above. But here, after parsing C# the coloring is fine at least. Closing VS and reopening shows the correct coloring in t.hpp.......
Sorry for the plenty of text here, but I wanted to share my experience in this case.  |
Dany
// using VAX in C# of VS2010 SP1 (en), Win 7 SP1 (de)
|
Edited by - Dany on Jul 10 2008 01:58:07 AM |
|
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 10 2008 : 09:51:24 AM
|
Thanks Dany for you support ;)
Feline:
I tried and, as you (and I) expected, it works fine. So I went and looked in the other project, and noticed that the problem is generalized: bool returning methods all have the same symptoms. But to my surprise, I have found void methods that exhibit the same behavior!
Any clue what in the solution could cause that?
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 10 2008 : 10:56:26 AM
|
Dany it sounds like you are seeing other problems as well. VA has to finish rebuilding its symbol database before it can apply enhanced syntax colouring to your code. So an initial delay before any colouring appears is normal.
Sometimes after the symbol database has been rebuilt you need to change files or at least make sure keyboard focus has been placed into the editor before syntax colouring is applied. This might explain some of what you have seen here.
VA features being turned off when you first open a C# solution sounds like a totally different problem, and is not one that I recognise. Can you start a new thread for this problem please?
joracine since this is solution specific my first thought is that something in your solution is redefining "bool" and "void".
Can you look in your registry please and see if parsing for macros calling macros has been turned on as described in this FAQ entry:
http://docs.wholetomato.com?W363
On one of these problem functions if you place the caret into the return type what does VA show in the context and definition fields? What, if anything, does alt-g do?
If you change the function name to a random string, e.g.
bool kjhrsejkhre98797fhsfjkhsjfkhsdf();
is it now coloured correctly? It is possible the problem is the function names themselves, and not the return type, or some combination of the function names and the return type. |
zen is the art of being at one with the two'ness |
|
|
|
Dany
Senior Member
Germany
41 Posts |
Posted - Jul 11 2008 : 02:06:14 AM
|
feline, I opened a new thread (topic 7988), but after rebuilding the cache the missing VAX features after a reboot went away for now. 
For the coloring problem, I tested some random named methods even without giving an explicit return type (e.g. xxxxxxxx(); or ljkasdghf();) which stayed black until the second start of VS, where they are colored correctly...
|
Dany
// using VAX in C# of VS2010 SP1 (en), Win 7 SP1 (de)
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 11 2008 : 1:25:03 PM
|
It does sound like some form of VA symbol database problem was behind the problem you were seeing. Most odd.
We are hoping to post a new build of VA in the next few days which may help, depending on what is causing these problems. |
zen is the art of being at one with the two'ness |
|
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 11 2008 : 2:46:06 PM
|
Questions
- It has nothing to do with th name of the method
- Yes, deep macro parsing is enabled as stated before.
- Alt-g does not work
- I don't think bool is redefined since when I right click on bool, I do not get "goto def/decl".
Please read carefully the tests I've done since I have put a lot of time in this:
Test:
1. I create a new solution.
2. Create a new project in it. Add a few new classes/files.
3. Save everything. Closed Visual Studio. Open Visual Studio. I *don't* have the bug.
NOTE: The project dependencies (libs) are wxWidgets
4. I add a new, blank project, using the wizard (empty project).
5. Save everything. Close Visual Studio. Open Visual Studio. I *have* the bug.
NOTE: The newest project is completely empty.
6. I remove the project.
7. Save everything. Close Visual Studio. Open Visual Studio. I *don't* have the bug.
The interesting part:
8. I move the (empty) project to another directory.
9. I add the project to the solution.
10. Save everything. Close Visual Studio. Open Visual Studio. I *don't* have the bug.
NOTE: I have VisualSVN installed. I uninstalled it and it did not solve the problem. |
|
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 11 2008 : 4:20:10 PM
|
This is clearly a VA cache problem. If I reset symbols, wait for VA to reparse, then try to document a problematic method, it works.
But I can't do it twice! If I move my cursor on the method to implement (or document again), it won't work anynmore and it's never going to until I Reset the symbols table again, And once I did a single document, all the bool returning methods in the class are "broken". |
|
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 11 2008 : 5:09:54 PM
|
Ok. Got the exact problem. In wxWidgets, you can find, in defs.h:
#if defined(__VISUALC__) && (__VISUALC__ == 1010)
typedef unsigned int wxbool;
#define bool wxbool
#endif
Now, this is for legacy code and is not used. But yet Visual Assist interprets it. I know Visual Assist doesn't know what is or what isn't defined, so what can I do about this?
|
Edited by - joracine on Jul 11 2008 5:10:56 PM |
|
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 11 2008 : 5:13:56 PM
|
| I've limited Deep Macro Parsing and it did fix the problem. Arrrgh! I'm pissed. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 14 2008 : 09:29:32 AM
|
I am glad you have found the problem.
One specific comment, you said:
- I don't think bool is redefined since when I right click on bool, I do not get "goto def/decl".
These right click commands come from the IDE, and have nothing to do with VA. So these might be disabled while alt-g still does something.
Do you need deep macro parsing turned on? If so then commenting out the problem #define in wxWidgets should help. Alternatively adding:
#define bool bool
to VA's "StdAfx.h" file as explained in this FAQ entry:
http://docs.wholetomato.com?W302
might help. I am not sure how this definition and the deep macro parsing will interact. |
zen is the art of being at one with the two'ness |
|
|
|
joracine
Senior Member
36 Posts |
Posted - Jul 14 2008 : 09:45:18 AM
|
Yes, I need deep macro (don't remember why exactly, but I know I turned it on for a good reason).
I'm glad you understood I wasn't pissed against you ;p Because I re-read the post and it wasn't that clear. I was pissed at the time wasted.
I'll try to stdafx trick, since it seems to be the best solution. Thanks for you help and patience.
I suggest you add to your notes that wxWidgets cause that problem, might be simpler for others/you who encounter this problem.
Thanks again! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 16 2008 : 2:08:12 PM
|
| I have added a note about this to the FAQ item. This is not the first time I have seen this cause problems. |
zen is the art of being at one with the two'ness |
|
|
|
beylevem
Tomato Guru
102 Posts |
Posted - Jul 16 2008 : 5:52:17 PM
|
Can I add my voice to the plea for improved macro parsing. I too turned deep macro parsing on in an effort to improve things and got bitten by the same problem with wxWindows. It was only by accident that I found this post.
Also, as part of the FAQ, can we please state explicitly the rules for macro parsing:
* If VA comes acroos multiple definitions for a macro in the same file, which one does it use?
* If VA comes across a macro definition in the same file as the macro usage, but there is also a definition in a different file, which one does it use?
If you use a macro to create accessor functions, does the ordering of the functions matter? e.g.
#define ACCESSOR_FUNCTIONS (varType, varName) \varType* get##varName() {return hidden##varName; } \void put##varName(varType* v) { hidden##varName = v; } \varType* hidden##varname;
Does the ordering matter if one susequently wants to type
getVar1()->
and have the dropdown populated correctly?
If one includes a file inside a class definition, how can one get the best parsing from VA? For instance
file1.h:
class Class1 : public Base1 {
#include "file1.inc"
};
file1.inc:
ACCESSOR_FUNCTION(Type1, Var1)
ACCESSOR_FUNCTION(Type2, Var2)
My current approach is to wrap it as follows:
#ifdef FOOL_VA
class Class1 {
#endif
ACCESSOR_FUNCTION(Type1, Var1)
ACCESSOR_FUNCTION(Type2, Var2)
#ifdef FOOL_VA
};
#endif
Should I list the base class or not? Is there a better way? And no, putting everything in the stdafxva.h is not a realistic option.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Jul 17 2008 : 10:13:45 AM
|
Unfortunately I do not have good, general answers to these questions.
Normally VA will pick up and use the first macro definition it finds. This is an easy statement to make, but as soon as a macro is defined in more than one file it runs into problems.
VA has problems with ## in macros to generate names, this is a known problem:
case=729
and we are hoping to improve support for this.
Improving support in general for macro's, once people start using #ifdef statements it is fairly easy to produce macro code that VA has virtually no chance of properly understanding. |
zen is the art of being at one with the two'ness |
|
|
|
beylevem
Tomato Guru
102 Posts |
Posted - Nov 26 2008 : 09:27:37 AM
|
| Is there any projected timeline for fixing case 729? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Nov 28 2008 : 08:42:48 AM
|
Unfortunately there is no progress to report on this. It is down as a high priority bug, but macro's are a complex subject.
It is "easy" for the compiler, since the pre-processor just expands all of them. Unfortunately VA does not have that luxury. Before you suggest doing so, #ifdef statements where VA does not know which version is active rather complicate matters.
Sometimes it is possible to help VA by adding dummy helper macros to VA's StdAfx.h file, showing how certain common macro's are expanded.
http://docs.wholetomato.com?W302
http://docs.wholetomato.com?W310 |
zen is the art of being at one with the two'ness |
|
|
| |
Topic |
|
Methods not detected as methods
