Salmon Run Site Location

“The Wheat Field” is what the USGS map says our Salmon Run location is. From the photos, it doesn’t look like much wheat is there at all.

USGS Quadrangle Snip

In this picture, you can sort of see the end of the Forest Service road that leads up to the camp.

The US Geological Survey provides quadrangle maps for free. This fantastic service lets you view maps in PDF format that used to require a trip to the library or some money for the map on paper. Armed with these maps and Google Earth, you can plan your own county expedition and perhaps you will own Salmon Run this year or next.

Salmon Run 2009 With N7PP

The N7PP multi-two county expedition will be in Columbia county this year. We will be camping again this year but about 1,000 feet lower than last year.

View a Map

From the photos, the site looks beautiful with scrub pines and a grassy meadow. I suspect we will practically own the Salmon Run this year. Maybe a big county expedition will find a county location and roll over the whole thing.

I built a PFR-3

I struggled with the construction of the PFR-3 I received for my birthday. I really wanted to get it done two weeks after getting it so I could take it with us on a camping trip but could not get enough hours in a row to do it. Chuck, AC7QN, loaned me his for our camping trip. I contacted W7GKF/MM who was riding on a ferry sailing out of Ketchikan AK. Bill was running 1 watt which made my 5 watts QRO! I made an easy 599 contact with KL7DX and a tough one with WA0JLY in CO. For an antenna, I hung up a field day special doublet in the trees around our camp site. Good fun. Once I got back, my build didn’t go so well. I had an intermittent problem that I couldn’t pin down so I sent the rig off to KD1JV for the $35 fix. Steve found the DDS chip (on of the pre-soldered surface mounts) had a bad solder joint — that one was on him. He also found that X2 was shorted — that one was on me. So he split the fee and sent me back an aligned, tuned, working rig that puts out 5W on all bands. Better than if I had finished the job myself. I banged out a couple of contacts on 20M during the NAQPCW and I’m pleased as punch.

Some talk on the PFR-3 reflector has been about driving a speaker and the low audio output. I found a little amplified speaker with an internal Li-ion battery that works FB. Search for “Super Mini Sound Box Speaker with Li-ion Battery” on ebay. I got mine from one of those ‘daily deal’ web sites but the same exact thing can be found easily. This is almost exactly the one I have:

PortableSpeaker

Price at the time I’m writing this is $12.32 with free shipping from Hong Kong. Although I haven’t bought from this particular seller, I’ve purchased items from Hong Kong electronics purveyors before and it takes a while but the merchandise has always come in as advertised. Hey, if you can cut out the middle-Mart, why not. This speaker fits in nicely with the PFR Paddle and doesn’t get in the way at all. The sound quality is pretty good and plenty loud without modifying the audio amplifier in the PFR-3.

I have one small complaint about the PFR-3. The run of cases with the lettering silk-screened on them are gone. Now you get a painted case and a page of water slide decal lettering. It looks pretty good but even after 4 coats of clear Krylon paint, I’m afraid the letters will scratch off. Still, I’m not complaining too loud because the rig works and looks fine.

WriteLog Contest Module Development – New Free Tools

I didn’t think it could be done but leave it to clever programmers…. You can use the free Microsoft Visual C++ Express Edition to compile WriteLog mult-modules! Follow the instructions in this Code Project page. NOTE: the WriteLog Contest Wizard with *NOT* run because it does not work with Visual Studio 2008. I installed VC++ Express, the Windows Server 2003 DDK, and made the minor changes that were needed to a couple of header files described in the Code Project instructions. With Visual Studio setup and the Windows Server 2003 DDK installed, the modules compile without errors and will actually work in WriteLog. You need a resource editor as well because the Express editions of Visual Studio don’t come with one. There is a terrific free resource editor you can use for this called RedEdit. This is a great solution if you want to just poke around a bit without investing in a license for VC++ 6.0. Just download the demo module I’ve been writing about to get started.

