Hot Door CORE Forum

In creating a plugin too large to be practical in one source file, would you recommend breaking some segments of the code into separate classes and use calls such as hdi::core:lugin::instance() to reference the main plugin to create callbacks, tools, menus etc. in methods called by the main plugin at startup, postStartup, shutdown, etc.? Or would it be better to just put it in separate source files and include them as was "toolFormatting" in the Tool sample?

A lot of sizable chunks of my code are reused in different plugins and as I rewrite them in CORE it would again be helpful to take a modular approach.

That pretty much comes down to personal taste and/or what you find is best for your workflow. However, I am of the opinion that modularization is always a good way to hedge your bets.

For example, we basically modularize by feature. The plugin itself is its own class (like the CORE samples), all tools are their own individual class, all panels are their own individual class, etc.

Thanks, Garrett. Modular is my preferred way of working--I really learned to embrace it when using Xojo for utility apps. C++ for Illustrator plugins is a bit different from the focus of most books or classes, and I find I have to sort out what applies and what doesn't, and figure out what's missing. Maybe it's just the mystery of not knowing exactly what's going on behind that Adobe curtain, but AI plugins seem considerably more fragile than standalone projects I've done. As a result, I may be over-cautions and apologize if I ask too many basic questions. I'm currently copying the Skeleton project and keeping the skel class as-is, adding all of the real work into classes. To communicate back to the main Plugin class I find it simplest to just use skel::, etc., but hdi::core:lugin::instance() was obviously written for a reason; when should it be used instead? Thanks -- Rick

The hdi::core:lugin class is there to allow for basic plugin-level functionality, and of course its instance is necessary during startup to register your various callbacks. Otherwise, additional plugin-level functionality is up to you to provide wherever you find best for your workflow and/or the needs of your plugin. If you choose to do that via subclassing the hdi::core:lugin class, wrapping the hdi::core:lugin class, or altogether leaving hdi::core:lugin alone is up to you.

In the samples, their *:lugin classes are not there instead of hdi::core:lugin. It's more like in addition to.

After writing plugins for eleven consecutive versions of Adobe Illustrator, it feels like CS6 has dealt me such a blow that I'm struggling to learn to walk again. Inching along with baby-steps in CORE, I've made a simple class that handles a custom About box. After copying the Skeleton project, it creates the About class just before creating the skel object:

About* myAbout = new About;

skel then calls it to do its tasks at startup, shutdown, etc., the new class installs an about menu and its own menu callback to pop up an alert-style box. That works like a champ.

Moving on to a more sophisticated dialog, I defined a simple modal dialog with a couple of widgets as shown in the tool sample, but when the callback goes to:

this->AboutMD.show();

That does nothing. Thinking I may have better luck, at least for this instance, using:

this->__Plugin->setAboutBox(&AboutMD);

My About class can't assign a value to __Plugin because it knows nothing of the skel namespace nor the skel:lugin, nor can I find any way to make use of hdi::core:lugin::instance() or SKEL_PLUG_INST to find the root plugin. skel:lugin can't set About's __Plugin pointer because because of a type difference I can't resolve. I can apparently use menu callbacks in my own classes, but I'm not so sure that'll work with dispatchers, etc.

I hope someday Hot Door will consider revising a sample project, moving some of the members and methods to one or more separate structs and classes.

I love "ah-ha" moments! After hours of studying every reference to dialogs in every header in the CORE headers, I noticed that the tool dialog wasn't declared in the .h file, which led me to notice that I had carefully copied the instantiation of the tool dialog from the tool sample. Thus:



should have been


The tool stored the pointer to the sample's dialog, but my class needed to store its own pointer.

Now I look forward to making real progress again, at least until I need to reference back to the Plugin instance.