This is the second article in my series about XP development. To understand this article properly, you should be familiar with the contents of the previous articles.

In this article, we’ll talk about how we can manipulate our drawing. In CC3+, a drawing is really a series of entities, so we are going to have a closer look at what an entity really is, how to create new entities in the map, and how to access and manipulate existing entities.


Everything in a CC3+ map is an entity; a symbol, a line, a landmass and so on. This term should be well known to all CC3+ mappers, as it is the term used in official documentation. However, it isn’t just these visible things that are entities, almost everything stored in a CC3+ drawing is an entity, such as a map note or an effect. We can view an entity as a data container for one specific thing or aspect of our map.

When working on an XP, you are almost always going to be handling entities. After all, manipulating entities is needed no matter what you want to do with the drawing, including extracting information from it, so understanding how to work with these is very important.

Continue reading »

Campaign Cartographer 3+ is a a very configurable and extensible program. In addition to the core program, users can purchase official add-ons, providing not just new artwork, but also new tools. Users can easily add new artwork such as symbols and fills, and many users with an artistic talent create such resources themselves and import into CC3+ for use with their maps. It is also easy for users to create their own drawing tools and organize symbols into symbol catalogs. For the more advanced users, it is possible to customize the menus and toolbars, and write macro commands which can be used to add additional functionality or automate tasks.
But, the most powerful option is the possibility of writing your own add-ons, or XP’s. While you can do a lot with macros, you are still limited to the commands actually provided by CC3+. Clever combinations of these commands can yield interesting results, but sooner or later you will run into things you can’t do. And this is where XP development comes in. By writing your own add-ons for CC3+, you get direct access to the building blocks of your drawing, and can write your own commands for CC3+ to do all kinds of stuff.
In this series of articles I will teach you how to write these add-ons yourself. A word of warning here; these articles will teach you about XP development, but I’ll have to assume you actually know something about programming, and in particular, C++. If you don’t know that, I recommend you find yourself a free C++ tutorial on the internet and start there before coming back, as you will have problems following the tutorials otherwise.

In this first tutorial we’ll look at how to set up your programming environment, as well as making our first code.

Note that you can easily find all the articles published in this series so far by using this link.

Continue reading »

When Simon and I discussed how to fully integrate the city creator, code named “Map Invoker”, the idea of it working like a Wizard surfaced. 

With a wizard like interface, each layer of objects (Waterways, Roads, Walls, etc.) would each be generated by a different page on the wizard.  A “generate” button would draw the objects directly in CC3.  If the results were not what the user wanted, the user could press the “generate” button again and the old objects would be removed and the new ones drawn.  Once the user liked the output, the “next” button would take the user to the next wizard page.

Now this sounded like a great design to me.  But …. I had some technical issues to overcome and some design work to make life a little easier.

The main technical issue was that the built-in dialog system was not made to ever run custom code and call XP functions while the dialog was still visible.  This was solved by using C# to write the Dialog code and communicating with CC3 via a simple callback class and a delegate.  I will go into this solution in depth in a later post.  Right now I want to go over the design work I did to make life easier passing data back and forth between C++ & C#.

Here is the diagram of my classes thus far.  They are simple value classes, with no behavior.  In a previous experiment, I created a REAL object (data & behavior) but because of the fact that a real class crosses native and managed code, it worked great in a all C++/cli environment, but I could not use it in C#.  So I decided to split data and behavior into two separate dlls.  The cc3objects.dll, a C# set of value classes and cc3actions.dll, the C++/cli dll that implements the behavior.


Now, what this does is let me create an entire object, or set of objects that can be directly converted to native CC3 objects.  So, I actually build my objects in C# then pass them to my C++/cli XP dll.  Plus, once I get done with this project everyone will be able to use these dlls.