Things that make you go humble

Today I started working with the full set of VCL controls from DevExpress. We used a couple already, but we decided to buy the lot. Mainly because I was working on some much needed tidying up of our dialogs and I got sick and tired of moving controls a pixel left or a pixel right. I already had some logic in place for my own VCL controls (I have created about 20 or so) to do some automated formatting and placing, but that wasn't good enough.

I knew DevExpress had something called dxLayoutControl, but also noticed there weren't many questions about it in the support database. I had the feeling it didn't get much attention, so I nevergave it much thought. But, when the pixel movements were required again, I decided to give it a go.

The demo led me to believe there was actually something good in it, although I was not fully convinced. There were a couple of other libraries that I was interested in, so we did decide to buy the lot.

I couldn't be happier after working with it a couple of hours. It takes a bit of hassle to convert your current dialogs to ones that are built with dxLayoutControl, but once you get the hang of it, it's just a bit of work. After that, you don't have to look at it again and the layoutcontrol takes over and care of everything.

I feel so relieved to know that I don't have to think about placing controls again. As a matter of fact: I will probably redesign some of my compound controls to take more advantage of the capacbilities of dxLayoutControl.

This component by DevExpress might not get the best exposure, but it sure is worth every dollar you pay for it. It really relieves you from the troubles you have to make a real nice form. I can recommend it wholehartedly.

Bye,
Bart

A node is *not* a document...

Tonight I spent a considerable amount of time looking for a problem that wasn't there. In the end I was feeling kind of foolish...
I have a XMLDocument (in a XMLDomDocument from MSXML) that has the folowing structure (this is fake...):

<root><parent><child /></parent></root>

Now, I select a single node, using the xpath query:

/root/parent

and pass it to a procedure. In that procedure I was looking for the child. Suppose this is the procedure:

procedure foo(myNode: IXMLDomNode);

I tried to collect the child node using the xpath query:

/parent/child

and applied that to the passed node. After all, when I inspected myNode, the debugger told me that its structure was:

<parent><child /></parent>

So, why was I getting nil as a result of the xpath query?
The answer (which I found after two hours of debugging...) of course is simple. Even if you apply the xpath to a node, using '/' as the first character starts the query from the start of the document of the passed node. Not at the start of the node...

Boy oh boy, how foolish I was. The correct xpath to select the child was:

(can you guess....., read on .......)

child

Just a little moment of humiliation is called for.... To bed, to bed, my friend.

Bye,
Bart

It's a bugs life

Two weeks ago I visited Marco Cantu in Italy to solve a long lasting memory related bug. Below you find the posting on his website about this experience.

It's a bugs life
I've been programming for ..., well, since ever really. The first programs I've written were on paper cards, ticking boxes with a pencil. Those cards were send to a computer center which returned me the output the following week. Yes, I'm that old.

For a decade or so, I've been working with Delphi and much to my pleasure I might add. But, two years ago something happened. I have a couple of programs out there with a couple of hundred users and some of them were sending in bug reports that I couldn't explain. I looked all over the place for the cause of these reports but I simply couldn't find it.

I knew they were related to this text editing control I was using abundantly, and I dug deep into the source code of it, but I couldn't find a problem there. I was beginning to doubt myself. I knocked on the door of the developer of the control, but he asked ridiculous prices, even to *start* looking at the bug. And for all I knew, the control was actually causing the problem. So, even though I was in big trouble, my pride told me not to pay for solving a bug - at least not to the one who caused it.

I continued my hunt, sometimes giving up, sometimes digging deep. I made some small progress, but nothing that completely took it away.

Then, one day, I saw a news posting somewhere that Marco Cantu was starting a new service to help you out if you have any problems in finding solutions in Delphi software. Although the posting focused on new software and thoughts, I contacted him to see if he wanted to dig into this existing problem.

Soon we agreed on a reasonable fee; one for when we would find a solution to the problem and one if we wouldn't. Now, that's confidence: no hassle, no long e-mails, more like a gentleman's agreement.

I made the necessary travel arrangements and went to Piacenza (near Milano) in Italy. After going through some things I found out earlier and showing some of the bug reports to Marco, he concluded it must be a problem with memory management. We grabbed WinDbg (Microsoft debugger) and very soon we cold confirm that there actually was a problem with that. After having a great lunch we worked a little more, but because of other arrangements I had to leave early that day. But, we already made some real progress.

The next day we soon were able to create a small program that reproduced the problem (something I wasn't able to do the previous two years) and after that, the rest was easy. There was a problem with heap memory and it was due to some timing problems inside the control. Working around the problem didn't take more that a couple of lines of code and I can tell you I was elated! Just by having the correct assessment of the problem we were able to come up with the solution I was looking for for two years.

I couldn't have done it without Marco's expertise and - in the end - it was really fun working together on this. Peer programming really is a joy if you make more progress than working on your own (which not always is the case really).

I can recommend Marco to anyone, not only to novice programmers, but to very experienced once also. He has a quick mind, great expertise and is very friendly and makes you feel welcome. I'm sure to contact him again is something comes up that I can't solve alone.

Bye Bart

http://blog.marcocantu.com/blog/bugs_life_roozendall.html

Looking for a VCL Wizard component

First, there is a sort of discussion going on about deleting items from a list. Should you do that traversing forward or backwards to a list? Point to http://17slon.com/blogs/gabr/2008/03/on-bad-examples-and-smelly-code.html to read on.

Back to wizards. Until now I have used JvWizard (from the JVCL components) as my component of choice for implementing wizards. It's a great component, but there are a couple of reasons why I want to abandon that.

First of all: I have a bad smell (...) about using open source code in my commercial software. Although there are professional programmers working on libraries like JCL, I simply want a phone number or e-mail address I can turn to in case of trouble. I don't want to be dependent on the good will of some programmer. I want to pay for my software and (hence) get some rights to support on it. It's a matter of principle.

Second: I want the controls to comply to my user interface. In this case, I want the controls to use DevExpress components. I saw some switches and stuff to turn DevExpress support on in the JVCL library, but the library is simply too complex and large to dig into and find out what's happening where. And, I want to be sure that if DevExpress upgrades its library (which becomes less frequent unfortunately), the wizard components upgrades too.

So, what to do? DevExpress doesn't deliver a wizard component. I can't find another commercial one. So, I'd better create one myself. Maybe there is some commercial value to that in the end too.

I'll keep you posted.

Bye,
Bart