It does not sound like you are doing anything wrong. Any chance of getting the code to run through?
Simply using mgOpenDb and then immediately saving with mgSaveAsDb on a file that has externals truncates the file. If I do the same thing on a file WITHOUT externals, there are no issues.
AND if I open FLT1, save as FLT2. Open FLT2, save it as FLT3. FLT3 is truncated even more...
Using Borland C++ Builder 2007. I have converted the COFF 'lib' files to OMF using Borland's coff2omf convertor. Also tried recreating the lib files using Borland's implib program. However, the DLL's are UNCHANGED from the 'stock' API.
This happens with API 401 and API 32.
myDb = mgOpenDb(FLT1);
seem to be getting an 'Invalid Floating Point' error when using mgSaveAsDb, mgWriteDb and mgExportDb...
Going to try using the system LoadLibrary routines instead of the lib files...will see how that works.
I certainly don't see this using Visual Studio 2005 (for which the distributed lib and dll files are intended). I've never used this modified configuration you are using so I'm sorry I am not much help.
Perhaps there is something suspect in the original OpenFlight files. If you post FLT1, I'd be happy to take a second look.
Sorry, can't post the FLT files...
Historically, there have been no issues with using MS-generated DLL's with Borland tools. Just create the new LIBs and everything works...simple.
It would probably help to get a peek at the source for the DB 'save' routines, that might shed some light on why those crap out with the Borland tools.
Are the DLLs using the FILE* type?
I understand if the FLT files contain sensitive data. Can you manufacture a "sanitized" version that shows the problem so we could have a look?
Can't sanitize the existing FLT file, so we will have to play things by ear.
Remember, the Floating Point error occurs no matter what type of FLT file I use...
Am going to try VS 2005 and see if I can duplicate the errors there...
Let me restate my suggestion... Perhaps you could manufacture (from an empty file) a test case that shows this. If you can with, say, models from the Creator gallery for example and you still have the problem, it might tell us something. If you can only reproduce the problem with "your" data then the problem might be the data itself.
In other words, can you fire up Creator, make a new file, add two trees x-refs from our gallery and then try your test on that file?
I will see how that works.
I cannot create a test file for you, as my Creator is on a classified system.
Attached are the OMF versions of mgapilib.lib and mgdd.lib as converted by Borlands COFF2OMF tool.
See what you think...
Just to set your expectations... I'm not sure what to do with these files. The sample I really wanted was the API based program so I could check to see if it had a problem in the Visual Studio environment. If it runs there and not in the Borland environment that would give us a clue as to how to proceed.
As we don't have a Borland dev environment here, again, I'm not sure what help we can be.
So when you convert files from VS to Borland, all you have to do is convert the .lib files? What about the DLLs? Note that there are many DLLs comprising the OpenFlight API, not just mgapilib.dll and mgdd.dll. If you have to perform some magic on the DLLs make sure you are waving your magic wand over them all. The complete set of DLLs are found in samples/apps/bin in the SDK.
Looks like you're gonna end up finding out the solution by yourself. I can't seem to find any problem with it too.
First, when using MS-Style DLLs in Borland projects, the only conversion is to the LIB files. The DLLs are left alone...
I couldn't figure out where the problem is with the LIBs, so I tried the same with MS VC++...with no issues. Not being a big MS fan, I also tried doing it with QT Creator from Nokia (Nokia bought TrollTech and 'open sourced' QT).
QT Creator works wonderfully with the 'as is' LIBs and DLLs...so for this project, I am using QT and 'abandoning' MS and Borland...
I am working on a stand-alone program that will duplicate & read a FLT file, gather all refereced textures and externals, copy all files to a new location and then update the FLT file to point to the new textures and externals.
Everything works fine with the textures...the problem is with the externals.
I open the FLT file, use mgWalk (with the MWALK_MASTER flag set) to visit each node and check if it is of fltXref type.
If I find a fltXref node, I grab the filename using mgGetAttList, copy the external to my new location, then update the node to point to the 'new' external using mgSetAttList.
I get good status back all along the way.. until I save the FLT file with mgWriteDb. When I do this, the external nodes in the new FLT file are DELETED.