| Author |
 Topic  |
|
|
tcassisi
Junior Member
14 Posts |
 Posted - Jun 05 2008 : 07:43:20 AM
|
I have been using VAX for sometime but unfortunately cannot recall if it ever supported the __declspec( property....) syntax.
NOTE: If I enable 'use content from Visual Studio Intellisense' it does partially work (colours don't) - obviously because VS supports it.
//To ease typing:
#define DECLARE_VIRTUAL_PROPERTY(ISNAME,TYPE)\ __declspec( property( get=Get##ISNAME, put=Set##ISNAME ) ) TYPE ISNAME;\ virtual TYPE Get##ISNAME(void);\ virtual void Set##ISNAME(TYPE);
class Test {
public:
DECLARE_VIRTUAL_PROPERTY(StringValue, LPCWSTR);
};
Visual Studio shows:
a) StringValue as a single property
b) Also the GetStringValue and SetStringValue are shown
VAX with content from VS shows:
a) and b)
*BUG: a red wavy line and incorrect colouring is shown for a)
VAX natively:
b) only is shown
IDEALLY:
a) VAX recognises the Property and colours correctly
b) VAX parses the Property syntax and shows ONLY the property
(Basically VS and VAX should never show the actual accessor implementations, only the single property).
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jun 05 2008 : 4:39:57 PM
|
I tried your example, but I don't see any problems here using VA 1640 and VS2008.
- the keyword "property" is blue (keyword color), and do not underlined
- StringValue is colored as a variable with the Enhanced Syntax Coloring of VAX
- I get all suggestion including StringValue, GetStringValue, SetStringValue. I keep "Get content from default Insellisense" turned off
- I do not see any underlines at all. VAX recognize StringValue, GetStringValue, SetStringValue for me, so properly colored and working ALT+G and all other features on them
The idea part: your suggestion makes sense, but GetStringValue and SetStringValue are also part of the class, so showing them is not a problem for me. Visual Studio is also showing them, so users may miss them if we remove it from VAX populated listboxes.
Which version of VA are you using?
Which version of Visual Studio are you using? |
Edited by - accord on Jun 05 2008 4:49:13 PM |
 |
