The Day Job (again)

Well, it turns out that I've been doing AJAX for the most part since 1999, excepting that I haven't been using asynchronous XMLHttpRequest and I've done my work in VBScript. Makes me feel all warm and fuzzy.

In any event, I replaced the DLL containing the XML with an XMLHttpRequest invocation, and everything worked fine. Next, I will secretly replace the DLL with these "Folger's Crystals" in production, and see how it goes. If our bandwidth doesn't spike too badly, I will keep it and produce some web-based tools allowing on-the-fly editing of default rates plus the creation of custom ratebooks. I'll also add code allowing a ratebook to be associated with a customer, so selecting a customer in the system automatically pulls their ratebook.

The Day Job

I'm moving into some new territory at the office. I've started looking up information on AJAX in order to improve a web-based invoice app.

I am currently using a downloaded VB ActiveX DLL to supply the app with rate book information, as it's too much information to download. The DLL provides rates data in XML to the app on demand; the app uses VBScript to load the requested rate book into an XML data island for subsequent client-side processing. The part of the app that edits invoices does all the processing on the client side through the use of XML data islands and VBScript that accesses the DOM. The following picture shows a line item added to an invoice:



Using the DLL to make rates available to the client side made sense when the rates were updated infrequently. We now want to update these rates frequently, and add additional support for updating contract rates on a per-customer basis. IT needs to get out of the receive data-build DLL-publish DLL loop.

Fortunately the current problem helps us solve the original problem that called for a DLL-based solution in the first place. Generic rate books tend to be large collections of data -- everything we might charge to anyone. Add a few of those together, as was necessary from day one, and you could grab a cup of coffee from the break room and be back before the page rendered, especially using dialup. Using smaller, targeted "slates" of contract rates requested on a per-customer basis, we should be able to work within the available bandwidth, while decreasing page render times.

What I want to do now is use XMLHttpRequest to get the desired part of the selected rate book as XML. Once I have this technique down I can use my existing client-side code to parse the XML into the UI. I will then write some tools to allow users in the field to create and update small contract rate books.

We'll see how this goes.

Game Developement Status 11/10/05

Monthly total 8 hours, yearly total about 232 hours.

tick, tick, tick, tick, tick.

I started work tonight on a game status display. Both Richard Kane and Robert Fulton had suggested we include such a display. This will be a dockable window that will show things such as the weather, game turn and game time.

Feelin' Worthless :)

My blog is worth $0.00.
How much is your blog worth?

Game Development Status 11/7/05

(October total 6 hours 13 minutes.)
Monthly total 6 hours 16 minutes; yearly total 230 hours 49 minutes.

I just sent off the "Halloween Beta" to Chris for review.

The Jump Map is now modeless. It toggles on (and off) using the F9 key. The size and position of the reticle representing the portion of the map displayed on screen updates as the map is scrolled or the Game Messages window is resized or repositioned.

The Victory Condition dialog now displays the actual text of the victory conditions from the Battle Book.

And the Credits dialog (off Help | About) will pause and resume the (otherwise) automatic scrolling of the dialog. There are also buttons to control the speed of the scrolling.

I already have as much time in this month as all of last month. I'll continue to move forward this month. I will work on bugs and UI enhancements for the time being, until we hear back from Clash of Arms.

vive l'E!