Thu, 01/11/2001 - 21:48
Forums:
hi
is it possible to not set any environment variables and still use opencascade?
i'd like to try to create an active x control embedded in a browser. i'm not sure but i don't think the active x control can conveniently read environment variables. so i'm avoiding that altogether if possible. besides, it makes distribution easier.
perhaps there are certain global variables that i can set in opencascade modules?
Fri, 01/12/2001 - 12:10
Hello,
you can set the environemnt variables programmatically with OSD_Environment :
OSD_Environment theCSFGraphicShr("CSF_GraphicShr","C:\\WhereIWant\\TKOpenGL.dll"); theCSFGraphicShr.Build();
Under WNT , this Environment variable will be valid inside your process ( for *nix, I don't know ).
Take care : you must do that at the beginnig of your application, before any call to Cascade !!!
HTH,
Stephane
Fri, 01/12/2001 - 15:13
Hi,
I just post a little remark about V.E.s: I think ( i guess Stephane agree) that there is a very simple and very efficient method for using V.E. : -> FORGET THEM!! Nowadays, any problem can be solved in a efficiently, portable and elegant way by using any solution which DOES NOT use V.E. I can submit you a lot of stuff for bypassing V.E. Examples: 1.The most trivial and straightforward is analyze argv/argc and/or build a little IHM to propose what you want to set before running your application. 2. Use Properties in the command line (that look likes the java invocation style -DName=.. ) or properties in a file. 3.Stop writing any code if you plan to use VE. (Here the best solution i think) L-)
Fri, 01/12/2001 - 16:01
Hello Yan,
I'm agree to say that the best way to handle the Environment Variables is not using them,and not register them in the system.
A common problem with the environemnt variables is : what happens if somebody whant to use your software with a third party software. In your installation programm, you CANNOT overwrite the old ones, because the other application using OpenCASCADE may not work.
But your solution with command line is not very efficient , especially with an MFC application on Windows.
You cannot ( or not very easy ) give the EV as command line, because , if you create an Application ( MyApplication.exe ) with your file extension ( .MyExt ), you can associate the extension with your application. When you doubleclick a file ( toto.MyExt ) , windows will automatically launch "MyApplication.exe toto.MyExt" and your command line params will be ignored. I think it is the same if you are creating an Embedded Application ( ActiveX ... ) , you cannot control the command line.
My solution on Windows is to store the environment variables in the Registry under your product-key ( HKLM\Software\MyCompany\CSF_GraphicShr=\Dlls\MyTKOpenGL.dll). When you start your application ( in the InitInstance method ), you just need to read these variables from the registry and register them using OSD_Environment ( see previous post ).
My 2 cents,
Stephane
Thu, 01/18/2001 - 02:41
The command line is specified in the association with the file type, so there is no reason why you can't put it there. Actually, it is almost the same solution, you create an association by editing the registry, instead of putting information in separate keys, you put it in the form of command-line arguments. This has the advantage of being portable, and easier to change in the registry than separate (often cryptic) keys.
IMHO command-line arguments are the best way to specify run-time information.
As far as enviornment varaibles are concerned, I HATE them. We are currently re-writing our app in Open CASCADE because we are not satisfied with the development tools we were using. These inferior tools rely heavily on enviornment variables, and under IRIX one of the envornment variables that must be set causes SGI's compilers to fail.
Take heart though, recently changes have been made to inform the user that CSF_GraphicShr is not set, rather than the segmentation fault we were all used to seeing.
Tue, 01/16/2001 - 11:04
hi!
thanks a million for the replies. i certainly agree not to use environment variables as they're a bit restrictive. anyway, let's debate that elsewhere.
now, i've tested my program by intentionally leaving out EV or setting wrong values in the EV. but the program still crashes.
the program is actually an ATL COM object. it worked fine without MFC, just plain Win32SDK. the line that crashes is:
myViewer->SetWindow(myWNTWindow);
any ideas anyone?
thanks a gazillion again!
kh