Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Technical Support
 Suggestion accepted without consent
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

carase
New Member

5 Posts

Posted - Nov 28 2007 :  11:04:31 AM  Show Profile  Reply with Quote
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.

feline
Whole Tomato Software

United Kingdom
19022 Posts

Posted - Nov 28 2007 :  1:27:49 PM  Show Profile  Reply with Quote
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?

zen is the art of being at one with the two'ness
Go to Top of Page

carase
New Member

5 Posts

Posted - Nov 28 2007 :  1:44:48 PM  Show Profile  Reply with Quote
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.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19022 Posts

Posted - Nov 28 2007 :  1:57:10 PM  Show Profile  Reply with Quote
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.

zen is the art of being at one with the two'ness
Go to Top of Page

spark
New Member

5 Posts

Posted - Nov 28 2007 :  2:31:08 PM  Show Profile  Reply with Quote
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.

Sarah Park
Software Engineer
Chief Architect, Inc
http://www.chiefarchitect.com
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19022 Posts

Posted - Nov 29 2007 :  08:23:50 AM  Show Profile  Reply with Quote
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?

zen is the art of being at one with the two'ness
Go to Top of Page

carase
New Member

5 Posts

Posted - Nov 29 2007 :  09:42:08 AM  Show Profile  Reply with Quote
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;
}


Edited by - carase on Nov 29 2007 1:34:35 PM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19022 Posts

Posted - Nov 29 2007 :  2:41:12 PM  Show Profile  Reply with Quote
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.

zen is the art of being at one with the two'ness
Go to Top of Page

carase
New Member

5 Posts

Posted - Nov 29 2007 :  4:22:39 PM  Show Profile  Reply with Quote
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.

Edited by - carase on Nov 29 2007 4:40:19 PM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
19022 Posts

Posted - Nov 29 2007 :  4:53:55 PM  Show Profile  Reply with Quote
Excellent news

zen is the art of being at one with the two'ness
Go to Top of Page

support
Whole Tomato Software

5566 Posts

Posted - Aug 04 2010 :  5:40:29 PM  Show Profile  Reply with Quote
"Selections committed with" behavior for member lists is now configurable under VA Options | Advanced | Listboxes. (case=9369), implemented in build 1829.

Whole Tomato Software, Inc.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000