I've worked for more than ten years with OCC, I know this message quite well, usually it's easy to get rid of it, but recently I couldn't figure why I could not open 3dView anymore in my App (VS2008) ...
It didn't worked anymore even for OCC sample, even with batch files (*.bat) that does the work for env. var.
Usually the answer in this forum is Look at "CSF_GraphicShr" environment variable, it is not set properly.
A lot of people says in this forum it does not solve their problem, it's just because this simple assomption is not 100% true.
It's a starting point but not the solution.
Some beginners will go away probably just because of one line in OCC code.
You have to understand precisely what is happening. takes hours !
I personnaly don't use env. variables,, it's a unix approach, not always easy to check or not fast to configure.
You can use OSD_Environment
I would prefer an xml SetOccConfiguration("occ_config.xml") but it's another discussion
[First Analysis :]
In fact CSF_GraphicShr is not really mandatory. You can delete it. It will take dllName="TKOpenGl.dll" by default
If you look code, OCC will try to Load Dll TKOpenGl.dll with this call ::LoadLibraryEx (dllName, NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
*********************** </MY CODE> **********************
void 3dViewerWnd::CreateIndependentViewer(V3d_TypeOfView aDefaultTypeOfView)
// if this not working dont go further
myGraphicDevice = new Graphic3d_WNTGraphicDevice(); // call SetGraphicDriver
[SEARCH FOR TYPICAL PROBLEMS]
So you have to find why this dll Load fails.
Sources of problem can be
Mixing x64 with win32 compilation or
Release with Debug dll or
Multi-Threaded Dll with Single Threaded Dll or
Your Os can't find your Library.
Mixing OCC versions without knowing it (6.5.1 with 6.2.0)
You installed another software that use OCC and this software puts OCC dll in System32 (bad luck)
SetDllDirectory is called somewhere (your code or even not) and will redirect badly LoadLibraryEx call
Look all OCC Dll path in the Debug Window when they are being loaded by the sytem.
Search in your computer ALL "TKOpenGL.dll" and you could find some surprise.
Dynamic-Link Library Search Order
Note that the standard search strategy and the alternate search strategy specified by LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH differ in just one way:
The standard search begins in the calling application's directory, and the *** alternate search begins in the directory *** of the executable module that LoadLibraryEx is loading.
If a module changes the standard search order by calling the LoadLibraryEx function with LOAD_WITH_ALTERED_SEARCH_PATH, the system searches the directory the specified module was loaded from instead of the directory of the calling process. The system searches these locations in this order:
The package dependency graph of the process. This is specified in the <Dependencies> section of the application's package manifest. Dependencies are searched in the order they appear in the manifest.
The directory the specified module was loaded from.
The System directory (%SystemRoot%\system32).
If lpFileName specifies a relative path, the entire relative path is appended to every token in the DLL search path.
To load a module from a relative path without searching any other path, use GetFullPathName to get a nonrelative path and call LoadLibraryEx with the nonrelative path.
If the module is being loaded as a datafile and the relative path starts with .\ or ..\, the relative path is treated as an absolute path.
If lpFileName specifies an absolute path and dwFlags is set to LOAD_WITH_ALTERED_SEARCH_PATH, LoadLibraryEx uses the altered search path. *** LOAD_WITH_ALTERED_SEARCH_PATH does not work with relative paths. ***
Alternate Search Order for Desktop Applications
The standard search order used by the system can be changed by calling the LoadLibraryEx function with LOAD_WITH_ALTERED_SEARCH_PATH. The standard search order can also be changed by calling the SetDllDirectory function.
So what you can try first :
::LoadLibrary ("TKernel.dll") Doest it work ?
yes : continue, no : check your "Path" env Variable and get error code and message associate with it
::LoadLibrary ("TKOpenGl.dll") Doest it work ?
yes : your CSF_GraphicShr is not set properly or check there is no OCC dll in your App Directory. No : continue or call this before new Graphic3d_WNTGraphicDevice();
::LoadLibrary ("D:\\OpenCASCADE6.5.1\\ros\\win32\\vc9\\bind\\TKOpenGl.dll") Doest it work with your full path ?
yes : check your "Path" env Variable and check there is no OCC dll in your App Directory. You could think one Dll is used and in fact it's another one
no : check the full path between "", then clean and recompile OCC Project entirely and check before the platform, the lib and include path, "VCVER" env Var, "OS_TYPE" env var. (vc9, win32 for ex)
If like me it does not work after all that awful work :
1°) workaround is call ::LoadLibrary("TKOpenGl.dll") before OCC call to "new Graphic3d_WNTGraphicDevice(); "
2°) change OCC code in OSD_SharedLibrary :: DlOpen () then recompile OCC
Hope this approach will helps.
If I find the solution without changing OCC code, I will post it.
working with OpenCascade for beginners is hard going. I'm working some years with OCC under Windows XP SP3 and with MS Visual Studio 2008 SP1.
I agree with your observation that the answers in the forum on the failure with graphic initialization are always the same: enviroment settings are wrong
and it helps not.
I have now a curious occurrence:
My application is starting in debug-Modus with OCC 6.5.0 (compiled with VS 2008) as well under Win XP as Windows 7 64 bit prof. Both OS on different hardware. No problem.
If I try to start my application with OCC 6.5.1 (also compiled with VS 2008) under Win XP it works well, with Windows 7 64 bit the application start crashed with the wellknown failure :
On the same hardware with the same OS (Win 7 64 bit) and the same enviroment settings OCC 6.5.0 and OCC 6.5.1 has a different behaviour ? A beginner has to be frustated if he failed at these things.
Does this makes any sense ?
I think the whole installation routine of OCC has to be overhauled. The procedures are to difficult for beginners.
I have checked the OCC6.5.1 in the specified environment: VS2008, Windows 7 X64 bit prof. The problem is not reproduced. Probably you didn't follow the published instructions for OCCT rebuilding or did it in a customized way.
The OCCT rebuilding instructions are very simple.
1)First you need to rebuild third parties libs to be used with OCCT.
Html documentation delivered with the release gives good road-map for this.
See chapter "Welcome to Open CASCADE Technology/Compilation of third-party products used for OCCT/Recommendations for compilation".
As result you should get in '3rdparty' directory the next structure of the rebuilt third parties:
Projects' options are well defined in the specified chapter too.
2) Second step is rebuilding of OCCT itself.
It's also well defined in the chapter "Welcome to Open CASCADE Technology/Building Modules/Building Modules".
It is in fact the easiest step. Pay you attention to the last note:
Use script msvc.bat located in the ros sub-folder of OCCT installation directory for launching MS Visual Studio in the environment configured for building OCCT libraries. The script accepts optional arguments: the version of Visual Studio to launch (vc8, vc9, or vc10), the architecture (win32 or win64), the mode of libraries to use for execution (Debug or Release), and the path to the solution file."
For you case it may be like the next
msvc.bat vc9 win64 Release
After that you should just rebuild the solution.
3) Check step (using Draw application).
Use script draw.bat located in the ros sub-folder of OCCT installation directory to run Draw:
draw.bat vc9 win64 Release
> pload ALL
> box b 100 100 100
> vdisplay b
> vsetdispmode 1
After that you will see in 'Test3d' window the just built box 'b' in shading mode.
The displayed box proves that there is no problem with Viewer3d services.
Thank you very much for your help.
but I compiled the third-party libs on my 64-bit machine Windows 7 64 bit VS 2008 SP1 in accordance to the documentation as 32 bit versions without any problems.
I rebuilded OCCT 6.5.0 and 6.5.1 as 32 bit version too in debug and release modus without any failure.
My application project compiled and linked against OCC 6.5.0 starts in 32 bit debug modus, with OCC 6.5.1 crashes with above mentioned failure while starting. That is what I do not understand.
Maybe it is my specific problem, so I will work further with OCC 6.5.0.
After finishing my works I will follow your instructions to compile and rebuild everything in 64 bit with OCC 6.5.1.
I will report.
Hi, I do not know if it can help but when TKOpenGL.dll is loaded windows try also to load dependent libraries like ftgl_dynamic_MTD.dll.
Just try to copy all dependents dll in the same folder as TKOpenGL.
Hope this help
so do you mean that the final solution for the problem is to do "THIS ONLY"
because I did set "CSF_GraphicShr" environment variable properly but I still have the problem
waiting for help
Dear Philippe Carret ......
I had the same problem of Graphic initialization ....
I did set "CSF_GraphicShr" environment variable
and I replaced :
myHandle = ( HINSTANCE )LoadLibraryEx ( myName, NULL, LOAD_WITH_ALTERED_SEARCH_PATH) ) == NULL
myHandle = ( HINSTANCE ) ::LoadLibrary (myName) ) == NULL
and then I recompiled OCC but then I had the same problem so what is wrong then ??????