WriteLog contest module development – Part 6: Contest Parameter Dialog Box

In the last part, I posted a link to the source code of the module up to this point. The code compiles and creates a working module. Have a look.

The contest module needs some information from the op, namely their SKCC number and QTH. This dialog box is in the resources for the project. Edit the dialog box so that it has two fields, one for QTH and one for SKCC number. Change the style of the input boxes for uppercase entry.

Create an identifier for the input field IDC_SKCC. Leave the ID for the QTH as IDC_MYMULT. Please be diligent and set the tab order for the inputs and buttons. Search for m_MyMult in all files and in the class implementation, create the new property for SKCC everywhere m_MyMult is found (just going down the list of what was found). Duplicate the action taken with m_MyMult for m_MySKCC. For example, in the ScoreDlg() method, add the lines for the contest parameters.

int
CSKCC_WES::ScoreDlg(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
int Command;

switch(message)
{
case WM_INITDIALOG:
SetDlgItemText(hDlg, IDC_MYMULT, m_MyMult);
SetDlgItemText(hDlg, IDC_MYSKCC, m_MySKCC);
Edit_LimitText(GetDlgItem(hDlg, IDC_MYMULT),
sizeof(m_MyMult) - 1);
Edit_LimitText(GetDlgItem(hDlg, IDC_MYSKCC),
sizeof(m_MySKCC) - 1);
return TRUE;

case WM_COMMAND:
Command = GET_WM_COMMAND_ID(wParam, lParam);
switch (Command)
{
case IDOK:
GetDlgItemText(hDlg, IDC_MYMULT, m_MyMult, sizeof(m_MyMult));
GetDlgItemText(hDlg, IDC_MYSKCC, m_MySKCC, sizeof(m_MySKCC));
case IDCANCEL:
EndDialog(hDlg, Command);
return TRUE;
}
break;
}
return FALSE;
}

Change the UserWrite() and UserRead() methods to save the new property when the contest is saved to a file.

HRESULT
CSKCC_WESPersistStore::UserWrite(IStream FAR *s)
{
HRESULT hres = S_OK;
CSKCC_WES FAR *Mmd;
Mmd = (CSKCC_WES FAR *) UnkOuter;
hres = s->Write(Mmd->m_MyMult, sizeof(Mmd->m_MyMult), NULL);
hres = s->Write(Mmd->m_MySKCC, sizeof(Mmd->m_MySKCC), NULL);
return hres;
}
HRESULT
CSKCC_WESPersistStore::UserRead(IStream FAR *s)
{
HRESULT hres = S_OK;
CSKCC_WES FAR *Mmd;
Mmd = (CSKCC_WES FAR *) UnkOuter;
hres = s->Read(Mmd->m_MyMult, sizeof(Mmd->m_MyMult), NULL);
hres = s->Read(Mmd->m_MySKCC, sizeof(Mmd->m_MySKCC), NULL);
return hres;
}

The secret to prompting for contest parameters on opening a new contest

Call the Score(Configuration_Entry_t *, HWND, int, const char *) method with null parameters. The InitQsoData() method seems to be a safe place because the contest log has been initialized. If you do this in InitQsoData(), you can check to see if the contest parameters have been set because either the op read in a saved log or they started a new one. Use a global flag to make sure you don’t repeat the prompt when InitQsoData() is called again. I created a class property called m_ParamPromptDone and initialized it to 0 in the constructor and flipped it to 1 after I prompted for parameters. That way the prompt only comes up when blank and hasn’t been presented to the op yet when the log is first created or opened. Just don’t save that property in the UserWrite() method of the persistant storage class. Here’s the code I put in IniQsoData():

if (((strlen(m_MyMult) < 2) || (strlen(m_MySKCC) < 3)) && !(m_ParamPromptDone))
{
Score(0, 0, 0, "")
m_ParamPromptDone = 1;
}

Found a little secret on this leg of the journey that makes the contest module all that much more practical to use. Next, we’ll explore how to calculate the running score as Q’s are logged.

