Docked User Forms in Word - the Best Practice   

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?

date: 4 May 2006 11:42:23 -0700   author:   unknown

Re: Docked User Forms in Word - the Best Practice   

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.





 wrote in message 
news:1146768143.039189.194740@j33g2000cwa.googlegroups.com...
> 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?
>

date: Fri, 5 May 2006 13:57:30 +1000   author:   Jezebel

Re: Docked User Forms in Word - the Best Practice   

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.

date: 5 May 2006 00:02:33 -0700   author:   unknown