| Author |
 Topic  |
|
|
Ivan A. Fotan
Ketchup Master
Ukraine
67 Posts |
 Posted - Apr 26 2007 : 07:34:43 AM
|
Maybe anyone can explain troubles with syntax coloring?
into member function definition I have:
void CalcItemRects(DPDFR_Bookmark *pItem, LONG x, LONG y, CRect &rcToggle, CRect &rcIcon, CRect &rcText);
----
Info: VS 2005 (without SP1); VAX 1553; 1554 |
IAF |
Edited by - Ivan A. Fotan on Apr 26 2007 07:36:28 AM |
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Apr 26 2007 : 08:24:46 AM
|
What do the colours mean? Is this green colour the colour you have set for functions? Or is it the colour for something else?
If you place the caret in "CalcItemRects" and "pItem" and look at what VA is showing you in the context and definition fields does this give you any clues? If VA is confused over what these items are then this can lead to incorrect colouring. |
zen is the art of being at one with the two'ness |
 |
|
|
Ivan A. Fotan
Ketchup Master
Ukraine
67 Posts |
Posted - Apr 26 2007 : 08:33:02 AM
|
I'm used default color scheme of the VA, so, sorry, green should be gray (just there are no gray color into availables colors on the forum). And option "Local symbols in Bold" is turned on.
When I set caret:
- on CalcItemRects -- VA is showing function definition
- on pItem -- shows nothing
- on x or y -- shows '#' symbol
- on the rest arguments -- shows nothing |
IAF |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Apr 26 2007 : 09:59:51 AM
|
Are you calling the function here?
Is this a declaration?
Something is clearly confusing VA quite badly, but what?
As an initial test I added the following code to a cpp file, using VS2005 and VA 1554:
class DPDFR_Bookmark {};
static void CalcItemRects(DPDFR_Bookmark *pItem, LONG x, LONG y, CRect &rcToggle, CRect &rcIcon, CRect &rcText);
which produces:
Here I have changed the colour for functions to Orange, and I have a very pale blue as my global background colour. The colouring is exactly as I would expect for this function declaration. |
zen is the art of being at one with the two'ness |
|
|
|
Ivan A. Fotan
Ketchup Master
Ukraine
67 Posts |
Posted - Apr 26 2007 : 1:01:30 PM
|
There are two screenshots which can explain you a lot of troubles with VAX. And this troubles constantly reproduced with all builds (not necessary in the same file, but in the project every time you can find a file which doesn't handled correctly by VAX; maybe it is a time to stop adding new features and start fixing base bugs?)
First one -- it is a class declaration and on it you can see common troubles with END_MSG_MAP macros.
On second you can find a lot of troubles. Just one of them outlined...
 |
IAF |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Apr 27 2007 : 12:04:52 PM
|
Most of what we do is fixing bugs. The problem here is going to be reproducing these bugs, that is always the first step.
Where do:
BEGIN_MSG_MAP(...)
END_MSG_MAP()
come from? The pair I am used to seeing is:
BEGIN_MESSAGE_MAP(...)
END_MESSAGE_MAP()
Both of which are being correctly coloured for me.
In the second screen shot what colour should functions be? Most of the functions are grey while a few are a dark red colour. |
zen is the art of being at one with the two'ness |
|
|
|
bugfix
Tomato Guru
Germany
324 Posts |
Posted - Apr 27 2007 : 1:17:49 PM
|
They come from WTL. No sane one uses MFC these days:)
Things get even worse if you use BEGIN_MSG_MAP_EX (from atlcrack.h), seems like something totally freaks out VAX parser. For me after some mins of work alt-g is completely broken and then I have to restart IDE (vs2003 sp1). |
http://www.mf-sd.de |
|
|
|
Ivan A. Fotan
Ketchup Master
Ukraine
67 Posts |
Posted - Apr 28 2007 : 10:51:37 AM
|
You wrote: "Most of what we do is fixing bugs". But looks like your developers during developming VAX don't uses it into their environment.
Just few bugs which can be reproduced into ANY build:
1. in most cases when I try to enter "return" or "break" keyword, VAX propose me anything exept I need. Yes, you say it depends of what was entered before, BUT I can warranty it is not true.
2. similar situation with "#pragma once". Insteed of "once" I can get anything, but not what I need.
3. as addition to point 2, #pragma doesn't handled correctly at all. When I trying to enter "#pragma comment(lib, "...")", into "" I can get anything...
4. Another area: when you try to disable VAX via "Tools -> Add-in Manager" all opened files will be closed. Here I'm not sure where bug is -- into the IDE or VAX, but looking at other bugs of VAX I cannot be sure...
I'm afraid I can continue this list with a lot of items. Just please ask your developers just to use product into REAL situation. I'm developer and know that in most cases we don't see problems into our products while have no reports from users, because we are thinking as developers...
In real your product is great, but on main opinion it is a time to fix some critical bugs which makes, sometimes, your tool 'bottleneck' in developming because a lot of developers like to use it.
Best |
IAF |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Apr 30 2007 : 10:36:56 AM
|
One problem at a time. The colouring of BEGIN_MSG_MAP() and END_MSG_MAP().
Let us start by me stating I have a copy of WTL sitting on a hard drive, and I can just about find the directory it lives in. Do not assume I know anything else about it. bugfix, I don't use MFC (yet) but I can talk to you about Qt if that helps prove my sanity 
I have done a find in files for "BEGIN_MSG_MAP" across my WTL 7.5 directory tree. The closest I can find to a definition is inside the file:
C:\\WTL75\\include\\atlcrack.h
I have the block starting:
#define BEGIN_MSG_MAP_EX(theClass) \\
Note this is the "_EX" form. It seems that BEGIN_MSG_MAP is never defined inside WTL. If it is never defined then it is a bit unfair asking VA to colour it correctly.
bugfix I seem to recall you posting recently that you had done something about WTL, involving VA's stdafx.h file, and that this fixed your alt-g problems. I don't remember the details off hand, but I do have this memory.
Does that fix still work? Is the problem you are seeing with this macro related or a different problem?
Do you have a test project that shows the problem? |
zen is the art of being at one with the two'ness |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - Apr 30 2007 : 10:51:59 AM
|
quote:
Originally posted by Ivan A. Fotan
You wrote: "Most of what we do is fixing bugs". But looks like your developers during developming VAX don't uses it into their environment.
When I get to do development work I can assure you that I use VA *all* of the time, and that I stopped being able to program effectively without it many years ago.
I think it is safe to say that all of our developers work with VA enabled.
I suspect, especially given some of what is going on in this thread, that some of these problems only show up under specific conditions. E.g. using WTL. If we are not using these libraries, or working in this way, we will never see these particular problems.
VA has quite a number of bugs, I know this, proving this is a large part of my job, but it still does a LOT correctly.
quote:
Originally posted by Ivan A. Fotan
1. in most cases when I try to enter "return" or "break" keyword, VAX propose me anything exept I need. Yes, you say it depends of what was entered before, BUT I can warranty it is not true.
By default there should be an autotext shortcut for "return", and one for "break" can easily be added if it does not exist. So you type "r" or "re" and VA will suggest "return".
Is autotext enabled on your machine? Are you seeing these suggestions or not?
Hard coding suggestion listboxes to give keywords priority is likely to upset people, and also trigger a debate over the nature of "keywords", since what happens with types, or other things? My initial answer is that this is exactly what autotext is designed to do.
quote:
Originally posted by Ivan A. Fotan
2. similar situation with "#pragma once". Insteed of "once" I can get anything, but not what I need.
This is a known bug:
case=373
From my testing notes on the bug, testing in VA 1428 (which contains a partial fix) "still able to reproduce with 1428, but much harder. works correctly in the first 5 files i tried, but failed in the 6th file, leaving me with:"
quote:
Originally posted by Ivan A. Fotan
3. as addition to point 2, #pragma doesn't handled correctly at all. When I trying to enter "#pragma comment(lib, "...")", into "" I can get anything...
I don't understand what you mean. using VS2005 and VA 1555 I have just typed in the line:
#pragma comment(lib, "...")
without any problems at all.
quote:
Originally posted by Ivan A. Fotan
4. Another area: when you try to disable VAX via "Tools -> Add-in Manager" all opened files will be closed. Here I'm not sure where bug is -- into the IDE or VAX, but looking at other bugs of VAX I cannot be sure...
Quoting from FAQ: http://docs.wholetomato.com?W306
>> In Visual Studio 2005 you cannot use the Add-in Manager to stop Visual Assist X loading at startup. This is a design decision by Microsoft.
You should not be seeing that problem, but unfortunately there is no point visiting that dialog, since it is never going to do what you want in VS2005. Based on your posted screen shots you are using VS2005.
quote:
Originally posted by Ivan A. Fotan
I'm afraid I can continue this list with a lot of items. Just please ask your developers just to use product into REAL situation. I'm developer and know that in most cases we don't see problems into our products while have no reports from users, because we are thinking as developers...
In real your product is great, but on main opinion it is a time to fix some critical bugs which makes, sometimes, your tool 'bottleneck' in developming because a lot of developers like to use it.
We do, day in and day out, but our real situation is writing VA. It is quite likely that this does not have much in common with what is happening when you are working.
I spend a LOT of time working with VA, in various IDE's, putting it under all sorts of stresses, and I never run into most of the syntax highlighting bugs your screen shots show. So something is going on that we are not expecting, but what? |
zen is the art of being at one with the two'ness |
|
|
|
bugfix
Tomato Guru
Germany
324 Posts |
Posted - Apr 30 2007 : 11:16:23 AM
|
quote:
Originally posted by feline
bugfix, I don't use MFC (yet) but I can talk to you about Qt if that helps prove my sanity
sure does, but it wasnt targeted at you:) just general talk.
quote:
I have done a find in files for "BEGIN_MSG_MAP" across my WTL 7.5 directory tree.
oops, my bad. its from ATL (atlwin.h) comes w/ VS.
quote:
bugfix I seem to recall you posting recently that you had done something about WTL, involving VA's stdafx.h file, and that this fixed your alt-g problems. I don't remember the details off hand, but I do have this memory.
Does that fix still work?
i've had modified VAs stdafx.h so it doesn't jump to MFC stuff as MFC and WTL often uses same class names which seems to cause problems. meanwhile i've coded my own vs addin that blocks VA from accessing certain files:)
LPCSTR filterList[] =
{
".*\\\\\\\\afx.*\\\\.((h)|(inl))$", // all mfc headers and inlines
".*\\\\\\\\mfc\\\\\\\\.*", // all other mfc stuff
".*\\\\\\\\VisualAssist\\\\\\\\vs7\\\\\\\\history\\\\\\\\.*",
".*\\\\\\\\VisualAssist\\\\\\\\vs8\\\\\\\\history\\\\\\\\.*",
0
};
one major problem is http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5774
though that isnt just a WTL/ATL problem. (*bump*)
quote:
Is the problem you are seeing with this macro related or a different problem?
Do you have a test project that shows the problem?
yes, coloring is just wrong and in case of BEGIN_MSG_MAP_EX is breaks completely alt-g after some while. |
http://www.mf-sd.de |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - May 01 2007 : 09:00:46 AM
|
I have bumped the priority on case=4249 for you
I remember this infamous plugin, technically a very elegant solution
Sanity, part of my work is support, not automatically the sanest choice for a programmer *rolls eyes*
If you are able to reproduce the alt-g problems on demand can you start a new thread for that? Clearly something is going on here that needs looking into.
Ivan, given bugfix's help I have added the following bit of code to a header file:
Now I do not expect this to compile, but notice that both macro's are coloured correctly, and that both are shown in italic. If you turn on:
VA Options -> Advanced -> Fonts and Colors -> Stable symbols in Italic
are either of these macro's shown in italics for you?
where does alt-g on these macro's take you? For me:
BEGIN_MSG_MAP() goes to "C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\include\\atlwin.h", line 2308
END_MSG_MAP() goes to "C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\include\\atlwin.h", line 2465 |
zen is the art of being at one with the two'ness |
|
|
|
bugfix
Tomato Guru
Germany
324 Posts |
Posted - May 01 2007 : 09:50:03 AM
|
quote:
Originally posted by feline
I have bumped the priority on case=4249 for you
thx!
quote:
I remember this infamous plugin, technically a very elegant solution
that was the old the solution, now its really an addin. not just some modfied vax files:)
quote:
If you are able to reproduce the alt-g problems on demand can you start a new thread for that? Clearly something is going on here that needs looking into.
Unfortunately I haven't found a way to reproduce it. I might take a closer look when I have more time. For now I've converted my files to use BEGIN_MSG_MAP instead of _EX version.
I wonder what causes this problem, basically all my files look like this:
Same problem as Ivan. |
http://www.mf-sd.de |
Edited by - bugfix on May 01 2007 10:00:46 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - May 01 2007 : 2:37:57 PM
|
*ah* are you using any other addin's?  I am wondering if some addin you are running might be confusing VA 
Using my sample, and much simpler code, when I place the caret into END_MSG_MAP() the context field shows:
#define END_MSG_MAP() break; default: ATLTRACE(ATL::atlTraceWindowing, 0, _T("Invalid message map ID (%i)\\n"), dwMsgMapID); ATLASSERT(FALSE); break; } return FALSE; }
which based on a quick scan, is a good match for the definition I am taken to when I use alt-g.
Does the colouring fail all of the time for you, or only some of the time?
When the colouring has failed, what happens when you try alt-g on END_MSG_MAP? I suspect nothing, or more interestingly you go to somewhere completely different.
The second screen shot interests me quite a bit more, since the bottom two lines have the wrong colouring, almost as if there is a cascade error...
Does commenting out "CHAIN_MSG_MAP(hoverClass)" or "REFLECT_NOTIFICATIONS()" have any effect? I am wondering if something in one of these macro's is confusing VA, and then everything further down the file is a lost cause.
This would certainly go a long way towards explaining your alt-g problems, and most, if not all, of the problems Ivan is seeing.
Of course speculating this is one thing, proving it, and reproducing it, is another. |
zen is the art of being at one with the two'ness |
|
|
|
bugfix
Tomato Guru
Germany
324 Posts |
Posted - May 01 2007 : 3:02:05 PM
|
no other addins than VAX and mine, and my addin sure helps to reduce VAXs confusedness:P
It's in every single WTL project I have.
If you look in wtldir/appwiz there are some .js file that add a WTL project wizard to VS. Can you try 71 one and then create a project w/ VS?
Alternatively I can create a sample project for you.
Uncommenting doesn't change a thing. That would have been too easy:)
Whats even more strange, looking at definitions of those macros in atlwin.h:
Already tried to clean and rebuild db if it fixes a thing the problem soon reappears. |
http://www.mf-sd.de |
Edited by - bugfix on May 01 2007 3:13:09 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
18939 Posts |
Posted - May 02 2007 : 12:57:11 PM
|
I have used the js file for VS2005, and created a default WTL form based project. It does not compile, due to the code:
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include "atlres.h"
which suggests I may have missed a step - due to not reading any instructions
Ignoring this for now I have looked at each of the header files in this project, and in each one of them both "BEGIN_MSG_MAP" and "END_MSG_MAP" are coloured correctly, and shown in italics.
I suspect this is not what you expected me to see.
It may be down to how I have my test system, or project configured, or it may be down to something else. If you have a test project you are happy to share then I can open it here and see what happens. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - May 31 2007 : 12:59:13 AM
|
| ATL and WTL templates is improved in Build 1557 |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - May 31 2007 : 01:23:39 AM
|
| While there were ATL and WTL parsing improvements in 1557, the MSG_MAP macros are still a problem. |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Apr 10 2008 : 01:08:50 AM
|
| case=4249 is fixed in build 1632 |
|
|
| |
Topic |
|
Syntax coloring bugs