SKCC WES Contest Module as of 2006-06-15

WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

WriteLog contest module development – Part 5: Supporting Structures

A couple of easy but important changes need to be done to this structure in SKCCWESmm.h. Leave the MAXIMUM_BANDS constant alone. We will return to the very important CONFIG_LENGTH constant defined here due to its use in other parts of the module. Defing MAX_NAMED_MULTS to match the number of mults named in the module’s INI file, SKCCWES.INI. MAXAYG defines the maximum number of as-you-go multipliers are available. For an SKCC contest, it isn’t likely an op will work all the members but it doesn’t hurt to make sure the list is big enough. AYGSTRING_WIDTH needs to be large enough to hold a member’s SKCC number, including the honorary C or T.

enum { MAXIMUM_BANDS = 42,
CONFIG_LENGTH = 14, // must match the number in SKCCWESdat.cpp
MAX_NAMED_MULTS = 292, // matches number of mults in SKCCWES.INI
MAXAYG = 6000, // exceeds current SKCC member count
AYGSTRING_WIDTH = 6, //SKCC Number of 4 digits plus C or T plus null char
};

Now set up the INI file for the contest. Edit the Init() method of the main class; I called the file SKCC_WES.INI. I created the INI file by copying the United Nations three letter codes for areas and countries into the INI file. Delete USA and CAN, and changed the lines to break them into alphabetic groupings like: “=A” and “=B” and so on. I copied the North America multipliers from namedmul.ini, taking only the two NAS sections. I renamed the sections to [SKCC_WES] and [SKCC_WES-ALIAS]. The details are in the contest wizard read-me file. I changed the MAX_NAMED_MULTS to 292 in SKCC_WESMm.h to correspond to the number of multipliers I ended up with in the INI file. This INI file needs to go into the WriteLog programs folder with the rest of the contest modules and their INI files. Download the INI file I created and have a look.

The secret to displaying fixed columns with titles in the Multiplier Display.

I saw this question when searching the WriteLog email reflector for clues about contest module development. The contest multiplier display shows the multipliers you have chosen for the contest in a dialog box. The combinations include DXCC, zones, as-you-go multipliers, and named multipliers. DXCC multipliers are set using the almost universal country DAT files that you download. Zones are defined right in the contest module code as a fixed array. As-you-go multipliers aren’t defined before the contest, and named multipliers are created in an INI file that you create. Look at the INI files for other contest modules. Multipliers are defined by their name=column title combination. The column title is tricky to display in the dialog box. The secret is in the Display() method of the main class which calls a method like this:

m_MultDispContainer->MakeDisplay(1, 0,
IID_IMultDisplayPage,
(IUnknown **)&m_NamedDisplay);

There are two mystery number parameters in the MakeDisplay() method. The first one is a flag that sets whether the display handles multiple bands. The second parameter is always 0 in generated code. This flag tells WL to create fixed sized columns with headers. Set the second parameter to 1 and your named multipliers will show up in separate columns with the title over each column. The trick is easy once you see it. Unfortunately, the SKCC multiplier list does not really lend itself to fixed columns because there are so many named multipliers (at least the way I wrote it).

While you are editing SKCCWESMm.h, go ahead and add four properties to the class to save the op’s SKCC number, Bonus, Centurion count, and Tribune count.

char m_MySKCC[6];
int m_MyBonus;
int m_MyCents;
int m_MyTribs;

Remember to initialize these in the class constructor later. We’ll be using these to calculate the score for the summary and reports.

At this point, be sure to try your module out. If you haven’t already, do Tools| Register control in Visual Studio and hit F5 to launch the debugger. Start a new contest, scroll down, and SKCC Weekend Sprint shows up in the list.

The exchange input box has the fields in it and you can log Qs at this point but the score calculation is still wrong.

