TDirectoryListBox - I/O Error 183 on first selection

Question

I have an application in which I get an I/O Error 183 as soon as i choose a directory with a TDirectoryListBox for the first time. After this, it works like expected.

This behaviour is independent from the Form I place the Box in, the drive and many other settings I tried to change.

But when I create a new application and place a TDirectoryListBox in there it works without problems.

I think its very strange since I/O Error 183 is the ERROR_ALREADY_EXISTS which should not happend with a TDirectoryListBox.

I am using Delphi 2007.

Can someone tell me why this is happening and how to resolve the issue?

Answer 1

Looks like the window manager is attempting to create a window that is already there. Use the $IOCHECKS and $I- compiler flags to suppress it. Here is a more detailed explanation:

Let's start with 16-bit window handles. Those are simple: They are just pointers into the window manager's data segment, cast to the HWND data type. Since the window manager had a single 64KB data segment, all of these pointers were 16-bit values.

When the window manager created the 32-bit heap, it asked the 32-bit heap manager very nicely if it could give back 16-bit handles instead of 32-bit handles. The heap manager did this by pre-allocating a 64KB block of memory and allocating its handles out of that memory block, using the offset into the block as the handle.

Since each entry in the handle table is four bytes (a 32-bit pointer), the 64KB handle table can hold up to 16384 entries. This is why the documentation for CreateWindowEx includes the following remark:

    Windows 95/98/Me: The system can support a maximum of 16,384 window handles.

Actually, it was a little bit less than that because some of the entries were lost to bookkeeping overhead. For example, the handle value of zero could not be used because that would be confused with NULL.

Both the 16-bit Windows technique and the Windows 95 technique did suffer from the problem of handle re-use. When a window is destroyed, its memory is freed (as well as its handle on Windows 95). When a new window is created, there's a good chance that the memory or handle will get re-used, and consequently the numerical value of the window handle once again becomes valid, but refers to a different window.

It so happens that boatloads of programs (and "boatloads" is a technical term) contain bugs where they use window handles after the window has been destroyed. When a window handle is re-used, that program sends a message to the window it thinks is still there, but instead it sends the message to a completely unrelated window. This doesn't bode well for the program, and it usually doesn't bode well for the new window that received the message by mistake either.

References

• How are window manager handles determined in 16-bit Windows and Windows 95?

• About List Boxes