AC17 API - ACAPI_3D_GetCurrentWindowSight

[Anonymous]

ACAPI_3D_GetCurrentWindowSight parameters have changed from *short to **void. With AC16 a -1 short was return for non-3d sights. What is returned in the void** in AC17 for non-3d sights? Documentation provides no clues. (And I don't have AC17 yet to find out!).

Thanks in advance.

[PBartke]

You should check the return value of ACAPI_3D_GetCurrentWindowSight before using the sight. In case of non-3d sight it will return APIERR_BADWINDOW I think. The void** parameter won't change.

[Anonymous]

Thank you.

[Anonymous]

Another sight question.

AC16 had a function Modeler::Sight::GetSightPtr (currentWindowSightId) so you can get the SightPtr for the ACAPI_3D_GetCurrentWindowSight.

This call (GetSightPtr ) is no longer present in the AC17 API - how can I achieve the same outcome as in AC16 pls?

Thanks

[Anonymous]

In addition to the above, is ACAPI_3D_GetCurrentWindowSight actually returning a pointer to a Modeler::SightPtr now (int he form of a void **)? Any details on this appear to be absent from the AC17 API documentation.

Thanks

[Anonymous]

To save others some time working this out....the void** returned by ACAPI_3D_GetCurrentWindowSight appears to be in fact a Modeler::SightPtr, so it is possible to do the following:

	Modeler::SightPtr currentSightPtr;

	GSErrCode err = ACAPI_3D_GetCurrentWindowSight ((void**)&currentSightPtr);

Perhaps this is not in the doco because Modeler::SightPtr is undocumented.

[Tibor Lorantfy]

Hi,

here's a short example code to show how to use ACAPI_3D_GetCurrentWindowSight (and EXPGetModel which has been changed in AC17 API also).

       GSModeler::ModelFuncTable *funcTable = EXPGetModelFunctionTable (); 
       if (funcTable == NULL) 
             return APIERR_CANCEL; 
       GSModeler::Model::SetFuncTable (funcTable); 
  
       void*  currentSightPtr; 
       if (ACAPI_3D_GetCurrentWindowSight (&currentSightPtr) != NoError) 
             return APIERR_CANCEL; 
  
       GSModeler::Model model; 
       Modeler::Sight* sight = static_cast<Modeler::Sight*> (currentSightPtr); 
       if (EXPGetModel (sight->GetConstMainModelPtr (), sight->GetSunSettings (), &model) != NoError) 
             return APIERR_CANCEL;

Regards,
Tibor

[drjustice]

I would like to confirm that the code posted by paulk is indeed incorrect.

	
Modeler::SightPtr currentSightPtr;
GSErrCode err = ACAPI_3D_GetCurrentWindowSight ((void**)&currentSightPtr);

A Modeler::SightPtr happens to be a GS::SharedPtr<Sight>, which is not the same as a raw Sight* pointer.

Calling the code above will seem to work but in fact will produce memory corruption errors that are difficult to track.

Tibor's answer is better, although I have fixed my problem differently:

        void* dummy = nullptr;
        ACAPI_3D_GetCurrentWindowSight(&dummy);
        Modeler::SightPtr currentSightPtr((Modeler::Sight*)dummy); // init the shared ptr with the raw pointer

        ModelerAPI::Model acModel;
        AttributeReader attrReader;
        EXPGetModel(currentSightPtr, &acModel, &attrReader);

[Karl Ottenstein]

drjustice wrote:
I would like to confirm that the code posted by paulk is indeed incorrect.

You are responding to an 8 year old thread... is your comment really about the AC 17 devkit / API ... or about a more recent version?

[drjustice]

I am working on Archicad 24/25 plugin.

And I'm sorry about reviving this. I replied because I always assume that if I struggle with something, then others are likely to eventually struggle with it also.

And whenever I post questions, if I don't get answers and I eventually figure it out, I will post an answer online to my own question -- again for the same reason.

I could be lazy and just leave the thread unanswered with no solution (as many threads here seem to end up) but I actually take the time and make the effort to give back to the community.

BTW, I know it's unproductive to complain. But I wish the Archicad API was well documented, but alas this isn't the case most of the time.

Like, I don't understand why you have 12 different data structures that do the same thing, in different namespaces, some types that are classes but some that have constructors some that don't, some that use void pointers, some that use templates, some type names that are missing letters, some that you must initialize not with a constructor, but with BNZeroMemory, and that the SDK provides header files that are there for whatever purpose but that we're not allowed to use other than to make things compile, some classes that we are allowed to use but when you call some of their methods you get unresolved externals, and so on...

[Karl Ottenstein]

drjustice wrote:
ike, I don't understand why you have 12 different data structures that do the same thing, in different namespaces, some types that are classes but some that have constructors some that don't, some that use void pointers, some that use templates, some type names that are missing letters, some that you must initialize not with a constructor, but with BNZeroMemory, and that the SDK provides header files that are there for whatever purpose but that we're not allowed to use other than to make things compile, some classes that we are allowed to use but when you call some of their methods you get unresolved externals, and so on...

You could start a new topic in this Developer Forum about this... legacy API / API documentation. Some of the things are ancient...and have more modern wrappers now, but are still there for legacy support (without requiring heavy updates to add-on code), others are newer and more object oriented. Not being a profit center, a full, clean update of the API, data structures and documentation is not likely. Also, because it relies on proprietary code - and access to the actual product code - it is not something that can be made open source / community-driven either.

Thanks for your clarification that you are on the 24 and 25 devkits and that the old solutions as well as yours apply there. 🙂