There were some big rocks to climb here. Download the INI file I created for this project to save yourself some work. I’ve covered a lot of ground here and it seems the context of the examples is getting lost. So download the source code that I have so far and have a look. This is actually a working module and I used it in last weekend’s SKCC WES. It worked like a charm. Don’t know if I would trust my programming on a major contest but all of those events have pretty much been written and vetted already.

SKCC WES Contest Module as of 2006-06-15

WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

WriteLog Contest Module Development – Part 4: The Exchange Entry Box

This series of blog posts started in part 1 where I listed the tools you will need. At this point, you should have a module that compiles, shows up in the list of contests in WriteLog, and can run in the debugger. In this part, we’ll shape up the exchange input and define what a QSO will contain.

Look at the exchange field layout in SKCC_WESdat.cpp. The structure exfa_srtu contains a two dimensional array of fields with each row defining one field. The first element is a string with the field caption. “A?” is a place holder for the as-you-go multiplier and “?M” is a running count of the AYG multiplers in the log. Actually, if you create a contest log with this module right now, you would see where these fields are used. In part 2, I demonstrated how to set up VC++ to run WriteLog when you hit F5 to run the program in the debugger. If you followed those directions, you can create a new log while tracing the module’s code. Go ahead and create a contest with the module in progress so you can see where these fields are used.

extern const struct exfa_stru
g_SKCCWESExfLayout[] =
{
{"CALL", CALL_WID, CALL_POS, A_CALL|A_PRMPT|A_MULTI|A_NOTIFY},
{"SNT", RS_WID, SN_POS, A_NUMS|A_NOTIFY|A_RST|A_OVERSTRIKE},
{"RST", RS_WID, RS_POS, A_PRMPT|A_NUMS|A_NOTIFY|A_RST|A_OVERSTRIKE},
{"RCVD", RCVD_WID, RCVD_POS, A_DUPE|A_PRMPT| A_NOSPACE |
A_MULTI|A_REQUIRED|A_NOTIFY|A_OVERSTRIKE},
{"A?", AYG_WID, AYG_POS, A_DUPE|A_PRMPT|A_MULTI|A_REQUIRED|
A_NOTIFY}, //TODO: check name, size and flags
{"ML", MLT_WID, MLT_POS, A_NOED},
{"?M", AYGMULT_WID, AYGMULT_POS, A_NOED}, //todo: NAME OF COLUMN
0 /*must end with a zero entry*/
};

Look at the field called “RCVD.” This one was generated because we selected named multipliers in the wizard. Change RCVD to QTH but don’t change the other constants associated with the field. Those constants are used in other places for handling named multipliers. Change “?M” to “BO” so we can track the bonuses there. The “BO” and “ML” fields are not typed in the exchange but calculated and show up in the log. The “ML” and “BO” are the titles of the columns in the log. Add a field called, NAME. The A_ flags are defined in the Esfsym.h file, which has some useful comments describing their definitions. Rename “A?” to “SKCC” and set the flags as shown below, adding A_NOSPACE to remove the ambiguity of a number with or without spaces.

extern const struct exfa_stru
g_SKCCWESExfLayout[] =
{
{"CALL", CALL_WID, CALL_POS, A_CALL|A_PRMPT|A_MULTI|A_NOTIFY},
{"SNT", RS_WID, SN_POS, A_NUMS|A_NOTIFY|A_RST|A_OVERSTRIKE},
{"RST", RS_WID, RS_POS, A_PRMPT|A_NUMS|A_NOTIFY|A_RST|A_OVERSTRIKE},
// Name is required but spaces are allowed to accommodate clubs, etc.
{"NAME", NAME_WID, NAME_POS, A_PRMPT | A_REQUIRED | A_NOTIFY | A_OVERSTRIKE},
// SKCC number (or power) is required in the exchange.
// SKCC has A_NOSPACE because an SKCC with a space will be different to the computer than same number without one.
{"SKCC", AYG_WID, AYG_POS, A_DUPE | A_PRMPT | A_MULTI | A_REQUIRED | A_NOTIFY | A_NOSPACE},
{"QTH", RCVD_WID, RCVD_POS, A_DUPE | A_PRMPT| A_NOSPACE | A_MULTI|A_REQUIRED | A_NOTIFY | A_OVERSTRIKE},
{"ML", MLT_WID, MLT_POS, A_NOED},
{"BO", AYGMULT_WID, AYGMULT_POS, A_NOED},
0 // must end with a zero entry
};

