ProfitUI QRB tool

This is a tool I worked up to edit one of the configuration files for the ProfitUI mod to the Everquest 2 user interface. One thing you need during raids is extra buttons to quickly cast buffs, heals and such on raid members. And you want to cast the highest-level version of a spell that you have available. With 25 classes, 5 buttons per class and usually 6-8 versions of a spell of varying levels, plus extra commands to announce things to the raid so they know what you've put on who, that all adds up to a lot of configuration. Add in dealing with the vagaries of EQ2's XML syntax (which isn't quite exactly standard XML when it comes to character encoding and the strings that make up command sequences) and probably wanting to have the configuration for spells you don't have assigned to a button at the moment and it's just too much to handle easily by editing the XML source code.

I had an earlier tool written in C++ that used simpler text files to hold the information, and while it simplified a lot of things it still had the drawback of not having any way to store configuration for things not actively in use. And non-developers running a Cygwin command-line program that depends on text files with a particular syntax when that program has less-than-optimal error handling? Probably not a good idea. Just getting Cygwin installed would be enough of a problem to make it a non-starter. So I decided I needed a GUI tool. It had to save information about spell lines (a series of versions of a spell of increasing level, plus additional non-spell macro commands) independently of the ProfitUI configuration file. It had to save it's configuration between runs. It had to allow selecting things from pull-down lists or similar selections where possible, avoiding having to type things in. It needed to make it just not possible to do things that weren't legal. And since I wanted a real project to cut my C#/.Net desktop development teeth on, something big enough to actually exercise what I'd need to write a real application but small enough I could actually complete it, the QRB tool seemed an ideal project.

After that it was a matter of designing features. There's more under the hood than you'd expect. The mechanics of a Windows Forms application. XML parsing and writing, to save the storage file. The bits of the storage object you don't think about when starting out, for instance how to create a new physical copy of it to hold the current state when you aren't ready to save it to the permanent program state yet (users want to be able to hit Cancel and have it really cancel their changes). Updating pull-down lists when the user's just edited the list of things that're supposed to be in the pull-down list. System mechanics, like where the data files are stored and how to find that out in the proper way so you adapt to how Windows is set up. And things like, if the user used the installer I can make sure the XML schema file's put into the app data folder right, but if the user just unzips the zipfile version the schema file's only in the executable's folder. And I can't just use a bare filename for the schema file, because if the user doesn't set up the shortcut with the right working directory I won't be in the right directory at run-time. So to be safe I need to check for the schema file in the app data folder, and if it isn't there locate the folder the executable's in (not the current working folder) and copy the schema file over. And then there's program help. It's not something a developer thinks of right off, but you need to make tooltips work and have a Help button. And help files for the Help button to display. Which is a completely separate utility, Microsoft doesn't build the Help Workshop into Visual Studio. And what do you do when unexpected exceptions happen? On my machine it's easy, I have the source code and can just debug the app when it crashes. Ordinary users want something a bit nicer, so how do you catch all exceptions that didn't get handled by the code and do something sensible with them so the user has information to submit to help diagnose the problem? And I'm just scratching the surface, there's tons of things that an app this small doesn't touch on that a real major app would have to.

If you want to look at the help, download the QuickRaidButtons.zip file, unzip it and look at the QuickRaidButtons.chm file in it. That's the help file for the program, and it covers the basics of using it. You can run the QuickRaidButtons.exe program directly out of the unzipped folder, it doesn't require actual installation (though an InstallShield installer's provided in QRBInstaller.zip). It doesn't do anything to the registry, just creates it's own QuickRaidButtons folder under your user AppData folder to store it's files. If you generate UI code, it'll let you select where to save the file so you won't have things going anywhere you don't know about. You'll need the .Net 4.0 framework installed first.

New features added with version 1.2 include the ability to use numeric spell IDs instead of or in addition to spell names (a dictionary associating spell IDs with their names is maintained) and the ability to import and export spell names and IDs, spell lines and button assignments to comma-separated value (CSV) files.

Version 1.3 rearranges the UI slightly to use a menu bar instead of so many buttons. The major new features are the ability to open and save different storage files so you can maintain multiple button configurations easily.

Version 1.4 adds support for the new Channeler class, but otherwise is unchanged from 1.3. Externally, at least. Internally there's some additions in preparation for supporting the EQ2 data feed to do things like automatically retrieve spell IDs to reduce the dependency on knowing them beforehand, populating an entire spell line automatically and correctly given the base name, and retrieving all spell lines for a class and letting you select which ones to add to the database.