I have discovered an issue relevant to Premium edition upwards. One of my SB apps uses the Win API call FindWindow to check if an instance of the application is already running.  The FindWindow call takes two parameters a 'class' and the window caption you are looking for.

If you're not sure of the class you can send a 0 in the class parameter (There is also a slight change in the REGISTER definition).

Anyway the problem I ran into was when I exited my application and ran it a second time, It would act as if there is an instance already running and not allow itself to run.  Killing the NTVDM would make no difference.

So I wrote a little app to go through an enumeration of the available windows in the system and sure enough there was a window there with the same caption as my applications, Even though my app is no longer running and NTVDM was killed.

The thing I noted was the windows class name was "ThumbnailClass" – Which I'm pretty sure is to do with Vista's "Desktop Window Manager" fancy effects it uses for task switching. It shows you a thumbnail image of your application while you switch tasks. Now why this would still be present when my application is no longer running is beyond me, perhaps its a synchronisation problem between the Win16 layer windows enumeration and the Desktop Window Manager.  However the problem is existant on the Business edition and I presume the Premium edition as the fancy Aero effects dont come with  the Basic edition.

So the solution I used was to find the class of the Superbase application window and also use that in my call to FindWindow.

So if you're checking for a class name the REGISTER definition will be:

REGISTER "USER","FindWindow","HCC"

if you dont know the class name and will pass a 0 instead it will be:

REGISTER "USER","FindWindow","HJC"

And to get the handle of a window of a SB Application by its caption the call will be:

hwnd% = CALL ("FindWindow","SBV3DATACLASS",caption$)

Just a few short notes to remind myself and anyone else how I got faxing working on vista.

Firstly you must have Vista Business or Ultimate edition as they are the only Vista editions that ship with Windows Fax & Scan.

To configure Outlook to treat emails with the recipient format as [FAX:0123123] as faxes correctly, it must first be configured to use Fax Mail Transport. 

To do this first make sure you run outlook as an administrator, to do this use explorer to navigate to "/Program files/Microsoft Office/Office12", right click the Outlook application and select "Run As Administrator".  If you don't do this you will get errors when trying to add the fax mail transport.

Next when Outlook is loaded, Click Tools | Account Settings | Email tab – New… | Select Other – and highlight Fax Mail Transport and click Next.  You should be prompted to restart outlook and that should be it.

To test, fire up Outlook again (the usual way – not as administrator) , create a new email and address it to [FAX:000] and click send.  Once its sending you should see Windows Fax & Scan pop up and attempt to process it.

You will then also be able to send faxes via MAPI.

Posting XML from Visual Basic 6 is pretty straightforward.  One would think.  But like many development tasks which you'd expect to take an hour or two, this one turned into a couple of days.

First of all, How are you going to get the XML across the wire ?  To answer this the easiest method I discovered was to use the MSXML object, since I have already been using it to create my XML document.

But then which version is best ? There are 6 to choose from ! To answer that I would ask you if plan on distributing your application and dont mind also taking care to include the MSXML msi installer with your deployment. For my purposes I want to make the deployment as easy as possibly. You can pretty much rely on MSXML v3 being present on a target machine. If you dont mind deploying an MSXML msi, then go for version 6.  So I went with version 3.

So far so good, I created my VB code to use MSXML3 to create the document and perform a HTTP post to my servlet which read it in without difficulty.

However the document being sent was 20k in length. That size might not be of significance to you but for me, this action maybe repeated up to 30 times, from many different machines so optimising bandwidth use was also a priority.

The immediate solution is to compress the data.  Searching the web there are many compression components available for VB. However I dont want to pay for something and really just need to zip the data so I can unzip it from my servlet.  I used the ZLIB library from http://www.zlib.net/.  Very easy to use, simply reference zlib.dll from your project and you can either compress a string or a byte array which suits us perfectly.  

Using ZLIB I took the original XML Documents xml source and first converted it to a byte array. Then using the compressData method from the ZLIB library, compressed the data. This took my 15k document down to 2k.

So now I've got the compressed data,  I can just post this ? No.  It must be encoded first.  Without going into why data crossing across the internet must be converted to 7 bit ASCII for succesful transmission, just accept that it does.

What encoding method should we use ?    I repeatedly was having problems at this stage. You can specify that a XML node is intended to contain encoded binary by setting its data type to binary.base64.  I had problems here because even though I did this, I was trying to insert a string representation of the compressed data into the nodes content.  This would raise an error from MSXML.  You HAVE to insert a byte array.

These problems led me to trying various other base64 encoding solutions, each giving different results !

So my working solution was to create a New XML Document containing a single element (I called it Data). The data type definition for data is set to binary.base64.  As soon as I insert my compressed byte array into the "Data" node, it is automatically encoded to base64 so it can be transmitted successfully.

 But not quite. I was still having issues..  When my servlet decodes, then decompress the data… Its all in unicode !  So I was unable to recreate an XML document on the servlet side.

 It turned out the routine I used to convert the XML data as a String to a Byte array is creating unicode bytes.. Luckily I found an alternative routine which gives the option to use ASCII/Unicode.

 Once that was sorted everything works great..   & Also across HTTPS. So my XML transmission is fast and secure.

 Source code examples on request.