Hosting an InfoPath form inside WPF via ShowUI

Aug 9, 2014 at 3:55 PM
All,

Being able to reuse InfoPath forms with the "Submit to environment" option via Show-UI could be a fantastic step forwards. In principle this should be possible as InfoPath forms may be hosted within WPF.

Hosting an InfoPath form inside WPF seems reasonably straightforward, see for example

https://wpfinfopath.codeplex.com/releases/view/7062

That example fires up a WPF GUI, prompts the user for an InfoPath form, loads the form and then allows the user to manipulate it, entering data.

Since, as I understand it, Show-UI wraps the .NET classes behind WPF, it should be possible to get the same behaviour via Show-UI, perhaps with a little careful tweaking of how the Cmdlet generators work. Does anyone have any ideas about how this could be accomplished or an example of hosting InfoPath forms via a PowerShell layer?

Building a Cmdlet with a workflow such as
Get-InfoPath -FilePath MyForm.xml | <code to process result>
would be fantastic, as would:
StackPanel -ControlName 'Get-InfoPath' {
   New-InfoPath -Path MyForm.xml

...
} -Show
Coordinator
Aug 10, 2014 at 5:32 AM
Edited Aug 10, 2014 at 6:39 AM
You should be able to take that dll and use Add-UIModule on it to generate a module, but InfoPath is COM, and it looks like it's only registered as x86, so you'll have to run the 32bit version of PowerShell...
# Import the FormControl assembly from Program Files x86 -- NOT the GAC
Add-Type -Path "C:\Program Files (x86)\Microsoft Office\Office15\Microsoft.Office.InfoPath.FormControl.dll"

Add-UIModule -Type ([Microsoft.Office.InfoPath.FormControl]) -RequiredAssemblies Microsoft.Office.InfoPath.FormControl, System.Windows.Forms -Name ~\Documents\WindowsPowerShell\Modules\InfoPathUI\InfoPathUI.psd1
That should be enough, but on my copy there was a bug in the generated module manifest, where it had a space inside the quotes on the file name:
FunctionsToExport = @('New-FormControl ') 
Which should not have a space inside the quotes.


Anyway, as far as I can tell there are only a couple other types in that assembly, and you don't need any of them. Something like this example should work, but I could not get it to run (there were several COM component crashes), so I'm obviously missing something important with InfoPath (which I've never used):
New-WindowsFormsHost -MinWidth 400 -MinHeight 600 {
      $InfoPath = New-FormControl
      $InfoPath.NewFromFormTemplate( (Convert-Path "~\Documents\Email.xsn") )
      $InfoPath
} -Show
If you try that and get 0x80040154 that's because you're in x64 PowerShell and InfoPath is 32Bit.

But the 0x8007045A error, on the other hand, I don't know how to deal with. I think it's because the InfoPath DLLs are from Office 13 not Office 15 which is what I have installed (and so Office 13 isn't activated):
System.IO.FileLoadException: A dynamic link library (DLL) initialization routine failed.
Exception from HRESULT: 0x8007045A
It also produces this error:
The operating system is not presently configured to run this application.