topic Re: moving 8.1 projects to 9.0 in Archicad C++ API

moving 8.1 projects to 9.0

Anonymous — Tue, 13 Dec 2022 21:34:55 GMT

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

Re: moving 8.1 projects to 9.0

Oleg — Wed, 16 Feb 2005 18:34:06 GMT

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.

Re: moving 8.1 projects to 9.0

Anonymous — Wed, 16 Feb 2005 18:54:28 GMT

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

Re: moving 8.1 projects to 9.0

Oleg — Wed, 16 Feb 2005 19:12:15 GMT

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.

Re: moving 8.1 projects to 9.0

Anonymous — Wed, 16 Feb 2005 19:41:59 GMT

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

Re: moving 8.1 projects to 9.0

Oleg — Wed, 16 Feb 2005 20:07:09 GMT

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.

Re: moving 8.1 projects to 9.0

Anonymous — Wed, 16 Feb 2005 22:18:15 GMT

Well,

fatal error C1189: #error: "valid"

.....

Re: moving 8.1 projects to 9.0

Oleg — Thu, 17 Feb 2005 06:06:36 GMT

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.

Re: moving 8.1 projects to 9.0

Andras Babos — Thu, 17 Feb 2005 13:35:48 GMT

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.

Re: moving 8.1 projects to 9.0

Anonymous — Thu, 17 Feb 2005 17:21:57 GMT

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

Re: moving 8.1 projects to 9.0

Karl Ottenstein — Sat, 19 Feb 2005 05:32:49 GMT

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

Re: moving 8.1 projects to 9.0

Anonymous — Sat, 19 Feb 2005 18:14:40 GMT

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.

Re: moving 8.1 projects to 9.0

Anonymous — Sun, 20 Feb 2005 04:51:57 GMT

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.