Monday, February 22, 2010

It’s drudge work but…

A whole week without posting. To be honest there hasn’t been much to post about!

It’s been a week of real drudge work on StrokePlay.  There is a lot of data that users can enter to make the game analysis more meaningful and more data means more data entry, validation, storage and retrieval.  So the majority of the last week has been spent on data handling.  It’s not the most interesting of jobs but it’s arguably the most important.

The only other item of note was that I required a good grid control for some of the data entry and again took to Google.

The first one I really looked at was the MFC Grid Control by Chris Maunder over on the excellent Code Project site.  It was good but needed a reasonable amount of code to implement and support it.

But, one of Chris’ responses to a query pointed me at the Dundas Ultimate Grid which has been made available on a free licence.  I remember looking at this control a few years back and I really liked it, but it was overkill for what I needed at the time.

So I’ve added the Ultimate Grid to Strokeplay’s data entry windows and it’s working really well.  More time saved.

Monday, February 15, 2010

Scary Moment

There I was, coding away, when my NAS drive disappeared during a StrokePlay build.

It was one of those moments where everything stops and your heart sinks until you remember that USB drive plugged into the back of the NAS which takes daily backups and that you know has been taking those backups because you checked.

There were no lights on the NAS network port but all of it’s status lights were in the green.  It’s network port on the router was devoid of lights too.

Initially suspecting a cable fault I changed it over to a new cable and, hey presto, a network connection to the NAS.

Connection restored, all data present and correct and a full overnight backup running – just in case.

Friday, February 12, 2010

Transparent CStatic

A strange little item cropped up this week when adding functionality to handle multiple players and switching between them.

I only noticed because I had a place-marker static text on top of a filled group box.

When the text of the static is changed (using SetWindowText) and the background mode is TRANSPARENT the previous text is visible under the new text.

I guess, when I thought about it, it made sense that the static wasn't painting its background because I'd told it to be transparent and allow the parent window background to show through.

The solution was easy enough, just override the SetWindowText method and get the parent control to paint the rectangle containing the old text before setting the new text value.  In addition I handled the WM_ERASEBKGND and simply returned stating I'd handled the message.

Code for the override was short :

CWnd *pParent = GetParent();

if (pParent)

{

    CString _winText;

    GetWindowText(_winText);

    if (0 < _winText.GetLength())

    {

        CRect _textRect;

        CDC* dc = GetDC();

        dc->DrawText(_winText, &_textRect, DT_CALCRECT);

        GetWindowRect(_textRect);

        pParent->ScreenToClient(_textRect);

        pParent->InvalidateRect(_textRect);

    }

}

CStatic::SetWindowText(lpszString);

Sunday, February 7, 2010

Hook, Line and Sinker

I made the mistake of allowing myself to get sucked into looking at a non-problem in StrokePlay yesterday.

I mentioned before that I'd tweaked the drawing code for the custom group box to reduce flicker.  Whilst working on the charting evaluation last week I was distracted by the flicker on window resize and yesterday I got sucked in to looking at it in more detail.

An easy way to waste several hours.  Trying out all kinds of weird and wonderful solutions to something that I can't really see being an issue at all.

Everything was tried, from new off-screen memory DC's, clipped painting, deferring the window repositioning and turning off full window drag for the application window.

In the end I couldn't actually notice a difference and pretty much reverted to the original code, keeping only the defer of window repositioning because I did think that made a difference.

Just goes to show how easy it is to be hooked by something, for no real reason, which eats up hours.

Charting Progress

As mentioned a couple of posts ago I was evaluating some charting and graphing controls to handle those requirements in StrokePlay. 

In the end a clear winner emerged : ChartDirector

The ease of integration, range and quality of the charts and graphs it produced were fantastic.

The only question I had regarded a visual aspect (transparency of background when using rounded edges and drop shadows) but it's not a showstopper since I can add the functionality I want using my custom groupbox.  I've e-mailed the question off to the developers in case I've missed something.

The licensing model is also helpful to the Micro-ISV'er in that you can purchase a low cost development license and only when you are ready to test with users or ship do you need to purchase the one-off redistributable license.  The cost of the redistributable license isn't prohibitive either.

I guess buying in a component is one of those points in Micro-ISV product development where you have to sit and say

Am I confident I'm going to make money and recoup the cost?

I'm still developing, still confident and off to purchase the license

Monday, February 1, 2010

Life in the old idea?

My previous post mentioned that I'd also started to look at printing.

This was prompted by a sudden idea that the product I shelved, PexPrint, to progress StrokePlay may actually be useful for StrokePlay.

StrokePlay's printing shouldn't be too complex but I want to keep it as easy to modify as possible to inject flexibility into that area.

I'd previously bought a couple of books on WPF and had a play around with that.  In addition I've looked at the more basic GDI approach to handling printing.  WPF would be good since it gives me more of a chance to pick up and use a new tech. 

Then I thought about the HTML based printing that PexPrint would give me control over.  That's very appealing for two reasons : the flexibility of just developing HTML pages for print content and, quite nicely dovetailing, the ability to take images from the graphing/charting component and pop them into the prints without much work.

PexPrint is also well along the development path and wouldn't take much finishing.

I've now moved printing up in the schedule so that it gets more attention sooner.

To buy or not to buy

I took a break from coding at the weekend to try and get things moving on two additional fronts in StrokePlay : Charting/Graphing and Printing.

I need a number of charts and graphs to allow me to show the user their statistics in a more meaningful manner.  These range from simple bar charts and line graphs over to area charts.

I had previously thought about coding this from scratch but the estimates I'd popped in to the plan are extending development by more than I'd like.  So I spent some time looking for options and came up with a short list which I'll evaluate this week.

All of the options come with one downside - they cost money.  But they also come with a big upside - I don't need to spend time developing the same functionality.  When I look at the prices I've started to view the cost as the number of licences I'll need to sell to recoup the money spent.  The one that caught my eye most will require approximately 20 sold licences.  But, the flip-side is that it'll shave 3 weeks off the development time.

I hope to have decided on this one by Friday so that I can start on the build for the charting and graphing areas next week.