Category / Programming

by Kevin Ragsdale

I’ve Seen This Before. It’s An Outlier.

UPDATE: Finally figured out this issue. I was encrypting an XML file, which caused some illegal characters to appear from time to time (the “outlier” instances). Took out the header of the XML file, and everything works as expected.

I recently added some functionality to an app which allows the app to login to a web service with a username and password. Since I want to retain the login information (so the user doesn’t have to be prompted to enter their credentials every time), I store the username and password in an XML “settings” file.

I’ve been using Craig Boyd’s excellent VFPEncryption FLL to encrypt/decrypt the password. The user enters her username and password, the password is encrypted, and the username and password are written to the XML file. It’s been working great on thousands of computers.

Except for four computers.

When the app needs to retrieve the username and password, it opens the XML file, decrypts the password, and tries to login to the web service. But on these four computers, the decryption crashes with “API call caused an exception”.

Working with a customer on this particular problem, I pointed him to the XML file and asked him if he would be willing to change his password for the web service – just to see if maybe we could get past the crash.

He changed a couple of characters in his password, and voila! – it worked with no problem.

So he went back to his original password and made note of the encrypted password which was stored in the XML file. Oddly, the encrypted password contained an embedded carriage return:

<PASSWORD>?-arP?­Z?=¤¨?? ;?¥
?8??*ù©y</PASSWORD>

He changed a couple of characters, and made note of the encrypted password again:

<PASSWORD>ðF’1L’|„ žU­MU¨èˆfâ‚?TÀn Çvõ’U</PASSWORD>

Freaky, huh? When I run the code from the app via the Visual FoxPro Command Window, including the STRTOFILE() and FILETOSTR() lines to write and read the XML file, it works with no problem.

The customer, a former software developer, tried 16 more random passwords – just to see what would happen. Every one of them worked flawlessly.

So, after successfully trying 17 passwords he went back to the original. Same problem: an embedded carriage return in the stored encrypted password, and an API exception when decrypting it.

The last thing he said to me was:

Then it hit me, not the first time I’ve seen this. It’s an outlier. There is a very good reason why this is happening. You may close the ticket now. The function is working fine.

by Kevin Ragsdale

Don’t Be So Hard On Yourself (or, ShellExecute() to the Rescue!)

I’ve got a bad habit of always trying to reinvent the wheel, even when I’ve got a perfectly good wheel right in front of me.

I just wrapped up some work on a Visual FoxPro app that uses a lot of rich-text format (RTF) files, and I was hitting a brick wall when it came to printing the documents.

I tried the FoxWiki, Google searches, even went back to my KiloFox book (excerpt here), but I just couldn’t find the right method to make the program do what I wanted it to do.

Then I thought, “Hmmm… every Windows computer has an RTF editor, right? And this editor has all the print functionality built-in. Very interesting…”

Plus, if the user has word-processing software (Office, OpenOffice, etc.) and it’s properly registered as the handler for RTF files, it’ll have all the print functionality built-in, too.

So, instead of pulling out the remaining few hairs on my head, I decided to go the ShellExecute() route, and set the menu up to open the user’s default RTF application in two different ways:

  • EDIT mode –  (The Print menu item – the user can do what they want with the document, then select the printer, etc.)
  • PRINT mode (The Quick Print menu item – open the app, and print the document to the default Windows printer)
Print menu example

 

So, I went from researching and trying all kinds of workarounds to this:

ShellExecute(FindWindow(0,_SCREEN.Caption),"Open",lcTempFile,"",JUSTPATH(lcTempFile),1)

and

ShellExecute(FindWindow(0,_SCREEN.Caption),"Print",lcTempFile,"",JUSTPATH(lcTempFile),1)

And immediately felt relieved for being just a little less hard on myself…

On a side note, the app uses the CommandBars Library from Alex Grigorjev. I was lucky enough to still have an active subscription when he released Version 7.0 (which includes the Ribbon interface).

VERY HIGHLY RECOMMENDED!!!

More info on the CommandBars library:

by Kevin Ragsdale

Google Docs with Visual FoxPro

One of my earlier blog posts I could not recreate was about accessing the Google Docs API with Visual FoxPro.

I re-did the screencast for it (watch it here), and also posted the code examples here (13.9 kb).

You’ll need the West-Wind Client Tools to run the demo (you can download a shareware version here).

I’m thinking about reworking the code to use Craig Boyd’s VFPConnection FLL, and expanding the examples a bit.