June 2004 - Posts

• Help!

  Help is available for InfoPath as part of its installation. But one particular help file is, in my opinion, more useful than the others. Depending on your installation path it can be found at: C:\Program Files\Microsoft Office\OFFICE11\1033\MSE10.CHM Why do I find this one so useful? Basically because it combines numerous help files into one. Here are the highlights: General Script Editor Information HTML in Microsoft Office Applications Working with Script and HTML in the Script Editor Customizing the Script Editor Managing Views and Windows Navigating, Searching, and Replacing InfoPath Developer's Reference Programming Concepts Developer Sample Forms Data Validation Events Structural Editing User Interface InfoPath Object Model Reference Collections Objects Properties Methods Events Enumerations InfoPath XSF Reference Namespaces Types Groups Elements Attributes MSXML 5.0 SDK GUID and ProgID Information Dependencies in MSXML 5.0 XML Developer’s Guide DOM Developer’s Guide How Do I? Program with DOM in C/C++ Program with DOM in C/C++ Using Smart Pointer Class Wrappers Program with DOM in Visual Basic Program with DOM in JScript DOM Reference XML DOM Objects/Interfaces XML DOM Properties XML DOM Methods XML DOM Events MSXML Helper APIs XML Digital Signature XML Digital Signature Developer's Guide XML Digital Signature Reference XML Digital Signature Interfaces XML Digital Signature Properties XML Digital Signature Methods XML Digital Signature Enumerated Types XML Digital Signature Elements XML Schemas XML Schemas Overview XSD Schema Developer's Guide XML Schema Reference (XSD) XML Schema Elements XML Data Types Reference XML Schema Regular Expressions XML Schema Instance Attributes XDR Schema Developer's Guide XDR Schema Reference XDR Schema Elements XDR Schema Data Types Reference DTD Developer's Guide DTD Reference SOM Developer’s Guide SOM Reference XSLT Developer’s Guide XSLT Reference XSLT Elements XSLT Functions XSLT Syntax XPath Developer’s Guide XPath Reference XPath Syntax XPath Functions SAX2 Developer’s Guide SAX2 Reference JScript JScript Language Reference JScript Tutorial Scripting Run-Time Library Reference FileSystemObject Object Tutorial VBScript VBScript Language Reference VBScript Tutorial Scripting Run-Time Library Reference FileSystemObject Object Tutorial Debugging Your Program in Office 10 Using the Debugger Inspecting Your Program Debugger Reference Visual Studio Getting Started Visual Studio Reference As you can see there is a lot of information contained in this one help file! Make a shortcut to it somewhere where you can easily access it, whether it be using a keyboard shortcut, on your Start menu, or in your Quick Launch Toolbar. As you are developing your InfoPath forms, you will undoubtedly have a need for the information contained in one or more sections of this help file. ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on InfoPathDev.com. Posted Jun 30 2004, 08:34 PM by Greg Collins with no comments Filed under: Help

• Conditional Formatting Conundrum

  STATUS: Fixed in InfoPath 2003 SP2. SCOPE: SP1 Managed Code. DESCRIPTION: I uncovered this bug on 2004-03-08 and reported it to my Microsoft contacts. It was at that point unknown to Microsoft. This bug is managed code specific, meaning it will not happen when using script. It is manifest when populating an xdCombo box control from the main DOM or from a secondary data source. Initially everything will work fine. But once the view has been roundtripped in the designer, the conditional formatting will be removed from this control. WORKAROUNDS: Download and install service pack 2 of InfoPath 2003. Use a section around your drop-down list box, and place the conditional formatting on the section. Place the drop-down list box in a preserve block. ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on InfoPathDev.com. Posted Jun 29 2004, 06:12 PM by Greg Collins with no comments Filed under: Conditional Formatting, Workarounds, Bugs

