Windows resource problem

[RandomMan]

I searched and found Vampyre_Dark's earlier thread on resource problems, and it fixed all but one aspect of what I am having.

Added an .rc file to my project, and it now does get compiled by rc.exe, and placed into the .objs\[app] directory as a .res file.  But I cannot get this to become linked into the executable.  If I enable full compiler output, the .res file is not in the final "link.exe /nologo..." line.

I can manually build the file ('rc.exe filename.rc'), and place it in the program directory (not the .objs directory), and add that .res file to the project and it is added correctly.

Any ideas?

Thanks,
David

using VC2003 toolkit with latest download of Code::Blocks (yesterday).

(ps - I am becoming much more impressed by this thing the more I play with it.  Thanks for everyone's hard work, it is much appreciated.)

[mandrav]

Go to "Settings->Compiler->[select MSVCToolkit]->Other->Advanced options" and make sure that the command line macro for "Link object files to executable" is like this:

Code

$linker /nologo /subsystem:windows $libdirs /out:$exe_output $libs $link_objects $link_resobjects $link_options

[RandomMan]

That fixed it!  Thanks.

FYI, I'm also having issues with the Logitech mouse item mentioned in other messages.  The main issue involves not being able to use the middle button for double-clicking on anything within Code::Blocks, although other programs are not affected.  It is probably a wxWidgets thing, so there is probably not much you can do about it.

Another issue I'm having is that my tooltips for my program, that displayed correctly using two other development environments, now come out looking like they are Unicode.  What used to be "Create new performance" now comes out as a square and a squiggly (tilde?).  It is probably something to do with using the XP headers rather than the older headers in the other two environments.  I've tried to ensure that Unicode is not defined, but have not yet gotten to the bottom of the problem.  It looks like I'm going to have to tear into WinDbg, so more learning is directly in my future.  I'll try to post what I come up with, unless anyone has seen this before, and has a solution.

Again, many thanks.
David

[RandomMan]

Added your solution to the wiki.  Cool.  I've never played with wiki's before.

http://wiki.codeblocks.org/index.php/Integrating_Microsoft_Visual_Toolkit_2003_with_Code::Blocks_IDE

[mandrav]

Thanks

[RandomMan]

And the tooltip problem ended up being the fact that MS had superceded the 'TOOLTIPTEXT' structure with the 'NMTTDISPINFO' structure, and of course, the newer headers illuminated this.

Does anyone know of a good tutorial on using WinDbg for normal debugging?  I was unable to even figure out how to get WinDbg to find the symbols for my app, although the file had been created.  (Or at least I think it wasn't finding the symbols.  It is slightly overwhelming to a beginner.)

David

[Vampyre_Dark]

I never had to mess around with the linker commands, I just had to make sure all the proper stuff had it's folder included. I think CB had some problem wanting everything to be under the same folder, when the platform SDK has it's own bin folder or something like that.

[mandrav]

I never had to mess around with the linker commands, I just had to make sure all the proper stuff had it's folder included. I think CB had some problem wanting everything to be under the same folder, when the platform SDK has it's own bin folder or something like that.

That was true at some point, but since mid-summer C::B supported compiler programs residing in multiple paths (see Settings->Compiler->Programs->Additional paths).

The problem discussed here was a wrong compilation command-line, which has been fixed in CVS.

[Vampyre_Dark]

I never had to mess around with the linker commands, I just had to make sure all the proper stuff had it's folder included. I think CB had some problem wanting everything to be under the same folder, when the platform SDK has it's own bin folder or something like that.

That was true at some point, but since mid-summer C::B supported compiler programs residing in multiple paths (see Settings->Compiler->Programs->Additional paths).

The problem discussed here was a wrong compilation command-line, which has been fixed in CVS.

I think I remember better... the problem was that the program looked for the resrouce stuff in the compiler's bin folder even when extra folders were specified. You had to put the whle path for it to work.