Developer forum
cancel
Showing results for 
Search instead for 
Did you mean: 

AC17 API - ACAPI_3D_GetCurrentWindowSight

paulk
Newcomer
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.
10 REPLIES 10

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

paulk
Newcomer
Thank you.

paulk
Newcomer
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

paulk
Newcomer
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

paulk
Newcomer
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
Graphisoft
Graphisoft
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
Newcomer
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
Moderator
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?
One of the forum moderators   •   AC 25 USA and earlier   •   MacOS 11.6, iMac Pro

drjustice
Newcomer
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
Moderator
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. 🙂
One of the forum moderators   •   AC 25 USA and earlier   •   MacOS 11.6, iMac Pro

Still looking?

Browse more topics

Back to forum

See latest solutions

Accepted solutions

Start a new discussion!