Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Feature Requests
 Add Include improvements

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
jschmidt Posted - Jul 27 2011 : 09:52:56 AM
The Add Include option under the contextual menu Refactor is really a useful tool, but sometimes, when you use the option for types like QPushButton (mostly include from 3rd party) and such you get:

#include "qpushbutton.h" instead of #include <QPushButton> (without the .h, the quoting is not important, can be "" or <>)

Could it be possible to detect header without extension first and include them if available? I know it is really library dependent, but for QT it would be nice cause the casing is not the same. QT always have a extension less header that directly include the header with an extension.

Thanks
27   L A T E S T    R E P L I E S    (Newest First)
sean Posted - May 23 2014 : 2:56:43 PM
case=80599 was opened for Add Include improvement for Qt.
case=80599 is fixed in build 2036.
Predelnik Posted - Apr 14 2014 : 04:24:03 AM
I've tried installable version from http://www.tver-soft.org/qt64 and "add include" for Qt classes works pretty much fine except "QUrl"/<QUrl> issue of course.
Predelnik Posted - Apr 12 2014 : 10:28:42 AM
Well but I certainly did not see any reason to add --prefix before this problem with VAX because everything else was working pretty much fine, so I think it's not exactly right to say that it is something completely obligatory.

Well it's nice that some custom sites do these builds on the other hand for example there was a bug in build for VS 2013 in released Qt version so I've had to use version from Git/ apply custom fix anyway, so until it's officially released there's no guarantee that it's working. Maybe now I'll try them though, thank you.
chrisaverage Posted - Apr 12 2014 : 06:43:23 AM
Well you should use special options (at least --prefix) and not build in the source dir in the first place. For VS 2013(which is MSVC 12.0) you can also find ready binaries(eg. here: http://www.tver-soft.org/qt64) which have a proper tree structure. They do have the .pdb files so you can debug with them, unless of course you want to debug Qt itself, in which case you do need sources.
Predelnik Posted - Apr 12 2014 : 05:28:40 AM
quote:
Originally posted by chrisaverage

I don't think it should use the first subtree. The so called "offline installers" like the one you used are kinda slice of what the main - online installer does. With it you can install several builds of Qt and source separately. The structure is then:
Src\\qtbase\\...
msvc2012\\include\\...
msvc2010\\include\\...
mingw48_32\\include\\...

I think VA should use the one the project is using, cause they can be configured quite differently, with different defines, modules enabled etc. The Src directory is kinda addition to them if you want to for example build Qt yourself.


Well it's obvious that if Qt is configured to add include dirs from second subtree which is the case when it was installed by installers when the second subtree will be used just fine. So for installed versions nothing will change.

The problem is that when you build Qt yourself(which for example you need to do if you want to use if with MSVC2013 currently) you don't have second subtree at all(at least if you built it without any special options) and dirs from the first one is being added to project configuration and thus not handled correctly.

By the way the best usage of source in installed version is to be able to debug it, it really helps sometimes.
chrisaverage Posted - Apr 12 2014 : 04:34:31 AM
I don't think it should use the first subtree. The so called "offline installers" like the one you used are kinda slice of what the main - online installer does. With it you can install several builds of Qt and source separately. The structure is then:
Src\\qtbase\\...
msvc2012\\include\\...
msvc2010\\include\\...
mingw48_32\\include\\...

I think VA should use the one the project is using, cause they can be configured quite differently, with different defines, modules enabled etc. The Src directory is kinda addition to them if you want to for example build Qt yourself.
Predelnik Posted - Apr 12 2014 : 01:35:38 AM
Thank you.
Looks like Qt built from the source has first subtree only, maybe with some additional build parameters it would change but since it's working as intended without them, no one cares very much anyway. So better work with first subtree would be very much appreciated.
sean Posted - Apr 11 2014 : 7:13:44 PM
Thanks for the log. I'll use QDialog as an example.

I've just done an install with source from qt-opensource-windows-x86-msvc2012-5.2.1.exe that I downloaded from the project site.

Here are the QDialog headers that are installed:
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\include\\QtWidgets\\QDialog (1 line -> includes qdialog.h in same dir)
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\include\\QtWidgets\\qdialog.h (1 line -> includes qdialog.h in qtbase\\src dir)
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\src\\widgets\\dialogs\\qdialog.h (full class definition - identical to other full one)
D:\\src.qt\\Qt5.2.1\\5.2.1\\msvc2012\\include\\QtWidgets\\QDialog (1 line -> includes qdialog.h in same dir - same as first QDialog)
D:\\src.qt\\Qt5.2.1\\5.2.1\\msvc2012\\include\\QtWidgets\\qdialog.h (full class definition - identical to other full one)

1 version of QDialog copied to 2 directories.
2 versions of qdialog.h where 1 version is copied to 2 directories and a different version is copied to a third directory.

Looking at the 5 paths above, there are 2 subtree groups:
Src\\qtbase\\...
msvc2012\\include\\...

The changes made in VA build 2031 work when using the 2nd subtree (msvc2012\\include\\...) as additional include directories, but not the first (Src\\qtbase\\...). We'll try to improve results for the 1st subtree in the next build.
Predelnik Posted - Apr 11 2014 : 03:09:02 AM
I've sent it.
sean Posted - Apr 11 2014 : 02:35:51 AM
Can you capture a log of the solution load and of running add include on a qt symbol?
File | Close solution
Enable logging on Performance page of VA options
Load solution
run add include
exit
then zip va.log and send it in via the contact form:
http://www.wholetomato.com/support/contact.asp
Predelnik Posted - Apr 11 2014 : 02:20:51 AM
Yes, "Project defined" is selected and there's no Qt src dirs in source files:
sean Posted - Apr 10 2014 : 12:10:18 PM
When your solution is loaded, open the VA Options dialog; on the C/C++ Directories page, what Platform is selected? By default, it should be Project defined.

Change the Show Directories for dropdown to Source files. Are the Qt src dirs listed there?
Predelnik Posted - Apr 10 2014 : 07:12:04 AM
Well I've posted all Qt related directories here, so there's no src directory mentioned explicitly. And /src dirs are definetily not used in project.
That's really weird though, looks like path "../src/corelib..." is based on "%QT_DIR%/include" include which is kinda strange behavior.
sean Posted - Apr 09 2014 : 3:47:55 PM
Yes, the duplicate headers are a problem. It looks like you are trying to use AddIncludePreferShortestRelativePath to deal with that problem but AddIncludePreferShortestRelativePath just muddles the situation since it assumes a single header file in one location - it was not introduced to deal with header files being duplicated.

In my Qt project, I link to libs/dlls so I do not have any qt /src/ dirs in my additional include dirs. The include dirs you listed do not have any qt /src/ dirs either. Do you have the qt /src/ dirs listed somewhere? Or are you compiling qt /src/ dirs in your project?
Predelnik Posted - Apr 09 2014 : 3:08:53 PM
Well I use stable branch from Qt git, `qmake -v` shows me 5.3.0 version.

Let's say "C:\\rfd\\qt-git-5-x64" - is path to my Qt

My additional include directories (I leave only Qt related paths):
quote:

"C:\\rfd\\qt-git-5-x64\\qtbase\\include";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtOpenGL";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtPrintSupport";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtSvg";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtWidgets";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtNetwork";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtGui";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtCore";C:\\rfd\\qt-git-5-x64\\qtbase\\mkspecs\\win32-msvc2013;"



On the other hand I would note(maybe it's important) that sources dir for the project I'm working on is written as a related path, like "..\\src". There is also a bunch of dependencies with full path which most likely do not matter in this case.

With AddIncludePreferShortestRelativePath - 1, it adds something like:
#include "../src/corelib/io/qurl.h"

with 0, it adds something like:
"c:/rfd/qt-git-5-x64/qtbase/src/corelib/io/qurl.h"

By the way correct (absolute) path to this file should actually be
"c:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtCore\\qurl.h"

So it's very disturbing, maybe you have supported this stuff only for Qt4, because all of these duplicated headers in Qt5 seem to be confusing for VAX.
sean Posted - Apr 09 2014 : 11:36:08 AM
What version of Qt?

What paths are added to Additional Include Directories?

When AddIncludePreferShortestRelativePath is at the default value of 1, what text does add include insert?
Predelnik Posted - Apr 09 2014 : 10:22:30 AM
Well I also interested in such behaviour with Qt but even using 2031 beta, can't achieve anything similar.
I have AddIncludePreferShortestRelativePath set to 0 and it just prints full path to Qt header, starting from "C:\\...", if I have this option turned on path is relative but still long. So what should I do to enable this behavior?

And also regarding additional include directories, QMake default behavior is to put Qt related paths there, so I don't think it would be easy to change that.
sean Posted - Apr 08 2014 : 12:43:17 PM
One other difference about the two directory lists is that if you use the VA "Stable symbols in italic" option, then Qt symbols will be rendered in italic if the Qt dirs are listed on the VC++ Directories page rather than the C/C++ page.

I don't think it is a Qt config bug per se, but it would be good if they offered the option to add the include dirs to one or the other list.
chrisaverage Posted - Apr 08 2014 : 05:04:54 AM
Actually I did neither (myself). There's a Qt add-in for Visual Studio that does that when you select Qt modules in a configuration dialog.
From what I see they indeed add that in the C/C++ section. Do you think this is something I should ask Qt guys to fix in the plugin?
sean Posted - Apr 07 2014 : 6:52:00 PM
<> should be used if you added the Qt include dirs to:
Project Properties | Configuration Properties | VC++ Directories | Include Directories

"" is used if you added Qt include dirs to:
Project Properties | Configuration Properties | C/C++ | Additional Include Directories

(Unless you have modified the AddIncludeTokenStyle VA registry value from the default of 0 per http://support.wholetomato.com/default.asp?W338.)
chrisaverage Posted - Apr 07 2014 : 4:49:56 PM
Thanks for this. It works almost ok but it still includes eg. "QByteArray" when it should include <QByteArray>.
sean Posted - Apr 07 2014 : 3:40:30 PM
build 2031 improves add include results for Qt 5 in some scenarios.
feline Posted - Feb 27 2014 : 11:40:46 AM
We are considering some way of handling this general situation, but its not yet clear how best to do that. I have added Qt to the libraries we want to look at for this:

case=37006
chrisaverage Posted - Feb 20 2014 : 08:13:37 AM
There are no problems (that I know of) like something not compiling or linking etc. so yeah, it's not extremely urgent.
It's a matter of style and convenience mostly. It's along the lines of including "stdlib.h" instead of <cstdlib>.
As such it usually causes code review feedback so for Qt types I end up either fixing the includes or typing them in manually in the first place.
It's a very deeply rooted convention in Qt world and it's just that nobody actually does it differently, and if they do they're immediately asked why :)

Another comment here is that the extensionless headers correspond to the Qt classes, while it's not always the case with .h files, eg.
both <QDate> and <QDateTime> include "qdatetime.h" or <QEvent> actually includes "qcoreevent.h".
It's easier for example to cleanup the includes when they correspond exactly to used classes instead of finding which include is actually for what.
feline Posted - Feb 18 2014 : 4:19:36 PM
We have added some special handling for Qt already, for handling signals and slots, and we do see quite a few support requests that involve Qt to some degree or other.

The regular expression idea is interesting, but it is likely to run into so many edge cases that I am not sure its going to be that useful.

As accord asked, is this actually causing any problems, or is it simply a cosmetic issue? If its causing actual problems then it is obviously more urgent.
chrisaverage Posted - Feb 17 2014 : 10:21:24 AM
I'm a heavy user of Qt too, so it would be really nice to have this. Also Qt is quite popular these days so targeting it specifically might not be that bad of an idea.
There are not many libraries with Q-starting classes so maybe this could be used as an indicator?
If you don't like the idea of targeting specific libraries maybe this could be generalized into some sort of user defined regexp or templates like:

^Q.* --> <%SYMBOL%>
^SomeLib.* --> "Some/Lib/%SYMBOL_LOWERCASE%.h"

or something like this. This could cover a lot of (if not most of) the libraries out there.
accord Posted - Jul 31 2011 : 12:46:27 PM
*uh* This is a special problem. Every library has its own policy and some of them uses special logic, like in this case. It cannot be solved generally, since strictly speaking VA includes the header which contains the symbol definition, so it can be considered "normal".

Is this causing any serious problem (i.e. with compiling or using the library), or is it "just" a cosmetic issue?
Simply only detecting whether the header has extension would have cause problems for other libraries / projects.
I'm not sure if is there any simple solution here, rather that supporting QT specifically.

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