Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Suggestion accepted without consent

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
carase Posted - Nov 28 2007 : 11:04:31 AM
I've noticed this problem with the new 10.4.1619.0 build of VAX.

I begin to type a member function, and get a drop down list that reduces to a single, totally incorrect match:

$ pPants->zipUp
[INCORRECT_SYMBOL_OF_DEATH]

Then I type the open parenthesis, since I'm ignoring VA:

$ pPants->zipUp(

VA decides my parenthesis indicates agreement, and does this:

$ pPants->INCORRECT_SYMBOL_OF_DEATH(

Then I cut my eye out with a spoon. It would seem that the checkbox under Options-Advanced-Listboxes-"Selections committed with Any character not valid in symbol" would control this behavior, but it occurs no matter what this box' value is.

I hope that this is specific enough, if not I can try to create a dummy project that demonstrates the problem.

Thanks,
Eric Caraszi
Vicarious Visions, Inc.
10   L A T E S T    R E P L I E S    (Newest First)
support Posted - Aug 04 2010 : 5:40:29 PM
"Selections committed with" behavior for member lists is now configurable under VA Options | Advanced | Listboxes. (case=9369), implemented in build 1829.
feline Posted - Nov 29 2007 : 4:53:55 PM
Excellent news
carase Posted - Nov 29 2007 : 4:22:39 PM
Your workaround is reasonable. I'll give it a try and post my results here.

Edit: Making a local StdAfx.h and putting stripped-down copies of my DEFINE_FIELD macros works like a magic charm. Awesome.
feline Posted - Nov 29 2007 : 2:41:12 PM
A very clear example, thank you

In the function Pants::bar() I am seeing _fieldNergets underlined as a mistyped symbol. Are you seeing the same thing?
Since VA is already confused at this point, things are going to rapidly go down hill from here.

I have changed the code by adding a dummy, and much simpler macro definition:


#ifdef VA_VALID_CODE_BUT_DOES_NOT_COMPILE
#define DEFINE_OBJECT_FIELD(CLASSTYPE, FIELDTYPE, METAFIELDTYPE, NAME, ENUM, ATTR, ALIGNMENTPREFIX, ALIGNMENTSUFFIX, REF, DESTRUCT) \	static METAFIELDTYPE* ENUM; \	SmartPointer< FIELDTYPE > NAME
#endif // VA_VALID_CODE_BUT_DOES_NOT_COMPILE

#define DEFINE_OBJECT_FIELD(CLASSTYPE, FIELDTYPE, METAFIELDTYPE, NAME, ENUM, ATTR, ALIGNMENTPREFIX, ALIGNMENTSUFFIX, REF, DESTRUCT) \	static METAFIELDTYPE* ENUM; \	ALIGNMENTPREFIX ATTR SmartPointer< FIELDTYPE > NAME ALIGNMENTSUFFIX


As you have already worked out VA is having problems with the DEFINE_OBJECT_FIELD macro.

Arguably this is a bug with VA. In this case though VA's parser would have to start evaluating macro's within macro's, and since VA often "sees" multiple macro definitions this could get very messy very quickly.

Since my simpler macro definition comes first I am hoping VA will use it, instead of the more complex macro that it does not understand. Since the macro is wrapped in a "do not compile me" #define the compiler never sees it, but VA's parser does.

For me the line of code:

float f = _fieldNergets->get(i);

now works. No underlining, and "get" is suggested by VA. Do you follow what I have done here, and why? You may need to tweak the fake macro slightly to suit your requirements and actual code base.

If you want to get really clever, or just leave your code alone, you may find that adding fake macro's to VA stdafx.h file, explained here:

http://docs.wholetomato.com?W302

with an example here:

http://docs.wholetomato.com?W310

works better. Note I have not tested this, but in theory it should work.
carase Posted - Nov 29 2007 : 09:42:08 AM
You've encouraged me to dig further. Here is example code which demonstrates the problem. I believe the problem lies in our metadata system which defines fields using macros and smart pointers. Somehow, VA does not recognize the fields. Copy the following code into a blank Visual Studio Console Application.

Let me know if this is sufficient, or if there is a bug database I should go enter this into. Thanks!


// macro_field_bug.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"

template <class T>
class SmartPointer
{
public:
	T* operator -> ()
	{
		return _ptr;
	}
	T* _ptr;
};

#define DEFINE_OBJECT_FIELD(CLASSTYPE, FIELDTYPE, METAFIELDTYPE, NAME, ENUM, ATTR, ALIGNMENTPREFIX, ALIGNMENTSUFFIX, REF, DESTRUCT) \	static METAFIELDTYPE* ENUM; \	ALIGNMENTPREFIX ATTR SmartPointer< FIELDTYPE > NAME ALIGNMENTSUFFIX

#define __dummy__

class Nergets
{
public:
	float get(int i)
	{
		return float(i);
	}
};

class NergetsMetaField
{
public:
	int all_about_nergets;
};

class Pants
{
public:
	DEFINE_OBJECT_FIELD(Pants, Nergets, NergetsMetaField, _fieldNergets, k_fieldNergets, __dummy__, __dummy__, __dummy__, true, false);

	float bar();
};

float Pants::bar()
{
	int i = 0;
	// Try to type _fieldNergets->get(i).  It will not autocomplete.
	float f = _fieldNergets->get(i);
	return f;
}

int _tmain(int argc, _TCHAR* argv[])
{
	Pants p;

	printf("%f\\n", p.bar());

	return 0;
}

feline Posted - Nov 29 2007 : 08:23:50 AM
spark if you open the OFIS dialog the title bar gives you two numbers, the number of files currently showing in the list and the total number of files. What is the total number of files in your solution?

This will give us some form of perspective on the size of the solution.

Do you see this problem with a local variable? I am wondering if the variable declaration is visible, so you can see if the class name (the variables type) is correctly coloured. If the type is coloured correctly then VA should have a good idea of what is happening.

If you place the caret into the variable name its self does VA show you the correct information in the context and definition fields?

If you wait for a few seconds, to give VA time to catch up, do you get the correct items listed in the listbox?
If you show VA View, then place keyboard focus back into the editor, and now hover the mouse over the variable is the correct information displayed?
spark Posted - Nov 28 2007 : 2:31:08 PM
I experience the same issue. It seems to me like VA doesn't realize what class I'm working with. I already know what function I want to call in the class---VA is probably still determining what my class is...

If I use alt-g on the functions that this issue occurs with, it does find the correct definition and declaration. VA usually lists one item in the list box when this happens. It's usually a macro. And it seems to be fairly random in that it's occurred with every class I've worked with.

The entire project here is written in C++. We use lots of inheritance. It's a very LARGE code base.
feline Posted - Nov 28 2007 : 1:57:10 PM
case=9369 is asking for the VA options to apply to all listboxes, which should be what you want.

If you use alt-g on one of these problem types does VA list one definition for the type, or several? If it only finds one definition then it may only require a single class copied and pasted into a test project to reproduce the problem. There is no need for the code to compile, although it would obviously be nice

I am just wondering how to make reporting the listbox content bug as easy and simple as possible. There may be something we can do about it.
carase Posted - Nov 28 2007 : 1:44:48 PM
Yes, I suppose the bug is that the listbox is wrong.

This is common. Our codebase is a large cross-platform hardware abstraction layer. Our header files are generated from another custom language, which I point VA at to parse.

There are multiple reasons I don't expect VA to handle everything, primarily because I do not remotely have time to piece out nice well-specified bugs for you :)

A checkbox to disable this behavior would make me totally happy.
feline Posted - Nov 28 2007 : 1:27:49 PM
There is one bug and one "by design - it needs changing" effect here. The listbox being accepted is by design, since this is what the IDE its self does when VA is not installed. This is reasonable behaviour if you assume that the listbox is always correct, and that you are not trying to use VA's Create Declaration refactoring:

case=9369

The VA options currently apply to suggestion listboxes (VA's current best guess at what you are thinking) but not to member listboxes (all members of this type).

The bug is that the listbox is wrong. Is this a common problem in your code? Or is this limited to only certain problem classes and types?

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000