Hi,
is anyone using VC7 to develop JUCE applications? It compiles fine, but something is not quite right. I extended the sample project to have another window resulting half an hour trial and error to make it compile again. The problem was one of the horizontal lines /===… which are used to divide the code.
And the funny behavior continues… if I set a breakpoint it usually picks a more or less randomly the next or previous method and breaks there. While stepping the code in debug mode it does not follow the sources correctly and sometimes the execution cursor is inside comments, etc.
I looked at the forums and most of the problems other people have are related to get the sources to compile in the latest VC. Any ideas what could cause this? Does the sources contain some multibyte stuff which could mess the visual studio?
I do not experience the same problems, but I’ve disabled the #pragma(lib,"…juce…") stuff, and I’m also building through custom makefiles , which I use for many other projects.
I never experienced something like this, while debugging JUCE (debug, release, final and even final + LTCG)
That’s certainly strange - are you sure you’ve not got multiple versions of the library - sounds like it’s built a different version to the one it’s showing you. Not sure if that’s even possible though…
I am having this problem and its driving me insane!! I have wasted about 4 hours today chasing wild geese just trying to get the debugger to break on the line I tell it to. It skips over lines that are there and breaks at lines that don’t exist.
How did you get it to work? I don’t see any #pragma(lib…JUCE…) stuff anywhere.
Possible idea, (though I don’t have VS7) - if you tell it that one project’s dependent on another one, then if the other one’s a library, the compiler will automatically try to link the version of the library that has the same configuration name. Could it be automatically linking the wrong one?
As I said, I’m not using JUCE provided dsw/dsp/vcproj/etc. files. I’m building the files with custom makefile, by including all .cpp.s
I’m now also linking with sqlite3 (sqlite.org), and lua (lua.org) and Visual Studio 2003 indeed does strange things when debugging.
I too was unable to debug (I’ve said before I did not have problems). But hardly that’s JUCE’s fault - after deleting .suo and .ncb files cleaning and starting again - it worked!
Once I actually got the debugger and juce locked one onto each other. Juce was opening a File Open Dialog (standard win32) - some assert happened meanwhile, VSNET 2003 stopped, but kind of hanged, and the Open Save File Dialog too - it was weird.
I blame it on MS, as such problems used to happen and with other non-juce related projects if they are using more than one thread (for example directInput and OpenAL).
I have the same problem in VS7, but only in the button/change handlers in my own code, but not when I’m using the jucedemo. I have noticed that all the code is in one .cpp file and all “inlined”, i.e declaration of functions are implemented in a seperate file to the definition of the the functions. I wonder if this makes a difference?
I doubt it would make a difference, and in C++ it is best to seperate them since you can have conflicts that can arise if they arent’, not to mention changing the implementation at compile-time is easier.