• I Just Can't Keep the Rules!

  STATUS: Potentially fixed in InfoPath 2003 SP2. DESCRIPTION: I uncovered this bug on 2004-02-17 and reported it to my Microsoft contacts. It was at that point unknown to Microsoft. The rules that you defined actually remain in the manifest. The bug is that the xsf:domEventHandlers block goes *POOF*! One way for this to happen is if you open the manifest.xsf file in the Visual Studio editor after rules have been created. But there are others. Since the xsf:ruleSets block is still in the manifest, you could potentially attempt to establish stub rules for your controls and then manually reattach the domEventHandler to the correct ruleSet. But this may be more work than is worth the effort! Having said all this, it can still be be very annoying and very problematic to have your rules disappear. But there are a couple of things that I do, in the mean time, to avoid getting hit by this problem. You may find them useful too: Keep a back up copy of your manifest each time you change rules, just in case this does happen. Whenever you publish, always shut down InfoPath and either close your solution, or shut down Visual Studio. Any time you modify a solution file other than FormCode.xx within Visual Studio, always shut down InfoPath and either close your solution, or shut down Visual Studio. WORKAROUNDS: One workaround is to replace rules with code in the OnAfterChange event. But this may not always be preferred. I know it's a pain and inconvenient. And unfortunately you are one of the few of us who do the kinds of things that cause this. Just be patient and play by the rules I outlined above and you should be good to avoid it. ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on InfoPathDev.com. Posted Jun 29 2004, 05:57 PM by Greg Collins with no comments Filed under: Rules, Visual Studio, Managed Code, Workarounds, Bugs, ruleSets, domEventHandlers, OnAfterChange

• Order of Processing at Startup

  In InfoPath SP1, the order of processing at startup of a form is: User Roles Open Rules OnLoad event handler OnSwitchView event handler The User Roles are processed first so that when the Open Rules are evaluated that they can take into account the current role. The Open Rules can be used to change the default view. Then, after these have processed, the OnLoad event handler will take over. At this point the View object doesn't exist and any functionality requiring it will fail. As a result, you cannot switch views at this point, but can change the default view. Lastly the default view is created and the OnSwitchView event handler is called. ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on InfoPathDev.com. Posted Jun 26 2004, 01:16 PM by Greg Collins with 1 comment(s) Filed under: OnSwitchView, OnLoad, Roles, Rules, Launch

• The Case of the Missing PI

  DAY 1 (2004-06-24) I was just working with a set of forms where a non-managed code (i.e. JScript)—hereafter referred to as NMC—form launches a managed code (i.e. C#)—hereafter referred to as MC—form and passes in its data using the new InfoPath 2003 SP1 method NewFromSolutionWithData. I ran into a bug that I have Microsoft tracking down as I write. The problem occurs only when managed code is involved. It is related to the Preview version of InfoPath 2003 SP1. I expect it will be fixed in the release version of SP1. If I use the NewFromSolutionWithData method going from a NMC form to another NMC form, then the problem does not present itself. But if I go from a NMC form to a MC form, or if I got from a MC form to either a NMC or MC form, the problem appears. So what exactly is the problem? The problem is that 2 of the 3 processing-instructions (PIs) that appear at the top of an InfoPath .xml file get striped out, namely the PI and the PI. Missing the former PI is not a great loss, but without that latter PI, Windows does not know that the .xml file belongs to InfoPath and will therefore not attempt to open it using InfoPath. Also this will result in the .xml file not having the InfoPath icon to identify it. Luckily, most InfoPath developers will not encounter this situation. A possible work around, if you know you will get hit by this bug, is to use the OnLoad event handler to manually add the missing PIs back into the XML. I haven't tested this yet, but believe it will work. DAY 2 (2004-06-25) Having played around a little with the code, my initial hunch was correct, there is a workaround and it is using code. This will require that you establish some way of knowing that your form was opened using the NewFromSolutionWithData method, and then in the OnLoad event handler you can add the following code: C# IXMLDOMProcessingInstruction oXML = thisXDocument.DOM.createProcessingInstruction("xml", "version=\"1.0\" encoding=\"UTF-8\""); IXMLDOMProcessingInstruction oPI = thisXDocument.DOM.createProcessingInstruction("mso-application", "progid=\"InfoPath.Document\""); thisXDocument.DOM.insertBefore((IXMLDOMNode)oPI, thisXDocument.DOM.firstChild); thisXDocument.DOM.insertBefore((IXMLDOMNode)oXML, thisXDocument.DOM.firstChild); JScript var oXML = XDocument.DOM.createProcessingInstruction("xml", "version=\"1.0\" encoding=\"UTF-8\""); var oPI = XDocument.DOM.createProcessingInstruction("mso-application", "progid=\"InfoPath.Document\""); XDocument.DOM.insertBefore(oPI, XDocument.DOM.firstChild); XDocument.DOM.insertBefore(oXML, XDocument.DOM.firstChild); Thus, when the form is saved, the two missing PIs will be back in place and your form will be ready to roll. ©2004 Greg Collins. All rights reserved. Licensed to Autonomy Systems, LLC for display on InfoPathDev.com. Posted Jun 24 2004, 05:57 PM by Greg Collins with no comments Filed under: OnLoad, Managed Code, Code, NewFromSolutionWithData, processing-instructions, Workarounds, Bugs, Script