Thu, 03/30/2006 - 10:58
Forums:
if i try to compile a sample from the MFC samples, i become the error:
compiling...
StdAfx.cpp
c:\opencascade6.1.0\samples\standard\mfc\01_geometry\src\stdafx.h(12) : fatal error C1083: File (Include) "afxwin.h": No such file or directory
In the Options- VC++ Directorys there are the OpenCASCADE Paths OpenCASCADE6.1\ros\win32\bin, \inc and \lib.
please could me someone tell, how I make false and how I can compile the samples?
Thu, 03/30/2006 - 12:50
Hi Frank,
do you also have '$(VCInstallDir)atlmfc\include' set?
Anyway, I don't have the 'c:\opencascade6.1.0\samples\standard\mfc\01_geometry\' in my distribution. The MFC examples start with 02_TopologySamples, don't they?
Besides, the samples are pretty buggy. I think the released version wasn't compiled on windows or at least not with vs.
Quite often I had to change
for(Standard_Integer i=...)
{
...
}
func(i); //something done with i but i is out of scope
Regards
Thu, 03/30/2006 - 15:59
Regarding the for-loop issue Pawel raised...
In VS2005 Pro (don't know about Express), you can get around the problem by setting
Project->Properties->Configuration Properties->C/C++->Language...
... Force Conformance In For Loop Scope
to No
--Tom
Thu, 03/30/2006 - 17:29
After separate Installation of the MFC in the C:\Programme\Microsoft Platform SDK Directory and setting up the path in Visual C++ Express Edition, I do no longer become the error. Thank you!
Now, if I build a sample, I become the Linker-Error:
LINK : fatal error LNK1104: File "TKVrml.lib" can´t be opened.
The TKVrml.lib is in the directory C:\OpenCASCADE6.1.0\ros\win32\lib and is not write protected (the Lib-Path C:\OpenCASCADE6.1.0\ros\win32\lib for the Linker is set).
What´s wrong?
Thu, 03/30/2006 - 22:04
The Samples link to a hardcoded path of $(CASROOT)\win32\libd
remove the d from libd in the or build a debug version of OCC in $(CASROOT)\win32\libd
Thu, 03/30/2006 - 22:04
The Samples link to a hardcoded path of $(CASROOT)\win32\libd
remove the d from libd in the or build a debug version of OCC in $(CASROOT)\win32\libd
Thu, 03/30/2006 - 22:14
Only started playing with OCC this week, and still using VS2003 to build a simple OpenCASCADE.sln which makes a complete debug build that I can walk away from - I've got the project dependencies working now, so I'm hoping to migrate to VS2005, but I've run some test compiles and found a few issues with changes to compiler strictness. Also found the .mak files didn't work cleanly.
Anyway, why did I want a debug build. Because if you look at the samples running in 'debug' build, you will find discrete references in the link options for Additional Library Directories that point to $(CASROOT)\win32\libd which doesn't exist with out a debug OCC build. If you build in 'Release' which uses $(CASROOT)\win32\lib , you will find that mfcsample.lib can't be found either, and this has to be build in 'release' build first.
The other thing is to build in debug, you also need a Tcltk installation for DRAWEXE - I downloaded the 8.4.12 version from www.activestate.com.
I'm still working the dependencies out, but I would be very cautiuos about moving directly to VS2005 without reference builds in VS2003.
Pete
Thu, 03/30/2006 - 22:25
As you can see others, answered the question quicker than I. However, the reason I'd didn't want to just change libd to lib is that I like the option when running in debug is to step through the OCC code. Actually this is about where I got to last night, and still could debug through OCC - but I think is because I haven't reset the system path from bin to bind.
Pete
Mon, 04/24/2006 - 16:19
Hello.
I have a similar problem with debugging. I've rebuilt the whole OCC in debug version but did not wanted to change the environment all the time. So i've renamed all the dlls, libs to have a d prefix. It almost worked: OCC loads some library at runtime depending on the environment variables. (It took me half a day to find the reason why the release version was working and the debug wasn't.) So i wanted to change the environment variables, but the exe had a different env.set as the dlls. Finally with the aid of OSD_Environment i could change it, but now it seems to be an ugly hacking. Is there any better solutions. And appart form the FWOSDriver, is there any other run time loaded dlls? (By the way, what does FWOSDriver does ?) And is there collection and documentation of all the environments used? (I've found lots of other used env variable mainly for debugging and performance checking.)
Thanks.