Bay Six Software

[Alyce]

Brent,

The MDI features of WMLiberty are very useful. I've created working MDI apps using LB and API calls, but it's a kludge, at best. I hope the next version of WMLiberty includes improvements in this feature. It's one that is often requested in LB-Land. It's also one of the reasons I use other languages.

[BASICwebmaster]

One of the big problems I see with MDI as implemented is that it's next to impossible to store data 'in' a window. With straight API, you'd just allocate some extra memory per window in the class, trap the WM_NCCREATE and WM_NCDESTROY messages to initialize it, and write a couple helper functions to get/set the information in the form of a struct. Having some way to do this through WMLiberty would be awesome.

Other than that, things are basically kosher as-is. I'm using so many API calls, controls, and callbacks anyway... but that's another topic entirely.

[Brent]

Hi Alyce & Bill,

I've given MDI some thought and I believe it may be possible to clone existing windows; something like this:

[BASICwebmaster]

Looking at it now, I've found a work-around to the issue of storing information with windows. Instead of storing the data itself with the window, an app-specific window ID can be stored (using SetWindowLong). That ID corresponds with an entry in a dynamic array. I've also worked out some simple garbage collection: when a new ID is requested, the allocater looks for an entry flagged as closed.

Truth be told, now that this issue is solved, I *like* the current implementation of MDI. Maybe I've been spending too much time doing straight Win32.

[Brent]

Bill, I'm glad you've found a way around your problem. The extra window data can be very useful for storing tidbits. My proposed changes to MDI support would also include "-Ex" versions that would allow you to specify window data blocks and more.