moving 8.1 projects to 9.0

[Anonymous]

Time has come for my API tools to get upgraded to 9.

New CPU, new VS (.net 2003), new apidevkit (6.1).

The standard examples seem to compile well, HOWEVER, my existing projects have some problems (and I only started the windows side:)

The first hurdles were relatively easy (the earlier wizard created absolute path references, so GRC compiler, the Support/Modules, etc had to be corrected for the custom build step/ additional source folders list...

Some puzzles still remain:

Project 1:
-------------------
link errors: unresolved external symbol:
_WriteReport
@ErrorBeep@8
_WriteReportAlert
@ClickAnElem@24
_WriteReport_End

These from modified versions of DumpBody, Do_TriangulateSlab, Do_Get3DOfClickedElem routines which were snipped (for 8.0-8.1) from the 3DUtilities example.

Project2:
--------------------

error C2248 'Geometry::Real::value' cannot access private member declared in class 'Geometry::Real' c;\api61\support\modules\geometrylib\real.hpp(253): see declaration of Geometry::Real::value Line 393, 399, etc.


(sorry being libearal with the uppercase/lowercase but I'm typing this on a powerbook, watching the windows xp pro screen. (that machine is safely off the internet)

Any ideas anybody?
(and I thought it will be a "simple" recompile.... (:

[Karl Ottenstein]

Andras wrote:
My guess is that a compiler or linker flag is at fault. Try generating a default project with the AppWizard and compare the flags with the flags in your project.

If nothing else works, try creating a new API project, adding your files to it and recompiling.

This advice is what was most useful to me in the past when moving projects from one release to another and encountering build errors.

I actually took the latter route: using AppWizard to create a blank project and adding my files to it. Was the least effort compared to tracking down all of the settings. (Life was easier with old fashioned makefiles in some ways.)

Karl

[Anonymous]

This project imports the Excel type libraries for some COM operations (Driving Ms Excel:) and that seemed to conflict with the VC7 type libraries.

The problem was partially solved by commenting out the #include <atlbase.h> line. That misteriously solved seemingly unrelated (real.h) error messages too. I meant to use some map, collection, etc. templates, but not yet implemented in this project.

Starting afresh with new API versions is last resort, usually I try to change one thing at a time. I wonder if the Examples are updated the same way.
This kind of stuff makes development more of a puzzlesolving than a planned and organized craft. The causes and effects are not clearly identified and separated. I think this API DLL development is not in the mainstream of the VS.net target and the peripheral of the apps are not very well/done tested.

Currently the only mistery left is that the pSheets= pBook->Worksheets;
statement returns 0x0000 in pSheets, while it was working with VC6 version, and pXL->Workbook and pXL->ActiveSheet returns the correct book and worksheet respectively.

[Anonymous]

Happy (kinda) end: solved the excel mistery, so it is working now.
The debug runtime complains about some corrupted stack around qSlab, qFill, qMesh property variables, so ACAPI_Get_Property calls might have some sideffect, but luckily it doesn't seem to be a problem there.
Projects are updated -at least on the windows side: mac to follow as time allows.

In summary version update meant:
-weeding out WriteReport and ErrorBeep deprecated function calls
-update references in the project properties/Additional Includes to find {API}/Support, /Support/Modules and {Compiler}/Include, {Compiler}/PlatformSDK/Include etc.
-update target applications/exe s
-Change some 81s to 9 in the target names

The rest was Microsoft (VS/Office) related mess/confusion.