Custom C plug-in works in 2018, not 2019 - where to put it?

[DanRathbun]

So I’m still thinking … “What changed between v18 and v19?”

And I just remembered that the C API had a build bug that was NOT exporting the symbols properly for the Mac. (The Windows build was always fine.) They just noticed it the past few months or so. The latest version 19.2 (C API Version 7.1) is the only one that has the symbols correctly exported in the libs.

@drwave I betting that this is the difference you are seeing.
Which also means you’ll be needing to release 2 versions (one for pre-2019 and one new build linking to the proper libs for 2019+)

---

REFS:

Loading a bundle with Ruby on MacOS?

Note that we’re currently missing the C API symbols in the SketchUp application. All except the SUGetExtensionLicense. What we see people have done is link against SketchUpAPI.framework - but that shouldn’t be done. You end up with duplicate symbols and linking to the standalone lib instead of the app. It will appear to work in many/most cases, but eventually you’ll run into crashes and incorrect behaviour. We’ll be making sure the symbols are correctly exported in upcoming release. We used t…

Best practice to support multiple SketchUp versions?

Are you linking against sketchup.lib or SketchUpAPI.lib? The former links to the C API within Sketchup.exe, the latter links against the standalone version. Mixing those two doesn’t work well. If you need to use features from the C API released with SU2018 with older versions you have to look into some other way of communicating with the C API. I’m afraid that function was neglected for a long time so it’s not reliable for older versions I’m afraid. That should be fine - the main thing to …

@tt_su

For the record, in regard to the Live C API in general:

The read-only live C API wasn’t really complete until SU2019.2 that was just released. While the symbols has been exported on Windows a couple of versions ago, mac did not export the C API symbols from the SketchUp app.

People working with the live C API on mac up til now have been linking against the standalone SketchUpAPI.framework which have appeared to mostly work. But this isn’t the correct way to consume it, and will lead to incorrect behaviour (such as not getting the cutout holes in faces) or in some cases crashes (SUSectionIsActive for instance.) Since it mostly appeared to work, this went under our radar.

We will provide better documentation to how the Live C API should be consumed. What we currently have is the licensed_ruby_extension example in the SDK package. But it’s not clear exactly what is going on. I’ll describe below - and we’ll get this documented publicly.

Windows:

Link against sketchup.lib.
If you link against SketchUpAPI.lib (the standalone version) you will run into the same issues as described before.

Mac:

Don’t link against SketchUpAPI.framework - due to same issues as above.
Instead add the path to the SketchUpAPI.framework to you Framework Search Paths in your Xcode project. This will allow Xcode to locate and use the header for the API.
To allow the project to build you must set the Bundle Loader to the path of the SketchUp application on your machine. Xcode will use the symbols exported from that binary when it links.

Both of the above is demonstrated in the licensed_ruby_extension (just not explained in detail).

Additionally we added SUApplicationGetActiveModel as the official way to obtain the model pointer for live C API. This saves you from doing the boilerplate of calling Ruby and interpret_cast’ing the pointer address. We will leave model.skpdoc(true) working! For backwards compatibility with existing users of the API. But going forward you should prefer SUApplicationGetActiveModel .