Hi Craig,

>On idea #2, prior to VFP 9 I've been using toolbars to create "panels" in my VFP applications. They lacked the ability to stack or tab dock like the VFP 9 dockable forms do though. However, what the toolbars have (and I am trying to figure out how to recreate in VFP dockable forms) was the ability to be turned into "collapsible" panels. A Toolbar automatically resizes based on the controls placed inside it... so it was just a matter of putting a container in the toolbar and voila! I mean if I made the height of the container inside the toolbar shorter then the toolbar would collapse upward or downward depending on the docking position, and if I made the width of the container shorter the toolbar would collapse left or right depending on the docking position (think of a sliding panel that you can open or close). This was great for all kinds of things... add a webbrowser control and you could even have really slick embedded help window.
>
>So, in this case I want my cake and eat it too. <g>
>
>There are a lot of really nice applications these days with dockable panels/forms that do just that. I'd like to think we could have the same in VFP, without the use of an expensive ActiveX control. Add that to what dockable forms already do, and we'd have something really phenomenal.

I've been experimenting with creating a framework that handles menus, toolbars, taskpanes, and panels all via containers and VFP based splitter controls (when resizing is a requirement). With VFP 9, I believe we have all the ingredients necessary to create as rich a GUI environment as we want in VFP without any ActiveX controls.

Like your search for the ultimate dockable window, I've spent a great deal of time looking for and trying to re-create the ultimate toolbar container: basically a VFP toolbar without borders or margins (just a resizable container for a container of controls). I felt that the advantage of a toolbar container vs. a dockable window was the fact that toolbar containers don't cause a control to lose focus.

The approach I'm experimenting with now is to use regular containers to build my toolbars and taskpanes and then adding some logic to my base classes so that the loss of focus that happens when my psuedo toolbar controls are used is dealt with in a positive and generic way. So far the only behavior I haven't been able to reproduce with my pseudo toolbar containers is the ability to send Undo and Redo "messages" (via sys(1500)) to an editbox. Apparently an editbox (unlike textboxes) clears its undo/redo history before its Valid and LostFocus events fire. Note that textboxes work fine with my approach.

This is an interesting thread. It sounds like you and I have similar goals (first class GUI's) but are approaching the solution from different directions.

BTW: Thanks for all your help on Tek-Tips. Very much appreciated! :)

Malcolm