Friday, January 29, 2010

Loss of wisdom

It's been a week of steady progress on StrokePlay this week despite a visit to the dentist resulting in a loss of half my remaining wisdom and a couple of days of not really wanting to do much at all. 

On my lacklustre days I didn't go near any of the main areas of the code and just busied myself updating documentation and doing a general code tidy-up after a lot of new functionality was added.

I started to look at the various edit controls I need and made a start on a custom edit box for data entry validation.  I was sure I had one kicking around somewhere in an old development but no luck finding it yet.

Aside from that the main focus of attention has been the player home page (the page the user first sees when the application is started) and the player defined courses page.  I need to maintain two types of courses in the application, player defined and those which are pre-defined and shipped with the application

I'll be spending the next few days and most of next week finishing off these areas before I start to look at building the various handicap calculation formulas.

I also need to look at splitting some of the functionality out into a couple of DLLs.  Some of the GUI code and processing would be better handled, in terms of packaging and maintenance, if they were separate from the main executable.  In addition, I've decided that things like the handicap calculations will be separate, again for easier maintenance.

Monday, January 25, 2010

Mixed bag weekend

It's been a mixed bag of work on Strokeplay over the past weekend.

First up was a quick re-visit to the group box control.  I was getting distracted by an annoying flicker during window resize so I added some off-screen painting to reduce it.

I thought it was a done job when I saw the new CMemDC class in MFC (part of the feature pack) but decided against using it when I read the remarks section:

This class supports the MFC framework infrastructure and is not intended to be used directly from your code.

So I stayed clear of the CMemDC class and rolled my own off-screen painting.

Apart from that it's been a case of "join the dots" development.  The database/tables are present and have some data in them, some of the objects (Player, Course..) are ready and some of the windows to display their contents are built.  So the next logical step was to join them together and check that the correct data appeared in the correct field on the appropriate window.

And do you know what, it did!

Lot's of small development tasks ticked off and a rewarding conclusion when the application appeared to take a big leap forward with the appearance of data on the windows.

Friday, January 22, 2010

Group Box in place

Just to finish off the last couple of entries on the custom group box control, I thought I'd pop up a quick image showing the custom control in place and side-by-side with the standard group box.


The image shows the new group box complete with contained controls.  This one is from a Player Properties pane which is where I thought the GUI could use a lift.

Ignore the radio buttons - they still need the background colour change handled to match the underlying group box colour and the application button on the ribbon (top left) is just a place holder image (as are the icons on the ribbon bar itself).

The only thing I needed to add to the previous version of the custom control code was an WM_NCHITTEST handler to make sure the contained controls were correctly notified of mouse events.

I think the caption box on the group box still needs a little work but it's giving me the general look I was thinking of which helps to visualise the finished window.

Wednesday, January 20, 2010

New Group Box

I decided that I'd rather see a more accurate version of the group box control I had in mind so I put together a new custom control.

The code needs some optimisation, for example the WM_PAINT handler is building some objects that could be created once during the control initialisation, but it's mostly there.

A quick sample of the various styles can be seen here:


Code wise, the control creation is simple and I've coded to allow for use in the dialog editor.

Sample code for creating the upper right box would be:


CRect _rGB2(CPoint(350, 20), CSize(250, 150));

CBCLGroupbox Groupbox2 = new CBCLGroupbox;

Groupbox2->setTextBoxOffset(15, 0)

.setTextBoxBorderPadding(5, 5)

.setGroupboxBkColour(RGB(236, 245, 216))

.setGroupboxBorderColour(RGB(0, 0, 0))

.setGroupboxTextBoxBkColour(RGB(186, 215, 97))

.setGroupboxTextColour(RGB(0, 0, 0))

.setDropShadow(7, ::GetSysColor(COLOR_3DDKSHADOW));

Groupbox2->Create("Shadow Colour Groupbox", _rGB2, this, 1);

Simple enough to be useful.

Stuck in the past

I was working on aspects of the StrokePlay GUI yesterday and was working with a couple of Groupboxes when I realised that this was a control that had barely changed over the years.

Sure, the XP version has rounded edges but apart from that it's essentially the same as it was when I first started with MFC.

I was looking at ways to do background fills on the groupbox area but the standard control still doesn't appear to fill within the enclosed groupbox area leading me to a bit of Googling.

I found one custom control that did roughly what I wanted on one of the many coder sites (The Code Project) but it was a C#/.NET control.

I'll park the colourful  for the moment since I don't really need it right now, but I think a quick groupbox custom control might be required to give me the GUI look I want.

New toy

We had need of a new monitor for a PC that's being moved around and I thought it would be a good opportunity to give myself a better display with more screen real estate.

So my trusty old NEC 2080UX is being kindly donated to the PC being moved and I'm snaffling the shiny new 23" wide screen monitor for my development box.

It's not a brand name monitor (not one I recognise anyway) but it's much sharper and brighter than the old monitor and the additional space from the wide screen view is a welcome addition.

Friday, January 15, 2010

SQL, SQL and more SQL

I'm concentrating on all of the data storage components for StrokePlay just now (yesterday and today).

The previous SQLite library I built is working brilliantly and the current task is to build all of the SQL needed for the data access and some of the statistical game analysis.

So far today's focus is on the database and table management SQL which I'm building and testing at the moment.

Of course, the joys of OO mean that the core objects for database management and general access stay the same no matter which database is being accessed.

The SQL itself is being kept separate from the code and may eventually reside in a resource type DLL for ease of maintenance.

Wednesday, January 13, 2010

Yes, it's golf.

I just updated my website to say what I'm working on and wanted to post it here too.

The application I'm now working on is golf related.  I'm a keen golfer - just not a very good one - and I'm working on an application to not only track golfing performance but to help highlight weak areas for the golfer to improve on.

I have a roadmap for the three editions I'm going to offer eventually but the first version (the "Par" edition) is aimed right at the club golfer with or without a handicap.  The two future editions are aimed at those who organise competitions and the clubs themselves.

Development name for the product is "Strokeplay Pro".

Progress can be followed via this blog and, additionally, via a dedicated section (ok, it's just a page right now) on my company website.  Just follow this link to get there: StrokePlay Pro

Monday, January 11, 2010

GUI Iterations

Happy New Year to everyone who occasionally pops by the blog - hope your Micro-ISV aims and hopes are met and exceeded during 2010.

I took some time off over the festive period to enjoy everyone being on holiday at the same time.  Quite a bit of time was lost to the new PS3 in the house and most of the chocolate has now disappeared.

But, back to development.

I jumped back in to development of my GUI last week and constructed a working prototype of the interface I had put together using .

The interface worked as expected but after going through some usability tests I went back and started some iterative design and development of the interface until I was happier with the layout and user interaction.

My target user age for the application is very wide, ranging from around 15 to over 70 and many may be only occasional PC users.  To me this means I need to pay particular attention to accessibility and simplicity in the user interface and I need to make it as intuitive as possible.  The original interface looked good but the interactions across the main controls weren't as intuitive as I'd hoped.

So now the GUI is far simpler but retains much of the originals look without the complexity.