VFP9: Dockable windows viable in an application (vs. IDE?) 1

[awaresoft]

I've been reading about VFP 9's dockable windows and wonder if there's a scenario where it would make sense to use this feature in a distributed application? By "use this feature" I mean with all the limitations associated with the VFP 9 implementation of dockable windows?

I'm looking for a tutorial, sample code, or even a high level description of how to make the current implementation of dockable windows useful in a distributed app.

Thanks,
Malcolm

 

[craigsboyd]

Dockable windows will do the same for your customers' applications that it does for you in the IDE. Maximize screen space, allow your users to customize the work area to reflect the way they work (thus increase efficiency), and in an MDI application it can help keep certain windows out of the way making your application more manageable (increase in efficiency again and lower the annoyance-factor for the user). I've been using toolbar classes with containers in them prior to VFP 9, so dockable forms was a god-send if you ask me.

Below is a screenshot of a VFP application my company created for a customer that utilizes dockable forms (docked over on the left-hand side). Sorry it's so small, but I don't want to kill this thread for anyone still using dial-up.

On top is a miniature view allowing the user to navigate around in the blueprint shown on the right. Below that is a Magnified view of where the mouse currently is in the blue print. Below that are two tabbed docked forms, one with a grid in it showing all the blueprints that the user can pick from (showing) and the other is a grid with information regarding the user's estimate that can be exported (to excel for instance) and printed. The blueprint on the right is an MDI form so the user can bring up multiple blueprints at a time while they are creating an estimate for the construction job the blueprints represent.

It just wouldn't have been workable without the use of menus, toolbars, MDI forms, and last but not least dockable forms.

http://www.sweetpotatosoftware.com

 

[awaresoft]

Craig!

Wow - that looks like a great application! You're the first first I've come across that's actually using Dockable forms in a production app.

Some questions:

