Minor Annoyances

[billroper]

Yeah, I know. Gripe, gripe, gripe. :)

The good news is that I'm down to under 50 compile errors in the Chart of Accounts. The bad news is that these will be a bit harder to eradicate than the others, as they're trying to parse formulas for the most part. And having determined that we were going to indicate an account by putting it in quotes, I am forcibly reminded that our string constants are also in quotes. The latter will have to give, although I'm not sure exactly how yet. Maybe single quotes instead of double quotes.

For Sequel, I now have to go home, dig a serial number out of the licensing software -- assuming it's there -- go up onto the Steinberg website and register that serial number with my My Steinberg account (assuming that I remember the user name and password), after which I will be able to request a new activation code. So possibly by tomorrow night, I will finally have this beast installed and working. I hope.

On the plus side of the ledger, Bonnie and marnie_gucciard are coming over tonight so that we can work with daisy_knotwise on plans for Special Events at WindyCon this year. That should be fun!

Comments

[min0taur.livejournal.com]

Someday, at the end of my life, I don't expect to have many regrets, but I'm guessing one of them will be all that mortal time I nickel-and-dimed away playing "Simon Says" with machines -- usually so I could pay for the privilege of repeating the experience.

[kizoku42.livejournal.com]

This Steinberg software is obviously being a pain in the a**. Just commenting, not knowing the software you're working with, but if you can have hundreds of compile errors shouldn't the code have been more modular to begin with? Of course, you probably inherited it.

[billroper]

The Steinberg software is and continues to be. *sigh*

The software I'm writing dates back in the current incarnation to 1995. There are certainly things I'd do differently if I were rewriting it, but the big problem in this case is that the keys to locate account objects were originally unwrapped LONGs. Later, we expanded the key to handle dimensional accounts and wrapped a LONG together with a CStringArray in a CVarID object. However, there were still many places in the code that were interested in looking at the LONG part of the ID -- such as, for instance, the formula parser where the user could enter an account number that we'd need to convert to a LONG. Now I'm converting the account numbers from LONGs to alphanumeric strings, so a certain amount of disruption is going to occur.

The big problem here is a module that was written by someone else that assumed a lot of things about the account numbers that simply shouldn't be assumed. I've now trashed through that module and patched it up so it compiles, but a lot of it is going to need to be rewritten by the original programmer so that it no longer makes those assumptions.