Tools for WriteLog contest module development This repo contains:
- Source code for Visual Studio 2013 wizards that create WriteLog contest module implementations.
- Instructions for using Visual Studio 2017 Community Edition.
- The necessary header files and import libraries to build WriteLog contest modules.
Developing in VS 2013 targets only WriteLog version 12. (The VS2013 C++ runtime is not installed by the WL11 installer. Developing in VS 2017 targets both WriteLog 11 and 12, but you must arrange to install the VS 2017 runtime when your module is installed on WriteLog versions older than 12.40. Modules developed here might even work with WriteLog version 11, but that is not tested.
The wizards generate code that assumes the relative file paths set up in this repo: The Directory Structure
Is not part of this repo, but is in .gitignore. It is where you should have the VS File/New-project wizard place any newly created WL module development projects.
contains the source of the VS2013 module create wizard.
contains the source of the VS2013 project create wizard.
contains the source of the VS2017 project create wizard.
contains the source of the various headers and import libraries required by the generated project. These headers and libraries suffice for both WL11 and WL12 (and VS2013, and VS2017). You do not edit anything here, with one exception:
is where it is suggested you put your own common headers you want available across multiple modules. The wizards arrange for this directory to be in the include path for both C++ and .rc compiles, so this is a good place to put, for example, source code for any copyright or version information you want in common across your modules.
WriteLog/generated/ WriteLog/MmdCom/ WriteLog/wlogtools/
Don't touch these. It is also recommended that you not use any headers you find in there for your development because much of it is archaic. The reason the archaic stuff remains is to enable source-code compatible development of module developed using the old Visual Studio 6 wizard last updated in 2008 (and most of which dates from 2000--or earlier.)
You must already have VS 2013 and/or VS 2017 installed. The Community Edition 2017 is supported for WriteLog module development. It takes two wizard operations to create a WriteLog contest module: The wizards
- The WL12ProjectWizard (or wl12ProjectWizard2017) creates a skeleton project from the VS File/New-Project menu.
- The WL12ModuleWizard adds skeleton header/cpp/wxs files to such a project for a contest.
There are a total of four wizards: two each for VS 2013 and VS 2017, and follow the one-time editing instructions below. The instructions for deployment are almost identical for all. There is more than one way to accomplish deployment, but here is one that works and is minimally intrusive on your system. Deploying the wizards
The deployment of the WL12 Project wizard is the same for all Visual Studio versions, except substitute 2013 for 2017.
For all wizards it is not necessary to use Visual Studio to File/Open-Project of any of the
.sln/.vcproj/.vcxproj files in the repo Wizard/ folders. Doing so MIGHT cause VS to auto-magically
deploy the wizard in your
<MyDocuments> folder, which might or might not conflict with the instructions below. Of course,
if you don't like the way the wizards work, you are welcome to change them to suit yourself.
Visual Studio should have already created the directory Deploy the Project Wizard
<MyDocuments>\Visual Studio 2013\(or
\Visual Studio 2017\.) Create a subfolder named
\Wizards\and copy these 3 files (and only these 3) from the
WL12ProjectWizardrepo folder (or similarly named files from
- WL12ProjectWizard.ico or WL12ProjectWizard2017.ico
- WL12ProjectWizard.vsdir or WL12ProjectWizard2017.vsdir
- WL12ProjectWizard.vsz or WL12ProjectWizard2017.vsz
Param="ABSOLUTE_PATH = c:\wherever\WriteLogWizards\WL12ProjectWizard"
There is no need to copy the files out of your git work area.
Now File/New Project in Visual Studio should show this entry that wasn't there before. (This screen shot has both VS2013 and VS2017 wizards installed)
In order for the directory structure to match that assumed by the module wizard, when creating a new project, browse to the Projects directory in this repo (create it, if necessary), and turn off that Create Directory for solution check box.
For VS 2017 Community Edition
- Use the WL12ProjectWizard2017 for the project wizard as above.
- Use the same WL12ModuleWizard directory as for VS2013, but copy the WL12ModuleWizard2017.* files into VS2017's directory (see below.)
- The wizard creates a project that targest the Windows 8 SDK, but VS2017 does not install the Windows 8 SDK. The first time you build it, you'll either have to follow its instructions to "retarget" to the Windows 10 SDK, or else manually install the Windows 8 SDK.
Getting a new item into the Visual Studio Add/New-Item menu apparently cannot be done in My Documents like a project wizard. Its deployment requires administrator privilege. You must create files in the Visual Studio installation directory. The directory to find is: Deploy the ModuleWizard
In that vcprojectitems directory, you need two things:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcprojectitems(for VS2013)
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\vcprojectitems(for VS 2017)
- Create a folder named
- Into that same vcprojectitems folder, copy the file (unchanged) from this repo:
- WL12ModuleWizard.ico or WL12ModuleWizard2017.ico
- WL12ModuleWizard.vsdir or WL12ModuleWizard2017.vsdir
- WL12ModuleWizard.vsz or WL12ModuleWizard2017.vsz
2017. That .vsz file must be edited to correct the
ABSOLUTE_PATH. Again, there is no need to copy files out of the git work area: just point that vsz file to the appropriate subdirectory in your fetched copy of this git repo. Once installed, and in Visual Studio with a WL project open, a right mouse click on the project looks like this:
- Rtty Support adds the interfaces that the RttyRite window needs to fully support highlighting and clicking into WriteLog's Entry Window.
- Cabrillo Support adds enough cabrillo support for basic export.
- NR in exchange instructs the wizard to add an NR column to the log.
- Pts Column adds a column to the log to display the points claimed for each QSO.
- RST in exchange adds sent/received RST columns to the log.
- Mode support selects among 3 choices.
- compiled-in The modes (CW/SSB/RTTY) are decided at compile time. Many RTTY contests are examples.
- ask at startup For a given weekend, only one mode (or set of modes) is allowed, but you need to ask the user which. Think ARRL SS CW versus SSB.
- multi-mode means that the contest rules are that on a given frequency band, contestants can make separate QSOs for credit on multiple modes. Think IARU HF.
- DXCC means the contest counts DXCC countries as multipliers, and the wizard generates code for the case of countries as mults once per contest, or once per band.
- Zones means the contest counts zones as multipliers. The wizard generates support for zones 1 - 40 (per CQ zones) but you can change this to use ITU zones instead.
- Mults as you go means that every unique string logged for a field is a separate multiplier, but you don't know when the contest starts what they're going to be. This can be used for logging those contests where the "headquarters stations" are their own multipliers. WPX also works this way.
- Named Mults means there is a list of strings (like state names, or whatever) that are the multipliers for the contest. You will need to create (and distribute) an INI file that has the multipliers in it along with any ALIAS names you want to all refer to the same multiplier
- Contest Display Name is what the user will see in the WriteLog Select Contest list.
- Class Name is the name of the C++ class to be generated. The wizard has to generate a name for the corresponding COM coclass which it does this way: if you start the name of the class with a "C" (capital C) then the coclass is the name of the C++ class with no leading C. Otherwise, the name of the coclass is the name of the C++ class with CoClass appended
The wizards described above generate code for a WIX installation using the kits available at Installer supporthttp://wixtoolset.org/. Installing the WIX tool set after Visual Studio will result in Visual Studio support for WIX installer projects. While the dll's created by the wizard support self-registration, that is not a recommended means for registration when deployed on customer machines (but its fine for use in development.) For customer depoloyment, use the .wxs files generated by the WriteLog wizards to create an msi installer for your module.
Generating the installer is not fully automated by these wizards. The Project wizard generates a product.wxs suitable to be added to a "Windows Installer XML" Setup project. And the Module wizard generates a .wxs suitable to be added to that same Windows Installer project. But these .wxs files are just "loose" in the dll's project--they are not referenced by or needed by the dll project. This readme does not attempt to document how to use the Visual Studio support for the Wix installer. This is just enough information to get you started.
Create the installer project after you have done a successfull Release build of with all the contest modules you want in your project dll. The relative include paths in the generated .wxs files assume this new installer project is placed in the same Projects/ folder as the module projects. Use Visual Studio File/New-Project and choose "Windows Installer XML" and "Setup Project".
The Visual Studio wizard generated a file named product.wxs that you discard. Replace it with the product.wxs moved from where WriteLog Product wizard generated it. At the same time, move the .wxs files that the WriteLog Module wizard generated.
With the installer project open in Visual Studio, do a right mouse click on the install project and Add/Existing-item and add the .wxs file. The project also needs a Reference to WixUIExtension that comes with WIX.
Edit the various TODO's in the two wxs files. (Or more wxs files if you put support more than one contest in your project).
There are a handful of bugs in the header files generated using the old Visual Studio 6 WriteLog contest wizard. It is recommended that any new work on those old modules be done using the software development environment published here, and with Visual Studio 2008 (or VS 2013 if WL12 and later support is all that is desired.) Start by placing the old module's source code in its own new folder under Projects in the directory tree created by this repo. You do not run any of the wizards in order to rebuild an old project. This exercise is just to use the latest versions of the header files, which have some templates and preprocessor directives that have been improved since the VS 6 wizard was deployed. Source code changes required for older modules
There are a couple of source code changes required in old modules to make them compile in this updated environment:
- Place the old source code directory in the new Projects folder here.
- The include path structure has changed. The easiest way to deal
with this is to edit only the .vcproj as text.
- Replace this:
- Similarly, replace
- This one is slightly different:
- Finally, to the include file paths, add this directory which did
not appear in the old wizard:
- Replace this:
- The clsid.c file won't compile anymore. Because it references headers that now only work in C++. Using the VS Solution explorer, rename it to clsid.cpp.
- clsid.cpp still might not compile if the <projectname>mm.h file won't compile stand-alone.
One simple way to fix this is to split out from <projectname>mm.h the bit that clsid.cpp needs
into a separate file.
- Create a new header file named, say, <projectname>guid.h.
- Cut from <projectname>mm.h all the lines that look like this:
DEFINE_GUID(CLSID_EuRttyMmd, 0xC7212160, 0x7716, 0x101A, 0xAA, 0x54, 0x00, 0x60, 0x8C, 0x61, 0xD0, 0xB1); /* C7212160-7716-101A-AA54-00608C61D0B1 */
- and paste those lines into <projectname>guid.h
- Update <projectname>mm.h to #include the new guid.h
- Change clsid.cpp to #include the new guid.h instead of mm.h.