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.... (:

[Oleg]

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

I can not help actually. I feel that reasons of both are simple, but it is hard to assume something certain.
Project1. I think you need attentively make sure that CPP source codes of these functions are really included to the project.
Project2. It is strange. I have just tried "IsNear" function with "Real" arguments. It was compiled.
I have just one fantastic idea if you somewhere have casually redefined the _MSC_VER value less than 1310 which should be for VS2003.

[Anonymous]

Thanks Oleg,

After sleeping on it, the Project1 problem is coming from a using a code segment from a 5.1 (4.2) api example, and probably I was using a deprecated method to write into the report window. (I might need to check out the @Clicked2D element and similar..), but that should be easy to fix.

On Project2 I will check the MSC_VER thing by finding and comparing to the 6.1 examples. that would be neat if it were that easy. It is not that I have it overwritten, but (since these are coming from 7.0-8.0-8.1 where VC 6.0 was what the doctor ordered) I need to update these.

That also would be an easy fix, maybe it should be mentioned somewhere in the dev doc. Where did you find it?

migrating to VS.net 2003 has another inconvenience- it looks like the vc7 libraries are incompatible with the mso9.dll, excel9.dll, vbeext6.dll which is necessary to drive Excel 2000. I'm trying to track this down on the MSDN forums...

[Oleg]

Ferenc wrote:
That also would be an easy fix, maybe it should be mentioned somewhere in the dev doc. Where did you find it?

I didnot find it anywhere. It was just just idea after i tried to reproduce the error. I have defined MSC_VER and then this errors arised.
Actually MSC_VER never defined by hand as it is special macro defined by the compiler at compilation. Therefore the idea ptactically unreal.
But .... life is life all happens.

[Anonymous]

So which file should it be in (rc2?), to edit it manually?

[Oleg]

Ferenc wrote:
So which file should it be in (rc2?), to edit it manually?

Try before a small experiment to check MSC_VER value.
Try to add temporary following to the CPP where you use the Geometry::Real and Geometry::IsNear ( source the errors ).
After other includes especially Geometry.hpp or Real.hpp.

#if _MSC_VER < 1310
#error "Wrong"
#else
#error "Valid"
#endif

And compile that CPP. You got the error anyway. The debug output window will contain Wrong or Valid string, so you will check MSC_VER settings.
If it is Valid then a reason is not MSC_VER.

[Anonymous]

Well,

fatal error C1189: #error: "valid"

.....

[Oleg]

Ferenc wrote:
Well,

fatal error C1189: #error: "valid"

.....

Then the idea on MS_VER was false and it is not that reason.
Sorry, I have no another idea.

[Andras Babos]

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.

HTH.

[Anonymous]

Oleg, thanks for the help, don't worry, I've found you try about 7-10 things which don't work during troubleshooting a problem.

I will try the compiler flags too, but the since I got Project1 up and running now (same general vintage VC6 project), I doubt that is the problem. I've created the baseline empty project now, but it is major code cut and paste, and in an ideal world I like to keep code revisions and version upgrades separate (orthonormal:) to ease troubleshooting.

If all else fails, I will do the code cleanup and version switch together, but it is generally easier when only ONE thing changes (API version, OR VS version).

The incompatibility between Office 2000 and VS.net 2003 libraries is bigger concern at the moment. I will try with Office XP, but there is a chance that Microsoft deprecated the COM interaction method, (go XML- .net ...)

Anyway, please share tidbits you've discovered during upgrade process (intra GS or extra GS), why suffer twice....