Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: Martin K. on November 27, 2012, 11:47:50 am

Title: unable to open project fíle
Post by: Martin K. on November 27, 2012, 11:47:50 am
Hi,

Its me - again :-)

I cannot open the attached project any more. Can someone try to open it?

Thanks, Martin
Title: Re: unable to open project fíle
Post by: ollydbg on November 27, 2012, 11:51:06 am
I can open it correctly. (nightly build rev8500)
Title: Re: unable to open project fíle
Post by: MortenMacFly on November 27, 2012, 12:05:34 pm
Works fine here, too - even in compiler branch from trunk.

But you've used a copied compiler that is not available on my PC C::B asks me to specify an alternative compiler. Maybe thats confusing to you as you've removed the compiler copy, probably?
Title: Re: unable to open project fíle
Post by: Martin K. on November 27, 2012, 01:38:47 pm
I have found the problem, maybe you should be care about it:

If you enclose the search path in the compiler settings with qoutes (for example: compiler->search directory->compiler = "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include") then wxFileName.Normalize() takes from 4 - 10 seconds on each call and generates a wrong filename. wxDir::Exists() taks this long time also. Both where called from the codecompletion plugin. It seems that a) this quotes should be deleted (automatically?) in the compiler configuration and in the local build settings and b) this functions are taking so much time because windows is seraching for this (wrong) paths on the local network. "C:\ becomes \\"C, maybe a possible unc path.

Martin
Title: Re: unable to open project fíle
Post by: MortenMacFly on November 27, 2012, 02:03:46 pm
It seems that a) this quotes should be deleted (automatically?)
No, this would dis-allow the use of macros in path's and most likely even break it. In addition it may be a backtick'd expression which needs this because it becomes evaluated. Please note that these are not necessarily plain path's but can be complex macros.

Its clearly a user input error, so as long as C::B does not crash I see no reason to "fix" this.