About   |   Getting Started   |   Downloads   |   Documentation   |   Forum


Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
recommended practice: classes or includes?
05-06-2016, 05:14 PM
Post: #1
recommended practice: classes or includes?
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::Plugin::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.
Find all posts by this user
Quote this message in a reply
05-09-2016, 10:19 AM
Post: #2
RE: recommended practice: classes or includes?
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.
Find all posts by this user
Quote this message in a reply
05-09-2016, 10:49 AM
Post: #3
RE: recommended practice: classes or includes?
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::Plugin::instance() was obviously written for a reason; when should it be used instead? Thanks -- Rick
Find all posts by this user
Quote this message in a reply
05-09-2016, 11:46 PM
Post: #4
RE: recommended practice: classes or includes?
The hdi::core::Plugin 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::Plugin class, wrapping the hdi::core::Plugin class, or altogether leaving hdi::core::Plugin alone is up to you.

In the samples, their *::Plugin classes are not there instead of hdi::core::Plugin. It's more like in addition to.
Find all posts by this user
Quote this message in a reply
05-21-2016, 11:09 AM
Post: #5
RE: recommended practice: classes or includes?
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::Plugin, nor can I find any way to make use of hdi::core::Plugin::instance() or SKEL_PLUG_INST to find the root plugin. skel::Plugin 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.
Find all posts by this user
Quote this message in a reply
05-22-2016, 09:43 AM
Post: #6
RE: recommended practice: classes or includes?
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:

Code:
hdi::core::ModalDialog AboutMD(...


should have been

Code:
this->AboutMD = hdi::core::ModalDialog(...

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. Undecided
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)