1. Do your users actually dock/undock, reposition windows and resize to create custom layouts or do they keep the layout illustrated by your screen shot? (do you save and restore your user's layouts?)

2. What made you choose multiple MDI forms vs. a single form with splitters, nested containers, and pageframes?

I'm also intrigued by your mention of toolbar based forms built with containers. I'll create another thread for this topic in order to keep this thread focused on dockable forms.

Thanks again for your detailed reply and your screen shot. I was going to write-off dockable forms as an incomplete feature, but your reply is causing me to re-think dockable forms from a fresh perspective.

Malcolm

 

[Mike Lewis]

This is very interesting. As I mentioned to Malcom in another thread, I need to create a taskpane-style window in my present app. I was thinking of trying a dockable form. Craig's comments are encouraging.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[craigsboyd]

1. Do your users actually dock/undock, reposition windows and resize to create custom layouts or do they keep the layout illustrated by your screen shot? (do you save and restore your user's layouts?)
Yes, users position the dockable forms where they want, resize them, and have them open or closed as they have need. I positioned them on the left-hand side and resized them for the screen shot. I do not currently save where they last had them docked, etc. (future version thing).

2. What made you choose multiple MDI forms vs. a single form with splitters, nested containers, and pageframes?
With an MDI, I only needed to create a form class and place some other classes on it for handling the blueprints. Then the user can open any number of blueprints and each comes up in it's own window. This also allows the user to either maximize the MDI forms or to resize them, cascade them, or tile them within the _screen. Also, as you can see from the screen shot, MDI forms respect docked toolbars and docked forms. So, I get a lot for free using an MDI.

As for toolbars with containers in them to simulate dockable forms, in earlier versions of VFP it was the only way to do this. Now with VFP 9 dockable forms, it just isn't necessary. Though containers still have their place in toolbars at times, in the case of creating panels for an application there's just no reason not to use VFP dockable forms.

http://www.sweetpotatosoftware.com

 

[awaresoft]

Craig,

You have my head spinning<g>.

I can see the flexiblity that your MDI based design offers over a pageframe based solution. In your case, the ability to tile MDI windows in various ways for comparision purposes could be very useful. This would not be possible with pageframe based interface.

I also see your point about "getting a lot for free" with a MDI based interface.

You've given me a lot to think about ... I guess its back to the drawing board!

Thanks for taking the time to help me understand how docked forms and a MDI forms can be used in an application - very much appreciated!

Malcolm

 

[craigsboyd]

Here, I've created a little example to allow you to play around with this design a bit. Copy-N-Paste the following code into a PRG and run it from within VFP. There will be a menu called Create Forms when this is run, and using it you can create an unlimited number of MDI Forms, Dockable Forms, and Toolbars. Once you are done looking at the example click Exit on the same menu to quit the example and restore your VFP IDE default menu.

PUBLIC colForms
colForms = NEWOBJECT("Collection")
ON SHUTDOWN CANCEL

DO CreateMenu

READ EVENTS
RELEASE colForms
SET SYSMENU TO DEFAULT

PROCEDURE CreateMenu
	SET SYSMENU TO
	SET SYSMENU AUTOMATIC

	DEFINE PAD CreateForm OF _MSYSMENU PROMPT "\<Create Forms" COLOR SCHEME 3 ;
		KEY ALT+C, ""

	ON PAD CreateForm OF _MSYSMENU ACTIVATE POPUP FormMenu

	DEFINE POPUP FormMenu MARGIN RELATIVE SHADOW COLOR SCHEME 4

	DEFINE BAR 1 OF FormMenu PROMPT "\<MDI Form"
	DEFINE BAR 2 OF FormMenu PROMPT "\<Dockable Form"
	DEFINE BAR 3 OF FormMenu PROMPT "\<Toolbar"
	DEFINE BAR 4 OF FormMenu PROMPT "E\<xit"

	ON SELECTION BAR 1 OF FormMenu ;
		DO CreateMDIForm
	ON SELECTION BAR 2 OF FormMenu ;
		DO CreateDockableForm
	ON SELECTION BAR 3 OF FormMenu ;
		DO CreateToolBar
	ON SELECTION BAR 4 OF FormMenu ;
		CLEAR EVENTS
ENDPROC

PROCEDURE CreateMDIForm
	colForms.add(NEWOBJECT("clsMDIForm"))
	DO SetupandShowForm
ENDPROC

PROCEDURE CreateDockableForm
	colForms.add(NEWOBJECT("clsDockForm"))
	DO SetupandShowForm
ENDPROC

PROCEDURE SetupandShowForm
	WITH colForms.item(colForms.count)
		.name = SYS(2015)
		.Caption = .name
		.Show(2)
	ENDWITH
ENDPROC

PROCEDURE CreateToolbar
	colForms.add(NEWOBJECT("clsToolbar"))
	DO SetupandShowForm
ENDPROC

DEFINE CLASS clsMDIForm as Form
	Autocenter = .T.
	MDIFORM = .T.
ENDDEFINE

DEFINE CLASS clsDockForm as Form
	Dockable = 1
ENDDEFINE

DEFINE CLASS clsToolbar as Toolbar
	ADD OBJECT Command1 AS CommandButton WITH height = 27, width = 27
	ADD OBJECT Separator1 as Separator WITH style = 1
	ADD OBJECT Command2 AS CommandButton WITH height = 27, width = 27
	ADD OBJECT Command3 AS CommandButton WITH height = 27, width = 27
	ADD OBJECT Separator2 as Separator WITH style = 1
	ADD OBJECT Combo1 as Combobox WITH  height = 27, width = 100
ENDDEFINE

http://www.sweetpotatosoftware.com

 

[awaresoft]

Craig,

Thank you for putting together that demo. It's a good illustration of the promise of dockable windows.

Since I don't normally use dockable windows in the VFP IDE, when I ran your demo it took some time to become acclimated to the art of using docked windows. Learning how to manage docked windows effectively appears to be a skill that needs some practice.

For others reading this thread, the technique for docking a form to an edge is to drag the form not only to the edge, but past the edge. During the process of moving your form offscreen, VFP will decide that you are making a docking request and dock your form to the edge - similar to a toolbar. To undock a form docked to the edge of the screen, click on its title bar and drag it away from the edge until it becomes undocked.

To dock multiple dockable forms to each other, drag the upper left corner of one dockable form over the upper left corner of another dockable form. To undock forms that are docked together, click and drag the form's tab out of the docked form collection.

Overall I found the concept of dockable windows to be very exciting. But I found the actual VFP 9 implementation to be rather awkward. Disclaimer: These observations may be specific to my VFP 9 setup or specific to my uncoordination<g>.

My observations:

1. I found the process of docking windows to the edge of the screen to be tedious and inconsistent. Sometimes VFP would recognize my docking attempts on the first shot. Othertimes I would have to repeatedly drag a window around the screen in order for VFP to detect the dock request.

2. I found it equally frustrating to try and undock forms that were docked together. Sometimes my undock attempts would be smooth and natural. Other times, my undock attempts would result in my undocked window snapping back to a docked position.

3. I found it disconcerting that docked windows can be dragged outside of the VFP screen - just like desktop windows. And once dragged out of the VFP screen, these windows do not consistently move or minimize with the main application.

Screen shot of this behavior:
http:://bdurham.com/downloads/vfpdocked_1.jpg

4. If one does a lot of docking and undocking, mystery windows begin to show up. These are dockable windows with just a captionless titlebar. These mystery windows show up randonmly on my system after I have made a lot of dock, undock attempts.

Screen shot of this behavior:

http://bdurham.com/downloads/vfpdocked_2.jpg

Conclusion: Docked windows have a ton of promise for efficiently building applications with customizable desktops. But ... I found the current VFP 9 implementation of docked windows to be a classic "1.0" release with the usual awkwardness and quirky behavior associated with first release technology.

Craig, thanks again for taking the time to describe how you use docked windows and for putting together a demo that let's others test drive this new technology for themselves.

Veryh much appreciated!

Regards,
Malcolm

 

[craigsboyd]

Malcolm,

You're welcome. A few comments...

When docking forms you'll always want to grab the titlebar of the form and it's not the window itself that determines the dock but the position of your mouse/cusor. Bringing your cursor within a few pixels of a dockable region (such as the sides of the _screen) while dragging a dockable form will result in a rubberband outline appearing (dotted line) showing where the form would be docked if you released the left mouse button.

Also, there are two types of docking that can occur when docking a dockable form with another dockable form. Stacked docking is when one dockable form is stacked on top of another dockable form. To create this you will drag one dockable form's title bar so it is just beneath the other dockable form's title bar and a rubberband outline will appear showing a square area with no tab on the bottom of it. These windows will now be stacked, and should they be docked in together but not docked to the _screen object then you will see a containing window created by VFP - this is the window without a caption in your screen shot.

Tabbed docking on the other hand is created by dragging one dockable form's titlebar over the top of another dockable form's titlebar. This should result in a rubberband outline that encompasses the form that is being dragged over the top of and includes an outline of the tab that will result if you drop the form.

It is important to always note that VFP cares little for where your form is in the dragging process and is only concerned with where the mouse/cursor is. So when I say drag the titlebar of one form over the titlebar of another, that is a bit of a misnomer... what I actually mean is start dragging on the form's titlebar until your mouse/cursor is over the other form's titlebar (for tabbed docking) or directly below the other form's titlebar for stacked docking. As for docking these forms to the top, bottom, right, or left of the _screen... vfp is concerned again with the position of the mouse/cursor and the dockable areas are the sides of the "client area" or the dockable areas of any other dockable form, to wit the titlebar or directly below the titlebar, or in the case of previously docked forms, all four sides of the docked form.

I agree with you that it all takes some getting used to, but it does follow window conventions for dockable forms and you will find that most windows applications that support these different types of docking will work in exactly the same way.

http://www.sweetpotatosoftware.com

 

[TamarGranor]

One more comment. Once you've docked a form once, you can undock and redock it by double-clicking on the title bar.

Tamar

 

[awaresoft]

Hi Craig,

Send me back to school! I would say I should RTFM, but I couldn't find instructions in the VFP online help.

OK, thanks to your great instructions, I went back and re-ran your demo. Now I get it! (Sidenote: Is there any way for me to go back and edit my earlier post so as not to mislead others following this thread?)

Any ideas if the following are possible?

1. Prevent docked forms from being converted to "desktop" windows that can be moved outside the screen?

2. Hide titlebars of docked forms to achieve a true "pane" (panel) like interface? One reason for doing this is that so users can't undock and move a carefully crafted set of docked forms?

3. Control color scheme used to display the tabbed region of docked forms?

4. Provide a caption for the container form that holds multiple docked forms? (What I previously refered to as my mystery forms)?

Thanks again for your patience in helping me understand VFP's dockable windows.

Malcolm (el stupido in NJ)