Marcus' Macro Scheduler Blog

For the licensing mechanism for our ClipMagic product (ClipMagic is an easy to use Windows Clipboard Extender if you didn’t already know) we adopted a server based activation system. I know that some people have a passionate dislike for software that needs to be activated, but you can’t please everyone. And until now we’ve had no complaints.

Then yesterday we get a ticket with no name and an invalid made-up email address saying simply:

“Unfortunately I purchased your product without realizing it required web authorization. I’ll just use a competing product”.

Now, before I’d seen the email address my immediate reaction was to reply and offer a refund. Perhaps I’m too nice but I don’t see the point in having customers that don’t want to be customers. But then I noticed that if I did reply the email would simply bounce. The “customer” has provided no identifying information at all!

I don’t get it. He says he purchased but doesn’t want it – and won’t activate it. Yet doesn’t want me to know who he/she is and isn’t asking for a refund. So why bother emailing me? Letting off steam perhaps. But it seems odd that there was no request for a refund.

I’ll file it away in our “Strange Emails” category.

Some people have asked why they can’t change the colour of a button that they place onto a custom dialog.

The short answer is that these buttons are standard Windows buttons and are drawn by Windows. And Windows has some “rules”.

Microsoft lays down some design guidelines. Take a look at this document here which says:

If you use standard windows and Windows controls, these border styles are supplied for your application automatically. If you create your own controls, your application should map the colors of those controls to the appropriate system colors so that the controls fit in the overall design of the interface when the user changes the basic system colors.

So, a standard control, like a dialog button will adopt the colour and design as decided by Windows and the user’s system wide preferences and we as the programmer have little or no control over it. Idealistically this is a good thing.

I believe that convention helps usability. If all buttons look alike a user knows it’s a button and so it’s purpose and functionality is obvious.

Of course, there are exceptions and sometimes there may be a reason (justified or not) for ignoring the guidelines and making a button look like something very different, e.g. in a game. So how do you do it? Well, obviously you don’t use standard Button objects.

On the whole Macro Scheduler dialogs are meant to be just that – standard looking Windows dialogs, designed for requesting data from users or giving them choices and controlling macros.

If you want complete freedom to design something snazzy then arguably you are using the wrong technology and should be considering something like Flash or HTML instead. And there’s no reason why such an interface can’t trigger Macro Scheduler macros anyway.

Having said that there are some things you can do to make more glorified looking dialog “buttons”. One option is to use Image objects. Don’t forget that you can respond to a mouse click on any object, so you can easily have a clickable image. You can trap other events too – such as mouse over events. So if you want to be really clever you can have your image’s mouse over event change the image, e.g. to one with a slightly different border style so that the user knows it is the active “button”.

I received this in an email yesterday and just had to share it:

“Thank you for a truly superior product! I used this at a previous place of employment and developed a system to autopopulate our very static software. When the software vender sent training staff they were so impressed they offered me a job! I now work for them and have you to thank for it!”

It’s not always easy running a small software company. But receiving feedback like that certainly makes up for a lot of hard work.

I received the following email today (I have paraphrased and anonymised it to protect the innocent):

“We were given a Macro Scheduler script to run on our system that someone else wrote which we are trying to use with your trial version. It doesn’t work. Your product seems to be very flaky and unreliable. Is this a feature of the trial version?”.

Now, when I read an email like that I have to breathe carefully and compose myself. To see what’s wrong with it let’s reword the same message as if it were talking about a different product:

“We were given a VBScript file which someone else wrote and we are trying to run it on our system but having problems. Microsoft VBScript must be very buggy!”

Yeh, so because a script that someone else built using a particular product is buggy the user thinks it is the product that is buggy. It seems not to have occurred to them that the script they were given is clearly not put together very well, or at least not written to run on their system. It hasn’t crossed their mind to report back to the person who wrote the script. For all we know the person who wrote it never intended it to be run on any other system but his/hers anyway.

You can build all kinds of dodgy, bug-ridden and dangerous software with C++. Does that mean Microsoft Visual Studio has a bug?

I’ve downloaded lots of dodgy VBscript code snippets, buggy PHP files and Perl scripts that fail to do what the author says they do, or need tweaking to work on my system. It never occurred to me to blame the VBScript, PHP or Perl interpreters. Next time rather than email the author of the code I’ll email Microsoft, PHP.com or Larry Wall instead.

Sheesh.