Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 3

Qt-interest Archive, August 2007
Visual Studio problem with moc-files


Message 1 in thread

Hi,

I'm having a funny problem with VS, both .Net and 2005 versions.

In the project theres been classname.cpp/.h for a while. The .cpp
contains #include "classname.moc" and this have been working without
problems in VS.

However, after I've added abstractclassname.cpp/.h, VS changes the
custom build of classname.moc to use abstractclassname.cpp instead of
classname.cpp. Even if I change the custom build job, press apply,
right click and choose to compile the single classname.moc, VS changes
the build job.

Anyone run into this?

-- 
 [ signature omitted ] 

Message 2 in thread

On 8/14/07, Robin Helgelin <lobbin@xxxxxxxxx> wrote:
> Anyone run into this?

And as usual I should have made a better search on Google than I first
did :). Disabling AutoUpdateBuildSteps in Qt-integration fixes the
problem.

However, should this be considered a bug in the integration or Visual Studio?

-- 
 [ signature omitted ] 

Message 3 in thread

> On 8/14/07, Robin Helgelin <lobbin@xxxxxxxxx> wrote:
> > Anyone run into this?
> 
> And as usual I should have made a better search on Google than I first
> did :). Disabling AutoUpdateBuildSteps in Qt-integration fixes the
> problem.
> 
> However, should this be considered a bug in the integration 
> or Visual Studio?
> 

i don't think you can count this as a bug - it's the way the integration
works - imho it's best to "surrender" to the integration and adopt the
way of the integration in how you structure your projects (how files are
put in directories or project folders) - this way you won't have the
problem that you want it "your way" and the integration always tries to
change it into a different way.

Cheers,
Peter

--
 [ signature omitted ] 

Message 4 in thread

On 8/14/07, Peter Prade <prade@xxxxxxxxxxx> wrote:
> i don't think you can count this as a bug - it's the way the integration
> works - imho it's best to "surrender" to the integration and adopt the
> way of the integration in how you structure your projects (how files are
> put in directories or project folders) - this way you won't have the
> problem that you want it "your way" and the integration always tries to
> change it into a different way.

Why not? Something changes my command line to use another source file
than it was configured to. If I disable AutoUpdate in Qt-integration
it works. However, I still don't know if it's Qt-integration that
changes the line (It's a bug in Qt-integration), of it's
Qt-integration that tells Visual Studio something, and then Visual
Studio changes the line (hard to tell where to problem really is).

-- 
 [ signature omitted ] 

Message 5 in thread

> Why not? Something changes my command line to use another source file
> than it was configured to. If I disable AutoUpdate in Qt-integration
> it works. However, I still don't know if it's Qt-integration that
> changes the line (It's a bug in Qt-integration), of it's
> Qt-integration that tells Visual Studio something, and then Visual
> Studio changes the line (hard to tell where to problem really is).

Without seeing your project file it's hard to tell what's going wrong,
however, the custom build step that does the moc'ing should usually be a
property of the corresponding .h file, not the .moc file.

The integration uses this scheme: for each <name>.h file that contains
the Q_OBJECT macro, it creates a custom build step that creates a
moc_<name>.cpp and it adds this .cpp file into a folder named "Generated
Files". As long as you can accept this scheme, the integration does a
fine job.

If this doesn't work for you, you'll have to turn of the automatic
updating on the build steps and do it your way(tm).

Cheers,
Peter

--
 [ signature omitted ] 

Message 6 in thread

On 8/14/07, Peter Prade <prade@xxxxxxxxxxx> wrote:
> Without seeing your project file it's hard to tell what's going wrong,
> however, the custom build step that does the moc'ing should usually be a
> property of the corresponding .h file, not the .moc file.

> The integration uses this scheme: for each <name>.h file that contains
> the Q_OBJECT macro, it creates a custom build step that creates a
> moc_<name>.cpp and it adds this .cpp file into a folder named "Generated
> Files". As long as you can accept this scheme, the integration does a
> fine job.

Yes, and all classname.moc and moc_classname.cpp/h files are created
within the project without problems.

> If this doesn't work for you, you'll have to turn of the automatic
> updating on the build steps and do it your way(tm).

I don't accept this as it's obviously a bug somewhere. I'm going to
make a simple testcase and send that Trolltech tomorrow. If it's VS
fault I can't do much about it, if it's in Qt-integration, I'm helping
Trolltech finding this bug so other people don't suffer from it :-).

-- 
 [ signature omitted ] 

Message 7 in thread

On 8/14/07, Robin Helgelin <lobbin@xxxxxxxxx> wrote:
> I don't accept this as it's obviously a bug somewhere. I'm going to
> make a simple testcase and send that Trolltech tomorrow. If it's VS
> fault I can't do much about it, if it's in Qt-integration, I'm helping
> Trolltech finding this bug so other people don't suffer from it :-).

Trolltech accepted this as a bug in the integration.

http://trolltech.com/developer/task-tracker/index_html?id=175262&method=entry

-- 
 [ signature omitted ]