Sorry for...

not posting much blog entries the last couple of weeks. And unfortunately, it'll be like this until the end of next week, at least.

Currently it's about 9pm here in Belgium on a friday evening... and I'm working. As I have been the last couple of weeks.

One of my clients will leave to an exposition in Asia on the 22nd and I've been working on an enhancement of his software package. Basically, the software package allows for CAD of industrial facilities. After design, the user can initiate a report generation which contains references to formulas used to calculate tensions, pressures, etc. Now, the clients would like to see the actual formula used to make a calculation integrated into the report. Additionally to that feature, I implemented a feature that is able to replace the variables of the formulas by values held by the software.

So far, so good. Now, I'm integrating everything into the report generation which makes use of hand made tables, hand made object within the table etc. On first glance the hand made stuff allowed including bitmaps into the report... only on first glance, because when digging deeper, the "bitmap" I could enter was a table that would always fit onto an entire page of the report. Thus, it was not possible to include a bitmap into line x row y.

I spent most part of 2 days understanding how those hand made classes are constructed, interweaved and derived. I also spent an entire day debugging to see which functions get called when. To give you a small glimpse of what kind of code I have to handle:

if (imp_info_wand() == 1) ziel << imp_terf();
else ziel << undef;

if (imp_info_wand() == 2) ziel << imp_terf();
else ziel << undef;

if (imp_info_wand() == 3) ziel << imp_terf();
else ziel << undef;

if (imp_info_wand() == 11) ziel << imp_terf();
else ziel << undef;

if (imp_info_wand() == 12) ziel << imp_terf();
else ziel << undef;

ziel << undef;
ziel << undef;

This is actually a piece of code filling one part of a table. The << operator actually puts the cursor into the next line of the table after inserting the value. There's no whatsoever documentation of the code. So...

There was also an issue to determine when and where which formula has been used since the reference to the formula appears magically in the comment row when the << operator has been used. I found out that the same line is used multiple times within the table description. Using a << with "undef" actually skips a line of the description and "removes" it from the table (thus the multiple following "ziel << undef;" line that I encountered.

Now, since the << operator puts the cursor into the next line, the trick is to try to determine which formula in mentioned in the comment line *before* the value is written into the table.

On monday evening I'll have to travel to the customer's office and I'll stay there until the end of the week. I still have this evening and monday until 4pm (shortly before I leave) to get at least a formula into the report. Once I have one formula in the table, I can insert additional tables at the end of the report and refer to those (if ie. values are included in the table).

Well well well...

Have fun.