Docked User Forms in Word - the Best Practice

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

oleg.krupnov@gmail.com - 04 May 2006 19:42 GMT

I've seen this topic discussed many times in this group, but I've never
seen what is ultimately the best practice of creating a window that
should not modal (i.e. shows while the document can be edited) and
should not obscure any part of the document.

It's desirable to have a solution for a few recent versions of Word,
not only the last one (2003).

The following is the summary of all ways I know to achieve the subject

- there are task panes (in 2003) non-programmable in VBA. They say you
can program it with VB.NET because the task pane is a "managed"
control, but I'm not sure it's worth the trouble of switching to
another platform and losing backward compatibility. Anyway, it works
only for 2003.

- to create a command-bar with custom controls pretending to be
buttons. This one looks to be too hacky and not guaranteed to work on
all machines.

- to create a modeless window without docking and then place it over a
task pane, command bar or another "native" dockable panel. A load of
code is required to move/size the window synchronously with the panel.
Alternatively, one can downsize the Word window and place the modeless
window beside.

- to create a modeless window and forget about docking :) Actually, it
may not be that bad solution, but the window unfortunately doesn't look
like a toolwindow and the main window loses active state when the tool
window is activated. In effect, it looks miserable.

I believe that creating a modeless window (tool window) is a common
task for VBA programmers, so there should be a legal and recommended
way of doing this!

Any ideas?

Reply to this Message

Jezebel - 05 May 2006 04:57 GMT

Best practice is to use the built-in methods and standard interface as far
as possible. All built-in tools in Word are provided via menus and toolbars.
Why not do likewise? -- Use a standard toolbar, with buttons (not controls).

Or, use VB (instead of VBA) which provides a much more powerful range of
form options.

> I've seen this topic discussed many times in this group, but I've never
> seen what is ultimately the best practice of creating a window that
[quoted text clipped - 32 lines]
>
> Any ideas?

Reply to this Message

oleg.krupnov@gmail.com - 05 May 2006 08:02 GMT

I agree completely that the standard interface should be considered in
the first place.

However, I need to place, say, a tree view control or a custom contol
on the form, whereas the command bars only support buttons and combo
boxes, so it won't do. Perhaps you thought that "tool window" implies a
tool bar, but it's not necessarily so - a tool window is just a
subordinate non-modal form.

Actually, it's not a problem to design a non-modal form and put various
controls on it, the problem is how to make it look like a native tool
window and dock it to the border of document window.

Reply to this Message