User Interfaces and my Secret Project

I don’t make it a secret that I despise designing and implementing user interfaces.  One of the beauties of the command line interface is that it is so simple to implement.  Unfortunately, unless you’re using the application programmatically (e.g. in batch files), the command line interface isn’t very user-friendly.  It’s simple to use but, in a Windows environment, opening a console, navigating to the proper directory, and then typing out the command line can be cumbersome.

Ultimately, you need to design your user interface for your intended users.  For more esoteric programs like my FLV Script Data Extractor, a command line interface is fine because anyone interested in that sort of thing is likely to be handy with the Windows console.  However, for my secret project, my intended users are not necessarily going to be hardcore computer users.  They’re much more likely to be casual computer users who may never have used a console application or a command line interface before.  Unfortunately, that means that I had to design a graphical user interface for my secret project.  I considered using .NET to make the interface because Visual Studio 2010 makes creating GUIs in .NET very easy, but I thought the overhead of .NET for such a simple application was overkill.  To my dismay, Visual C++ 2010 Express does not provide any interfaces or templates for creating GUIs in Win32.  You just have to code the whole thing.  I’m not familiar with making GUIs in Win32 so I was kind of stumbling all over myself at first.  I tried using Windows controls (static text, edit boxes, etc.) but I couldn’t get the coloring right without doing extra work that I didn’t feel like doing.  After banging my head against the wall for several hours, I decided to try using a dialog box interface.  I’ve done my fair share of dialog box programming from my time making objects for Multimedia Fusion.  I wasn’t sure how to make a Win32 program that was just a dialog box, so I had to play around with it.  Finally, I realized I could just scrap all of the default window creation code Visual C++ created for me and simply use the DialogBox function by itself.  A handy trick I’ve used in the past is to create my dialogs in Visual C++ 6.0, which has a neat little dialog box designer, and then copy the proper code over to Visual C++ 2010.  I suppose I could just draw the interface on paper and then code it manually but designing it visually is so much faster.  After several days, I finally finished the interface.  The code is messy, with way more global variables than I’d like, but I’ll just blame that on a lack of experience. 

I toyed with the idea of also allowing the user to use the command line if they so desired, but I ran into a bit of a speed bump.  In a Win32 application, Windows does not break up the command line into argv and argc.  Instead, it passes the whole command line as a single string.  Windows does provide a function (CommandLineToArgvW) for converting this string into something similar to argv and argc but it only works on wide chars (Unicode).  This really shouldn’t be a problem since I did design the program to use Unicode, but I was using TCHAR, which is a Windows type that can be either wide char or char depending on preprocessor definitions. I thought about using CommandLineToArgvW but that would defeat the whole point of using TCHAR.  Given that no one is ever likely to use the command line, I decided it wasn’t worth the effort to write my own function to parse the command line.

FLV Data Extractor and the Mystery Tag

I finally finished that FLV Data Extractor I mentioned in my last post. You can download a copy of it here: http://bumderland.com/dev/FLVScriptDataExtractor.html. The program has a command line interface, but I am strongly considering writing a generic GUI that can be placed over command line programs. I imagine that many modern computer users are not even aware of the Windows console, let alone how to use it, so if you want lots of people to use a program, it should probably have a GUI. There are still merits to the command line interface. For example, you can use programs with CLIs in batch files, but I suppose even windowed programs can also support command lines for such purposes. I’ll have to play around with the generic GUI idea and see how it works out. I may just end up modifying the FLV Data Extractor to have a GUI with support for the command line too.

If you try out the program, you’ll probably notice that it asks you to agree to some terms before using it. While I distribute most of my software for free, I can’t get over the idea of someone using my software for profit. I suppose this is a personal hang-up of mine and that I should get over it, but I can’t, at least not now.

On a final note, while testing the FLV Data Extractor, I came across a strange occurrence. Adobe’s FLV format specification only mentions three types of data tags: audio (0x08), video (0x09), and script data (0x12), but in some of my files, there was another mysterious data tag, 0x0F. I tried googling for information but turned up nothing. I then examined the data included in the mysterious tag, and it seems to be like a script data tag except that there’s a mysterious 0x00 byte before the start of the event name. This mysterious tag is why I added the -u flag to the command line options. I don’t know what the mystery byte is meant to indicate. If it’s a count of some kind or if it indicates the presence of some extra data, this will cause problems with the -u flag. If you happen to find any FLV files that produce errors or unknown tags (even with -u set), feel free to send them to me for analysis.