I've got an interesting problem here. I'm trying to determine if a given lightpoint is flashing or not. The files are openflight 15.7 but I'm reading them with the 2.6 API
I figure it's creating a light point palette when it reads the file so I've tried
mgGetAttList(rec, fltLpAnimation, &animpalettenumber;, MG_NULL);
to grab the animation palette ID number but it errors out, with this sort of message:
W: Unable to get attribute value 2792:"NULL" [argument number 1].
Trying to go the other way and just get the flashing flag directly from the lightpoint (as if it wasn't in a palette) I tried this:
mgGetAttList(rec, fltLpFlashing, &flashing;, MG_NULL);
That doesn't give any errors but it always returns zero (FALSE).
IÃ¢â¬â¢m seeing this problem in VC6
Which problem specifically? The original one where mgGetAttList was failing or the Runtime error problem?
The runtime error problem. I guess I'm missing the unique version of msvcr80.dll for VC6 but I have no idea where to find it. It's not on the API disk and it's not in the VC redistributable.
Well and truly stuck.
The VC6 version of the API does not use msvcr80.dll, it uses the VC6 version of the c-runtime DLL (msvcrt.dll). When Lars told you that the 3.5.2 patch does not apply to the VC6 version of the API this is because the VC6 versions of the API don't use embedded manifiests so they did not need to be fixed.
If you are still getting the message that msvcr80.dll is missing, your run time environment is not set up correctly. Nothing in the VC6 version of the API DLLs will be looking for msvcr80.dll. I suspect your runtime is still setup to find the VC8 versions of the DLLs.
Remember from past posts that just because you "link" with a certain version of the API does not mean you will be "running" with it. You might need to take inventory of your runtime environment to make sure the correct versions of the DLLs are found by windows when your app runs. This problem really has nothing to do with the OpenFlight API. It has all to do with the way you have configured your windows environment to run apps.
Here is a snippet from a past post that might help you: Note that this was originally written to address a similar (but related) problem. I have edited it a bit to reflect your specific situation.
Even though you compile and link with a specific version of the API, Windows might load a different version if your runtime environment is not set up correctly. In your case, you have linked with v3.5 VC6 but your app may be running v3.5 VC8:
First some background on how your app will "find" the API DLLs (and all other DLLs it depends on) when you run it on Windows.
On Windows, the OpenFlight API Dynamic Link Libraries (DLLs) are required when you run your stand-alone application. When you run your application, Windows searches for ALL DLLs (including the OpenFlight API DLLs) in the following sequence:
1. The directory where your stand-alone executable is located.
2. The current directory.
3. The Windows system directory. The Windows function GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The Windows function GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.
Also when your app calls mgInit, the API "echoes" out the version being run. Check the output of your program to make sure you see 3.5.1 to make sure you are running the API version you intend.
A useful Windows utility is "depends". You can run this tool on an executable file (.exe) and it will show you exactly which version of the DLLs will be found at runtime.
Don't fret, I believe once you correct (and fully understand) your runtime environment, you will make good progress.
Ok I think I know where I've gone wrong then. When starting with a blank folder and doing the empirical "run it and see what it complains about" technique, I've been copying the DLLs from my installed Creator 3.5 folder. I suspect those were probably built using a later version of Visual Studio and/or VC8 not VC6.
Would that explain why they're looking for msvcr80.dll perhaps?
I've stripped the path down to nothing so the only files my executable sees are those in the folder its in - we typically distribute the DLLs with the executables for these mini tools because it's the only way to guarantee 100% that the end user is getting the correct files.
I uninstalled the 3.5 API and re-installed it ensuring I installed the VC6 version.
Finally, in my blank folder with my executable, I copied in the DLLs from the 3.5 API (VC6 version) from this folder :C:\Presagis\OpenFlight_API_3_5\samples\apps\bin
Now all is well. I'm building in VC6, linking in VC6 and using the API DLLS that were built in VC6.
Thanks for grabbing the wheel and steering me in the right direction. I was way off road.
No sweat... this is a very common problem. We are always looking for ways to make this less painful for end users.
Hang in there!
Alright - I'm clearly an idiot because I've got the same problem back now.
Once I got everything working in VC6, my code would no longer read any of our extensions for whatever reason. I figured it was because of the mix of different versions so I did a clean sweep.
Installed Visual Studio 2008
Installed API 3.5 VC8
Installed the 3.5.2 API patch for VC8
Loaded my project - let it do it's thing and compiled it - no errors.
In my local folder where the executable is, I copied in the VC8 DLLs from the 3.5.2 API and my app errored out asking for msvcr80.dll again.
And back to square one - when I copy in msvcr80.dll, I get the runtime error.
I know for sure that I've linked with the new API, and that the DLLs in the folder where my executable sits are from the new API.
I also tried compiling a debug version and it errors out with the same problem - looking for msvcr80.dll and when I copy that file into the local directory, I get the runtime error.
Actually Chris, I think I am the idiot. I double checked the patch files you received and they are not correct. I believe I gave Lars the wrong set of files to give to you. Maybe you should not let me drive anymore :red:
I have located the "correct" patch. I am trying to contact Lars to get you an update. I would also be happy to upload onto an ftp site you might have. Send me e-mail directly and I'll upload the files there.
That's Ok - if you can put them in "my files" on the dashboard, I'll get them from there when ready.
Well I think I'm making progress. I installed the 4.0 API and compiled against that. Now my app compiles and runs OK but I've apparently lost the ability to read extended attribution.
When compiling against the 2.6API, I'm fine, but using the 4.0 API, the following error message gets spit out now for each node I'm querying with extensions:
W: Unable to get attribute value 6219:"NULL" [argument number 1].
The numeric value differs for each node and attribute type.
This is a result of the following line of code (for example):
mgGetAttList(rec, melLightVASIFlag, &vasi;, MG_NULL); // get VASI shading flag
My .h file with the definition for our extensions is the same - compiling without it shows all manner of errors during the build. But it seems like mgGetAttList and mgSetAttList can no longer read extensions. I know this can't be right so it's obviously something I'm doing wrong. (again).
Sounds like your extension DLL is not getting loaded.
Either it is not being found by mgInit or it is failing to load once found.
Take a look at chapter 22 in the OpenFlight API User Guide (Vol 2) for info on how plugins are loaded in your stand-alone program environment.
If you verify that the DLL is being found by mgInit but then still not loading, it could be that the extension DLL is compiled incorrectly. For example, I don't believe the VC6 version will load into the VC8 version of the OpenFlight API. You will need a VC8 version of the extension DLL.
Got it - thanks. I was still using MG_PLUGINDIR and it now needs to be PRESAGIS_CREATOR_PLUGIN_DIR
I think I've got all my ducks in a row. I'm just tussling with the openflight version right now - the API saves as v16.4 as default but I need both my backup file and the current file to be saved as v15.7 in this particular app.
This is the code I'm using and it seems to work - anything about this which looks dodgy to you? Basically I'm copying the open filename and appending a "~" to it, then exporting that and exporting the current file (instead of using mgWriteDb.
char *database = (char *)argv;
printf("File is about to be modified. Creating backup.\n");
mgrec *pDbackup = mgOpenDb(database);
mgExportDb(pDbackup,backupname, MEFN_OPENFLIGHT, MEFV_1570, MG_NULL); // export backup to v15.7
mgCloseDb(pDbackup); // file.
if (mgExportDb(pDb,database, MEFN_OPENFLIGHT, MEFV_1570, MG_NULL) != MG_TRUE)
cout << "ERROR: Unable to save model: " << argv << endl;
cout << "There are no changes required in this file: " << argv << endl;