InfoPath Control Exited upon Tab Press

[Pete Loveall]

I have a form region (OL 2007 B2TR) using the InfoPath editor control (IP
2007 B2TR). When the cursor is placed in one of the InfoPath form fields,
pressing Tab causes the focus to leave InfoPath and go to the next tab stop
on the form region. IMO, pressing Tab should cause the cursor to go to the
next field within the InfoPath form. I am double posting to the Outlook
Programming Forms group since I am not sure if this is an issue with Outlook
or with the InfoPath control although I suspect that the InfoPath control is
never seeing the Tab key press.

Pete Loveall

 

[Bojana Marjanovic [MSFT]]

Pete, thanks for your post.

We're looking into this issue and need some more information from you:
1) Does this bug repro in the Preview Pane only? In other words, if you open the message does it still repro?
2) Can you send us a picture (screen shot) of your display?
3) Can you describe your scenario?

Thanks,
Bojana

 

[Pete Loveall]

1) Not using the Preview Pane. This is with creating a new message or
opening a message to read (although it is probably easiest for you to
recreate by creating a new message using the FormRegion as the template).

2) Create a FormRegion. Add the 4 fields listed below to that region. Add
the InfoPathEditor control to the toolbox and then to the region. Save it.
Create a formregion addin as described in the MSDN technical article. When
composing a new message of your formregion type, have the InfoPath control
open a form template that you have already created (template should have 2 or
more fields).

3) This is a replaceall FormRegion with 5 controls:

To (control automatically created by Outlook)
CC (control automatically created by Outlook)
Subject (control automatically created by Outlook)
Message (control automatically created by Outlook)
IPForm (InfoPathEditor control)

Unfortunately, due to this application being developed for a corporation, I
can't get too detailed in exactly what the InfoPath forms are or the
application specific programming that occurs in the addin. This should be
enough information to recreate the issue as there is no control-specific
programming occuring other than opening the InfoPath form upon message
opening/creation and handling of replies, forwarding, and sending (none of
which involve control events).

Thank you for looking at this.

Pete Loveall

 

[Bojana Marjanovic [MSFT]]

Thanks for the additional information, Pete. It seems that you've run into a
bug.

Can you give me a bit more information about your scenario. Please don't
divulge any technical details, just your process goals should be sufficient.
I'd like to have more information so I can work with you to find a
satisfactory workaround for this problem.

When describing the scenario you're trying to accomplish, please let me know
which areas are absolutely critical to your business needs and which can be
omitted.

Thanks again,
Bojana

 

[Pete Loveall]

The project uses the formregion capabilities of Outlook 2007 and the rapid
form design and implementation capabilities of InfoPath 2007. The reason for
not using the built-in InfoPath support in Outlook is because of bulk (that
implementation is very bulky since it sends the form in the message body as
well as sending the XML as an attachment). We require just the XML data to
be sent as an attachment.

The Outlook add-in baskcally uses the replaceall formregion to present a
standard message form (to, cc, subject, body) and the attachment as an
InfoPath form. If the message is opened to look at (a received message, for
instance), the InfoPath control opens the attachment and sets the form to
freeze the fields (read-only). If the person composes a new message of this
type, they see the formregion and are asked to select a InfoPath form
template to create their new form. If they reply or forward the message, the
reply/forward message is set to the proper type and then the message is
opened using the formregion in compose mode (and the IP form is opened in
read/write mode).

The InfoPath form data contents are critical to the application and require
that once the user has gotten into the form, their keystrokes act like they
would if they were in a stand-alone instance of InfoPath. As stated above,
we can't use the built-in Outlook or InfoPath email modes because of the
resulting message bulk. That leaves us with using the InfoPath Editor
control in Outlook which, except for the tab key issue, appears to do exactly
what we need it to.

I have looked for a method to report this as a bug (I too think it is a bug
in the Outlook formregion support of ActiveX controls) but I have not found a
vehicle to do so (I have reported bugs for other products such as SQL Server
2005 through MS' standard feedback portals).

Thanks for your help.

Pete

 

[Bojana Marjanovic [MSFT]]

It looks like there isn’t a way to do exactly what you want. You can send the
XML as an attachment, without sending the xsn, but it will also display in
the body of the message.

Hosting InfoPath in the Outlook Forms Region is not supported.

Sorry,
Bojana

 

[Pete Loveall]

Not true! The InfoPathEditor control is just a standard ActiveX (COM)
control which is supposed to be supported in Outlook Form Regions (it has
been supported in Outlook Forms in the past as well). There is a bug in the
Outlook 2007 B2TR Form Region implementation for ActiveX controls (and I
would guess that this is also true for ActiveX controls in Outlook forms). I
have further examined this and even though the ActiveX control is shown on
the tab order list, it is not made a tab stop in the Form Region showing that
the ActiveX control is not being handled correctly.

Forget about InfoPath for a moment and concentrate on ActiveX controls in
FormRegions. Create your own ActiveX control which might trap the tab key
and see that it doesn't work nor can you tab to your ActiveX control.

If there was a way to report this _bug_ to Microsoft, I would.

Pete