Define the _WID and _POS constants to match the exchange field layout. The RCVD_WID only needs to be large enough to hold a three character multiplier (plus one for the null, remember). MLT_WID defines the width of the running multiplier column in the log, not a field width in the exchange input box. RS_WID and SN_WID are for the RST and don’t need to be changed. Change the AYG_WID constant to accomodate the SKCC number. AYGMULT_WID is like the MLT_WID constant in that it defines the width of a column in the log. We’ll use that column to show if the Q is a C or T bonus. Add a _WID constant for a new name field. I set the length of the name field to 21 because really, who is going to send you the entire, 70 character name of their club? Resist the temptation to change the name of the AYG contstants! Those constants are used several places so just leave them well alone.

#define CALL_POS -1 /*always*/
// Setting the width of the fields here. Number is width + 1.
#define RCVD_WID 4
#define MLT_WID 3
#define RS_WID 4
#define SN_WID RS_WID
#define AYG_WID 6 // sized for SKCC number
#define AYGMULT_WID 3
#define NAME_WID 21

We began editing the _POS constants back in part 2. Set the width of NAME to 21. Edit the SKCC position constant, changing the length to 6.

// The order of these POS constants doesn't matter but associating them with the
// correct field in exfa_stru DOES matter.
// These define the location of the entry in the variable part of the QSO.
#define RS_POS 0
#define SN_POS (RS_POS + RS_WID)
#define RCVD_POS (SN_POS + SN_WID)
#define MLT_POS (RCVD_POS + RCVD_WID)
#define AYG_POS (MLT_POS + MLT_WID)
#define AYGMULT_POS (AYG_POS + AYG_WID)
#define NAME_POS (AYGMULT_POS + AYGMULT_WID)

The order of the _POS constants is not important but associating them with the correct fields in exfa_stru is very important. These constants define the offset where the fields data will be stored in the variable part of the QSO.

A note on the variable part of the QSO: this block of memory is very important and gets used everywhere in the contest module. There is a potential for nasty buffer overruns with this data structure so take care in making sure the _POS and _WID constants are correct.

We are making headway now. Compile the module and create a contest using it to see how the exchange fields and the log looks. Errors compiling and creating a contest with the module? Go back through and see if you missed something. Review the readme.txt file. Path environment variable? Including the two LIB files in the project? Things should be shaping up now.

WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

WriteLog Contest Module Development – Part 3: The Code

In the previous part, I worked through the easiest of the TODO items and ended up with a contest module that will compile. If you are just picking up this series of articles here, may I suggest you start at Part 1 where the tools are described.

First, lets look at the terrain from a distance. WriteLog needs to do a few things: accept program configuration and set up details, accept contest configuration details, control the rig at the op’s command, show the operator status messages as a contact is typed in, show a list of worked multipliers, add a contact to the log, show the score summary as the contest progresses, read and write the log to disk, summarize the log into reports and files to submit to the contest committee, and more such as handling spots etc. The items in this list that are unique to the contest are what the contest module needs to handle.

Most of the editing occurs in only two key source files: SKCCWESdat.cpp and SKCCWESmm.cpp. A little editing needs to be done to the resource files but all of that will be done with the Dialog Editor in VC++. Only a tiny bit of code editing needs to be done anywhere else. We will make a handful of edits to constants in SKCCWESmm.h. A little work needs to be done to the INI file for the contest and to the summary sheet templates using your favorite text and RTF file editors.

SKCCWESdat.cpp defines some data elements critical to the contest module. The exchange entry and log file columns are defined here. Definitions for three structures used throughout the module are declared here. And a handful of key constants are defined in this source file.

