Re: xPL C++ Lib released

["Mal Lansell" <mlansell@xxxxxxxxxxxxxx>]

--- In ukha_xpl@xxxxxxx, "John B" <home-automation@j...>
wrote:
> Hi Mal,

>
> This looks great - I intend to use it to re-write my joystick app
(which allows you to use your game port as an I/O device, and
transmits xPL messages indicating the status of the input pins) using
your new classes.
>

Blimey - and there was me thinking I was in a world of diehard VB
fans ;-)

> A couple of points:
>
> In baseService.cpp:
> When parsing the command-line options, you do a case-insensitive
comparison for "/install", but a case-sensitive comparison
for "/Uninstall" - probably better to make both of these options
case-
insensitive.
>
> The usage information you display seems to be wrong - it talks
about using -i and -d for install/uninstall operations.
>

It used to be -i and -d, but when I did the installer I found it was
passing in /install and /uninstall - I guess I got a bit out of
step.  Easy to change though.

> Also, when installing the service, you use the value of argv[0] to
determine the path to the exe file.
> This doesn't always work (as I found out) - consider the following:
>
> If you run something like:
>
> c:\xpl\xpljoystick\release\xpljoystick.exe /Install
>
> Then it works fine. However, if you do:
>
> c:
> cd\xpl\xpljoystick\release
> xpljoystick.exe /Install
>
> Then it doesn't, as argv[0] just contains the "xpljoystick"
bit
(i.e. without the full path).
> Not exactly a major problem, but something to be aware of never the
less.
> I guess you could detect whether argv[0] was an absolute path (by
checking for the presence of a backslash or something) and if not,
use GetCurrentDirectory to prepend the current directory in front of
argv[0] to give you a full path.
>

The original code did that, but argv[0] always seemed to contain the
whole path, so prepending the GetCurrentDirectory meant the path was
in there twice.  I guess I need to be a bit more sophisticated.
Grrr!!!!

> Anyway, great work so far - it's nice to be able to produce some
apps that don't depend on the .NET framework or any ActiveX objects.
>

It would never occur to me to use them - I never have in the past,
and to be honest, I'm not 100% sure what they're for (although I
probably wouldn't want to tell my boss that!)

Mal