|
|
tcassisi
Junior Member
14 Posts |
Posted - Jun 05 2008 : 6:42:25 PM
|
This is a very long message as I have been having intermittent problems with VAX ever since my machine was upgraded to a Quad CPU with very fast RAID 0 HDDs and I think its time I try to get them fixed.
Below I have tried your latest and then downgraded.
I have explicitly manually deleted your cache folder.
I would suggest VAX has issues in its threading support. It perhaps has issues with the initial parse of a project when you also have to parse all the C++ system includes.
At least that seems to be when it breaks down for me.
---------------
I upgraded just now from a few releases ago to the latest (see end):
After doing that I had major problems with VAX, so I closed VS, manually erased the C:\\Users\\Toni\\AppData\\Local\\VisualAssist folder and re-opened my mixed C++/Native, C++/Managed and C# solution.
I have turned off "content from Intellisense" and turned on Underline mistyped symbols in red.
To be safe, no files were opened yet; I waited for parsing to finish and restarted VS.
In my .H file, the line below is not 'mistyped' but VS does not resolve the macro via Alt-G (hovering shows the 3 lines again and not the macro definition):
DECLARE_VIRTUAL_PROPERTY(StringValue, LPCWSTR);
I open the PCH.H (precompiled header file) that includes the following line to bring in the #define:
#include "Optimisations.h"
Going back to the .H file, Alt-G does nothing on the first two ones but on the 3rd it shows the first two in the list.
I now manually open the Optimisations.h file.
No change to VAX behaviour. I.e. incorrect Alt-G drop down list and incorrect hover list.
I open up the .CPP file. (No change in VAX).
I try:
this->
I see:
a) the macro define names listed as methods (wrong)
b) I see the SetXXXXValue() and Get() (okay)
c) I do NOT see the actual Property
I retry:
<instance of my class from static method>->
And I see the same a) -> c).
I open the VAX Find Symbol dialog and only b) is shown.
Having closed the dialog, I notice that the static method in which I was adding the temporary line to check the '->' is now marking all my arguments and locals as 'mistyped'.
As I scroll around the file clicking in the methods, suddenly everything becomes 'mistyped'.
-----
I now downgrade my VAX back to the other version shown below.
Prior to opening this I manually erased the C:\\Users\\Toni\\AppData\\Local\\VisualAssist.
I recheck settings are as before.
I now repeat the same tests in the same manner:
The identical behaviour/problems are seen.
Except this time I get the "problems" I mentioned in the first line of my email. Specifically, trying to redo the test below fails because VAX does not recognise the local variable at all - and no, there is nothing unusual or odd and yes, this has happened before but sometimes corrects itself with a few retries: no such luck today.
"I retry:
<instance of my class from static method>->
"
Note that this could be related to a small difference this time around: I see the 'mistyped' stuff immediately so don't have a chance to even do the '->'.
*NOTE: I now restart VS, and this time manually request VAX to reparse the files by opening each one and using the menu to reparse in the include order:
a) Optimisations.h
b) pch.h
c) .H
This time, hovering and Alt-G work correctly. Similarly, the .CPP file is behaving without any 'mistyped' indicators.
And finally I can see the single property as well as the redundant get/set accessors.
NOTE: Please remove the get/set accessors. They are 100% redundant because the single property is mapped to them - see the MS VC extension help for this. In fact, they clutter up the class significantly taking the advantages away of using them.
-------------------
VA_X.dll file version 10.4.1640.0 built 2008.05.22
Licensed to:
VA X: [email protected] (1-user license) Support ends 2008.11.06
DevEnv.exe version 8.0.50727.867
msenv.dll version 8.0.50727.867
Font: Consolas 17(Pixels)
Comctl32.dll version 6.10.6001.18000
Windows Vista 6.0 Build 6001 Service Pack 1
4 processors
Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0\\Include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0\\Include\\gl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\include;
Other Includes:
Stable Source Directories:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\crt\\src;
------------
VA_X.dll file version 10.4.1635.0 built 2008.04.18
Licensed to:
VA X: [email protected] (1-user license) Support ends 2008.11.06
DevEnv.exe version 8.0.50727.867
msenv.dll version 8.0.50727.867
Font: Consolas 17(Pixels)
Comctl32.dll version 6.10.6001.18000
Windows Vista 6.0 Build 6001 Service Pack 1
4 processors
Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0\\Include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0\\Include\\gl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\include;
Other Includes:
Stable Source Directories:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\crt\\src;
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Jun 06 2008 : 09:10:14 AM
|
The easy answer first. When you first open a file VA does not underline anything as a mistyped symbol, even if it thinks everything in the file is a mistyped symbol. The underlining only starts after you have edited the file.
This is a performance optimisation to avoid underlining when you are simply opening and reading existing files, but not editing them.
VA is going to have some problems with the macro:
#define DECLARE_VIRTUAL_PROPERTY(ISNAME,TYPE)\
even if we ignore the __declspec part. Currently there is a known problem (limitation) with our parser and macro's that use ## to construct names:
case=729
The number of CPU's or threads are not going to effect either of these two issues. Since these are long standing points you should see exactly the same behaviour in both VA 1635 and 1640.
Clearly you are seeing quite a few problems here. What we need to try and do is pin them down so we can try and solve them.
VA should not have any problems with running on multiple CPU's. This is quite common. The only obvious concern here is if you run more than one IDE at the same time. Having multiple IDE's along side multiple CPU's might increase the changes of problems. However this does not seem likely from your description here.
If I may focus on a couple of specific points:
quote:
In my .H file, the line below is not 'mistyped' but VS does not resolve the macro via Alt-G (hovering shows the 3 lines again and not the macro definition):
DECLARE_VIRTUAL_PROPERTY(StringValue, LPCWSTR);
I have just added your test code from the first post to a .h file in my main test solution. I gave VA a couple of seconds to parse the new code, then used alt-g on the macro DECLARE_VIRTUAL_PROPERTY, and I was taken directly to the macro declaration.
I then restarted the IDE, and alt-g still works. This is using VS2005, VA 1640, and a solution that contains C++, CLR C++, VB and C# code.
Ignoring tooltips for now since they can be confusing (sometimes they are from VA, sometimes they are from the IDE) what does VA show in its context and definition fields when you place the caret into this macro call? For me the definition field shows:
#define DECLARE_VIRTUAL_PROPERTY(ISNAME,TYPE) __declspec( property( get=Get##ISNAME, put=Set##ISNAME ) ) TYPE ISNAME; virtual TYPE Get##ISNAME(void); virtual void Set##ISNAME(TYPE);
So VA knows what the macro is, even if it has problems expanding it.
quote:
Having closed the dialog, I notice that the static method in which I was adding the temporary line to check the '->' is now marking all my arguments and locals as 'mistyped'.
Does this underlining seem to be related to this macro? Or is "normal" code also being underlined as mistyped symbols?
This sounds like something further up the file is confusing VA's parser, so it thinks that everything else is a mistyped symbol.
For now I would like to ignore the question of how VA should handle __declspec since it seems we have bigger problems that should be addressed first. |
zen is the art of being at one with the two'ness |
|
|
|
tcassisi
Junior Member
14 Posts |
Posted - Jun 25 2008 : 04:11:32 AM
|
a) case=729
How can i view the details or original forum topic?
b) Alt-G on DECLARE_XXX macros does not work for me
I manually deleted the VAX cache, put in 1640, opened up a simplified pure C++ project I had created earlier and the DECLARE_XXX entries - all 3 of them in Property.h - do not respond to Alt-G.
Closing and opening VS makes no difference - this was done twice only to test, so I'm not claiming its a permanant state.
NOTE: I have emailed a zip of the project to your forums email address with the title of this forum entry.
Be careful: this problem is intermittent as you can see by my long description of steps taken earlier in the project where suddenly the issue disappeared.
c)
quote:
Does this underlining seem to be related to this macro? Or is "normal" code also being underlined as mistyped symbols?
This sounds like something further up the file is confusing VA's parser, so it thinks that everything else is a mistyped symbol.
This problem is in my main project so I have yet to isolate it. However it applies to everything and does not seem to be macro related.
What is interesting is I could be editing a short procedure (class method implemention where the class header does contain multiple uses of that macro but the class method in question is not related) and suddenly all local variables including the method arguments will become underlined in red.
An example would be any of the methods (not Set/Get/Put) within the Property.cpp file.
This is what I was (attempting) to describe in the previous long post.
Any suggestions on how to isolate this issue appreciated. |
|
|
|
tcassisi
Junior Member
14 Posts |
Posted - Jun 25 2008 : 04:36:53 AM
|
Update on c):
To replicate in the zipped project provided, open up Property.cpp and in the single function put a space after the '{' of the function.
Immediately on my machine the local arguments to the function are underlined red and right-clicking does nothing, nor does Alt-G.
Is it possible the #define being used is the problem, as I've just noticed it does NOT happen with the method implementations but only with these extern'd stand-alone functions?
|
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jun 25 2008 : 12:08:22 PM
|
> a) case=729
> How can i view the details or original forum topic?
Not all bugs reported by the forum. You cannot track bugs directly, but fixed bugs appears on this page:
http://www.wholetomato.com/support/history.asp
> NOTE: I have emailed a zip of the project to your forums email address with the title of this forum entry.
Please submit the files via the form:
http://www.wholetomato.com/support/contact.asp
including this thread ID or URL in the description, so we can match it up. This is more reliable, e-mails can stuck because of spam filters. |
|
|
|
tcassisi
Junior Member
14 Posts |
Posted - Jun 25 2008 : 1:50:40 PM
|
| Attachment submitted as instructed with topic id in subject. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jun 25 2008 : 3:53:22 PM
|
Thank you for the files, I have played a little with them, and found that you can improve this situation a lot.
First, it seems you can improve this by turning off the limited macro parsing. After that Visual Assist recognize a lot more symbols, so will not underline them, context and definition fields working, can use alt+g, etc.
The process described here:
http://docs.wholetomato.com?W363
But still there will be macros that Visual Assist will not understand. For example the DECLARE_ macros.
I tried to work out you a workaround. You can continue to improve the situation by copy and paste the DECLARE_ macros into the stdafx.h of Visual Assist, and then deleting the
__declspec lines from them. You can read about this stdafx.h here:
http://docs.wholetomato.com?W302
For example, I have tried to transform this:
#define DECLARE_VIRTUAL_PROPERTY(ISNAME,TYPE)\ __declspec( property( get=Get##ISNAME, put=Set##ISNAME ) ) TYPE ISNAME;\ virtual TYPE Get##ISNAME(void);\ virtual void Set##ISNAME(TYPE);
into this:
#define DECLARE_VIRTUAL_PROPERTY(ISNAME,TYPE)\ virtual TYPE Get##ISNAME(void);\ virtual void Set##ISNAME(TYPE);
by deleting this __declspec line, and it worked like a charm. Now goto will work on the macro, and if I create a Set or a Get function, it will be understand by VAX (I tried the traditional way to create the function, without macros) |
Edited by - accord on Jun 25 2008 3:57:12 PM |
|
|
|
tcassisi
Junior Member
14 Posts |
Posted - Jun 26 2008 : 05:27:48 AM
|
a) Please provide some further information be that a forum entry or bug description so I can understand fully the limitations
Any ideas when this will be fixed? It seems to be a long standing issue?
b) & c) with macro limit removed
Yes, it does increase the symbol list, but way too far so that it effectively "makes up" symbols.
I cleared the cache manually, turned the option on, open VS with the test project and waited.
Inside the Property.cpp file, change the function to declare two items:
CHandle* pHandle;
CProperty* pProperty;
return FALSE;
Now experiment with pHandle-> (fine) and pProperty-> to see the latter has a number of completely unrelated members such as ReadFromStream?
b) & c) with stdafx.h workaround only
This would be fine provided VAX would merge my definitions with your master ones.
Please add an HKCU registry option to Merge rather than Override, unless its there already?
Btw, I tried this as well (and had to turn on proper macro parsing as well):
#define __declspec(x,y)
However, it didn't seem to stop VAX from getting confused by a (quite common and necessary) dllimport/export scenario?
So I'm going to add this as a separate bug:
d) Unable to parse common dllimport/export macro
Specifically, this one causes the problems outlined in c) earlier:
#define TOVICA_XLNET(X) extern "C" __declspec(dllexport, nothrow) X __stdcall
e) Tooltips
Please examine the tooltips for things like UNIQUEPTR. I'm seeing comletely unrelated structures here, at least when turning macro limit off?
Finally, is it not possible to consider merging intellisense definitions with VAX's ones on a user-specified basis? Example: if I specify a symbol to VAX it will use VS's intellisense content but only for that symbol?
Just an idea but maybe there are performance implications. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jun 27 2008 : 7:43:37 PM
|
a) There are multiple issues here, so I have to figure out how to separate them.
b&c) You are seeing the entries "ReadFromStream", etc. because there is already a system class named "CProperty". Visual Assist pre-parses a lot of system files to help you with suggestions. You don't have to include a file in order to get suggestions for symbols in it (this is by design). So if you have two classes with the same name, you will get the members from both. You will find workarounds to hide one of them in this thread:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5738
About macro merging: I don't know what do you mean. Always the first macro will be used. Visual Assist parses it's stdafx.h file first, and will not overwrite the definition later, and will not get confused.
d) About TOVICA_XLNET(X): you can place
#define TOVICA_XLNET(X)
into stdafx.h of Visual Assist, and will always skip this macro later.
e) I see __restrict for UNIQUPTR. Are you seeing something different? Do you see these unrelated structures with the test project you sent?
About merging intellisense definitions: Getting definitions from default intellisense is only a workaround, and I think better to focus on fixing bugs rather than improving this workaround :) |
Edited by - accord on Jun 27 2008 7:44:31 PM |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jun 27 2008 : 7:57:21 PM
|
I believe C) is related to
case=3727 |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Sep 13 2008 : 01:11:37 AM
|
| case=3727 is fixed in build 1649 |
|
|
| |
Topic |
|
|
|
Support for __declspec( property ...)
