Starting from a sample project
Instead of creating a new project it's much easier to start from one of the sample projects. I recommend using the DefaultTools sample as it contains a nice variantion of example plug-ins.
Duplicate the whole project folder and rename this folder to the name of your project.
Project settings
Before we go further it might be wise to test this our project. Compile the project to make sure it is working, it should run fine.
Debugging
Debugging isn't optional, it's what you'll need to test your code and find out any errors. Edit the export paths in your configuration to make sure the output plugin is put in the plug-in's directory of your Vectorworks user folder. The output is relative to the project's files, in my case this setting will do:
../../../../Plug-Ins
Add Vectorworks as the debugging executable and you are good to go.
Project name
In both Xcode and visual studio you can rename project files in case you really want to create your own module. You might need to rename some configuration settings as well to match your new name. I'll skip this step as the world wide web can help you with that.
Creating a plug-in
Create resrource strings
Head here if you need an introduction into plug-in resoures.
We need to define some new resource strings to match the tool/object name and it's parameters. Create a vwstrings file.
These strings can be referenced later as parameters and allows other persons to localise your plug-in. I make an habit of providing the localisation option for every string that is shown to the end user.
Creating the object generation files
The object we are going to create is a point based object. Lets duplicate the ExtObjThePoint.h/.cpp files. Give them the name of your object. In my case "Guideline.h/.cpp".
Make sure you also edit the include path in your .cpp file.
Before we start coding we better change the names of the used classes and namespaces to match a new, unique name. Find and replace is your friend here.
Definitions
Note that I use a definition "kStrGuideline_ParametricName" "and kStrGuidelineTool_UniversalName". I always create these definitions of parametric and tool names so it's easier to call them in other parts of our module without having to know the exact parametric name of the object. These kind of definitions should be put in the "PluginResource.h" header file. I generally place these definitions in that file, while other more in dept object based string definitions are placed in a designated resource file on it's turn included in the PluginResource.h resource file. For this simple plug-in we don't need the latter.
#define kStrGuideline_ParametricName "Guideline"
UUID
In Vectorworks, each tool/object/menucommand needs a unique identifier. Obviously you can't create 2 objects with the same ID. It is important that you change the UUID references into a new unused ID, otherwise I'm pretty sure VW will crash on startup.
Get your unique ID here: http://www.cesyam.fr/PHP/get_uuid.php
// {858af12b-0a62-487f-89e2-6942576e2889}
IMPLEMENT_VWToolExtension(
/*Extension class*/ Guideline_DefTool,
/*Event sink*/ Guideline_DefTool_EventSink,
/*Universal name*/ kStrGuidelineTool_UniversalName,
/*Version*/ 1,
/*UUID*/ 0x858af12b, 0x0a62, 0x487f, 0x89, 0xe2, 0x69, 0x42, 0x57, 0x6e, 0x28, 0x89 );
Object parameters and choices
I've setup the parameters and choices, should be easy to understand. Tweak it to your needs.
The resulting code
The recalculate event is the part where your object generation code will be.
You can ignore and remove the license code, which is a custom interface I use to verify my clients. In other words, this should be sufficient:
EObjectEvent Guideline_EventSink::Recalculate()
{
VWGuidelineObj Guideline(fhObject);
Guideline.DrawObject();
return kObjectEventNoErr;
}
The next tutorial will show how to create the referenced object class "VWGuidelineObj", we can finally start coding!