SKCCWESdat.cpp – key constants

  • CONFIG_LENGTH
  • NUM_BANDS
  • The width and position constants (all have _WID and _POS in the name).
  • A note on the width and position constants: this was a little confusing but the same width and position constant names defined in SKCCWESdat.cpp are redefined in SKCCWESmm.cpp. This is a bold assumption on my part but I think this is to accommodate the fact that you can change the exchange layout in WriteLog. I guess you have to expect the configuration in your module might be different than the one actually used because the operator can choose to change the layout.

    SKCCWESdat.cpp – key structures

  • exfa_stru
  • band_stru
  • g_SKCCWESConfigArray[]
  • SKCCWESmm.cpp
    There is one supporting structure defined in SKCCWESmm.cpp that will need to be edited to support a custom exchange input box and a list of constants that will need a couple of additions as well. By far, method definitions make up the most important part of the contest module and those are all defined in this source file.

    The contest module is composed primarily of one large class ::SKCCWES. SKCCWESmm.h holds the class definition and SKCCWESmm.cpp defines all of the methods that the contest module will need.

    I created a table of SKCWESmm class methods with a few notes on each one but it’s too big for a blog post. Please check the table out because it will provide a shortcut to what you will need to edit for the SKCCWES contest module to work.

    We have gained altitude but the trail has plenty of switch-backs and a few rocks left to climb.

    WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

    WriteLog Contest Module Development – Part 2: The Contest Wizard

    In part 1, I outlined the tools you will need to write a contest module for WriteLog. At this point, the steps needed to set up the wizard have been done. If not, review the WriteLog contest wizard read-me file to install the template, set the Path in the Windows environment, etc.

    The Contest.

    Look carefully at the rules for the contest you are developing a module for. For this walk-through, I’m using the exchange from the SKCC Weekend Sprint rules, http://www.skccgroup.com/sprint/wes/. The exchange consists of CALL, RST, NAME, SKCC NUMBER, and QTH. The QTH is a once per contest multiplier using States, Provinces, and three character codes for DX (as defined by the United Nations). It’s a simple exchange with some quirks to make it interesting. One interesting thing about SKCC Sprints is the bonus points you get for working Centurians and Tribunes, 5 and 10 points respectively, once for each SKCC number per contest. The SKCC number will end with a C or a T for one of those honored operators.

    The Wizard.
    In VC++, create a new contest project using the WriteLog Contest Wizard. Change the project’s Location to the folder named, “writelog” that was in the contest wizard zip file.

    Contest Wizard Template

    After you click OK, the WriteLog Contest Wizard displays. Select the RST in exchange option, Mults As you go, and Named Mults. Don’t use DXCC because the rules say to use the ISO three letter country designator as the QTH. The multipliers are not ‘By Band’ because you only get to use the multiplier once per contest. Add those to the named multipliers instead of using country data. We’ll be using Mults As you go to keep score of SKCC Centurion and Tribune numbers. Leave the Class name as it is. Fill in the Contest Name and 0 for the GUID. The SKCC contest doesn’t need Cabrillo support but I’m adding it because a lot of contests support this option.

    WriteLog Contest Wizard

    The Generated Code.

    After you click the Finish button a pile of code will be generated for you. Add the Dxpref32.lib and wlogsh32.lib to the project Source Files as described in the contest wizard read-me. Now, do Edit|Find in files and search for “TODO.” You should get a list of more than 30 occurrences.

    Start with the easy items in the list. Skip down past the resource files (*.rc).

  • Change the ID string in SKCCWESMm.h from “TODO” to “SKCCWES”
  • Change the MAX_NAMED_MULTS constant to 292 (the count of States, Provinces, and country codes).
  • Set MAXAYG to 400. I don’t know what the world record for QSO count is here but 400 seems plenty from looking at past results.
  • Set the AYGSTRING_WIDTH to 6 to accommodate an SKCC number (4 digits plus room for a C or T and the null for a ZSTR).
  • Run GUIDGEN and replace the one in SKCCWESMm.h. Copy “CLSID_SKCCWESMmd” and replace “<>” with it. Get rid of the old GUID place holder.
  • Change the number of bands in SKCCWESdat.cpp to the bands listed in the rules, 160 through 6m CW by setting NUM_BANDS to 7 and changing the band_stru array to the list of allowed bands and CW mode.
  • Just delete the TODO comment for the PointsForQso() method in SKCCWESmm.cpp. Each Q is worth 1 point.
  • Change the string in the Display() method from “TODO” to “SKCC Mults”.
  • Edit the switch statements in FormatTxField() and FormatRxField() changing the second occurrence of 0 to 2.

    Edit the block of _POS constants. The actual order is not important because these just define their position in an array, not their position in the log or on the screen. Delete or comment out the #error line just above the list of _POS constants.

    #define RS_POS 0 //TODO
    #define SN_POS (RS_POS + RS_WID)
    #define RCVD_POS (SN_POS + SN_WID)
    #define MLT_POS (RCVD_POS + RCVD_WID)
    #define AYG_POS (MLT_POS + MLT_WID)
    #define AYGMULT_POS (AYG_POS + AYG_WID)

    More changes will have to be made later but for now the project will compile without errors.

    Now that the project will build, go ahead and compile it and do a Tools|Register Control in VC++. Change the Executable for debug session on the Debug tab in the project settings with the path to the main WriteLog program. With that set, we can run the contest module in the debugger and step through the code as WriteLog runs.

    Project Debug Settings

    At this point in the journey we have built the framework for the contest module, made a few edits, and compiled the code without errors. Now we leave the lowlands and begin to climb.

    WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

  • WriteLog Contest Module Development – Part 1: The Tools

    WriteLog is the only leading contest logging program offering an open contest module development process for anyone with programming skills that is willing to dig in. I have traveled through the process and now I’d like to present where I’ve been and offer a map of the trail.

    The Tools

      Programming skills

    I have a BS in Computer Science with some programming experience. For this task, you will need passable C++ skills and be able to work with a project that uses the techniques for writing Windows programs as it was done in the ’90s. The generated code tends to lean toward C with some C++ peppered in. Integers, C strings, and one and two dimensional arrays hold most of the data. If you don’t know what a pointer is and how to de-reference one, you are under water from the start.

    A contest module is basically one big class with OLE interfaces and local elements all thrown together. To generalize, you will be writing methods that WriteLog calls when the user does stuff. Sometimes you are responsible for saving the information and sometimes WriteLog is asking for a detail or for you to provide score information.

      Programming environment

    The contest wizard is a project template that works in VC++ 5 and 6 only. However, once the project files have been generated you can work on the contest module in VC.NET Pro. After generating the project in VC++ 6.0, I tested the generated code with VS.NET 2005 and was able to compile a working contest module. The free Express versions of Visual Studio do not work for this task because they do not compile MFC code and you cannot edit and compile resource files. In theory, you could edit the source files in your favorite text editor and compile with the free command line compiler in the Windows SDK. Getting the template code out of the wizard would have to be up to your own devices; you would have to edit the resources by hand; and you would have to write your own make file. If you have written Windows programs beyond a simple hello-world command line application using the command line compiler, then you know what kind of high hurdle it would be to compile a module this way. I have not tried it yet, but the IDDE that comes with the $50 licensed version of Digital Mars C++ might work to edit a contest module but I’m 99% sure the contest wizard will not work with DM. Visual Studio 6.0 is your best bet.

      WriteLog software

    You need a licensed copy of WriteLog. Download the contest wizard from the WriteLog web site.

    Your first task is to do the one-time setup list of actions from the WriteLog contest wizard read-me file.

    That’s the tools you need to pack in order to get to our destination–a working WriteLog contest module.

    WriteLog is Copyright © 1992-2009 by Wayne E. Wright, W5XD.

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.