August 2007 - Posts - David Airapetyan

InfoPath Dev

David Airapetyan

August 2007 - Posts

  • Automating DBXL tasks with the DBXL Migration Tool

    Two commonly requested features for Qdabra DBXL are automatically populating the database and migrating content from one site to another. We have developed a tool that allows you to do both.The DBXL Document Deployer is an XML-driven, command-line tool with pluggable architecture that is simple to configure and that can automate many operations you'd typically do manually via the DBXL Administration Tool (also known as DAT). A Document Deployer plug-in called the MigrationTool allows you to easily export document types along with their settings and documents from a DBXL instance and then subsequently re-import them into another one.

    Getting Started

    Download the tool here:

    The first step is to configure the tool to point to your local DBXL. Do this by selecting Programs/Qdabra DBXL Migration Tool/Configure from your start menu, changing the value of DbxlRoot to your local instance and saving the configuration file.The Document Deployer tool uses XML Scenario files that define the actions that need to be executed. Each scenario file is split into two sections: the complex ActionDefinitions part that defines various DBXL actions and the Runs section which invokes those actions.Defining action definitions can be a daunting task but do not worry, you can do a lot with the existing sample action definitions that ship with Document Deployer!  To start the Document Deployer shell, select Programs/Qdabra DBXL Migration Tool/DBXL Migration Tool.

    Here are a few examples of what you can do:

    1. Create sample taxonomy for the QdCatalogBase document type that ships with DBXL 2.1:
    DocumentDeployer.exe Scenarios\QdCatBaseTaxonomy.xml CreateTaxonomy      Note: taxonomies are used to browse forms via the QdCatalogBase taskpane.
    1. Deploy sample documents for the QdCatalogBase document type:
    DocumentDeployer.exe Scenarios\DeployQdCatBaseInstances.xml PopulateCatalogBase
    1. Publish a new document type that contains pictures:
    DocumentDeployer.exe Scenarios\DeployPictureForm.xml PublishPictures
    1. Bulk deployment of documents with pictures (requires a previous PublishPictures deployment, requires Vista):
    DocumentDeployer.exe Scenarios\DeployPictureForm.xml BulkDeploy
    1. Export the QdCatalogBase document type and all its documents
    DocumentDeployer.exe Scenarios\Migrate.xml ExportCatBase
    1. Export the QdCatalogBase document type, all its documents and the complete taxonomy
    DocumentDeployer.exe Scenarios\Migrate.xml ExportFullCatBaseIf you want to achieve other tasks either create a new scenario file or modify an existing one. Mind you that you can import action definitions from other scenario files without having to copy them over! See Scenarios\Migrate.xml for an example.DocumentDeployer comes with two documentation files (available from the Start menu via Programs/Qdabra DBXL Migration Tool) that contain more details on the tool itself and the MigrationTool plug-in. 

    List of all Scenario files and their Action Definitions


    This scenario defines actions that can populate the taxonomy for the qForm solution that ships as part of DBXL 2.1. It contains the following action definitions:

    -          AddHierarchy: adds a hierarchy to a specified doctype
    -          AddCategory: adds a category for a specified hierarchy
    -          ChainCategory: puts one category under another
    -          EnumerateDocumentIds: lists documents matching specific criteria
    -          RemoveEnumeratedDocuments: removes listed documents


    This scenario defines actions that can create instances of the qForm solution and accomplish complex tasks such as tagging documents and assigning workflow. It contains the following action definitions:

    -          GetHierarchy: gets the docid of a specific QdCatalogBase hierarchy
    -          EnumerateDocumentIds: lists documents matching specific criteria
    -          RemoveEnumeratedDocuments: removes listed documents
    -          RemoveAllDocuments: removes all documents for a doctype
    -          TagDocument: tags a document with a specified category
    -          AddEmailFlow: adds e-mail flow to a document
    -          AddCatalogBase: adds an instance of the qForm


    This scenario contains only one generic RemoveAllDocuments action definition that eases DBXL cleanup.


    This scenario demonstrates the use of compile-on-the-fly plugins and bulk deployment. It contains the following action definitions:

    -          UploadDoctype: uploads a hardcoded doctype (can be modified to be made more generic)
    -          AddPictureDocument: uploads one document with a base64-encoded image
    -          BulkDeploy: uses an external plug-in to upload all sample pictures (requires Vista to work as-is)


    This scenario defines action definitions for the MigrationTool plugin and allows to export/import documents and doctypes. It contains the following action definitions:

    -          ExportDocType: exports a specified doctype to a given folder
    -          ListDocumentsForDoctype: enumerates all documents for the specified doctype
    -          DownloadListedDocuments: exports documents listed by the previous action definition
    -          ImportDocType: imports a specified doctype into DBXL
    -          ImportDocuments: imports specified documents into DBXL
    -          ExportDoctypeWithTaxonomyAndFlow: a complex action definition that can export a qForm-derived solution along with all its taxonomy and flow
    -          ImportDoctypeWithTaxonomyAndFlow: a complex action definition that can import a qForm-derived solution along with all its taxonomy and flow


    Each of the scenario files (other than MigrateCore.xml) contains examples of how to use the actions. For document migration, the usage examples are in a separate file, Migrate.xml. This file also demonstrates how you can easily build your own scenario by importing action definitions from existing scenario files.

  • Showing custom modal dialogs in managed code

    A common question is to how to show custom dialogs using the InfoPath 2007 OM. In InfoPath 2003 one could use the ShowModalDialog OM function that would take an arbitrary HTML and show it. Although you can still use the old IP2003 OM in InfoPath 2007, there is a better option if you are writing in managed code, namely WinForms!

    If you are writing using IP2007 OM, you don't need to do anything special, System.Windows.Forms has already been referenced for you and the using statement has been included.

    If you are writing using IP2003 OM, make sure to select "Add Reference" for your project and add System.Windows.Forms. Now you can start showing message boxes or create your custom winforms and show them when needed.

    Important: you cannot use WinForms when developing for InfoPath Forms Server. This is because no .NET code can run on the client and running WinForms on the server makes little sense. If you cannot use WinForms, make sure your compatibility is not set to "Browser" in Design Checker.

    Scenario 1 - Show a simple confirmation box

    if (MessageBox.Show(
       "Are you sure",
    MessageBoxButtons.OKCancel) == DialogResult.OK)
    {      // do something

    Note: in IP2003 OM, you will have to prefix each WinForms type with "System.Windows.Forms". You cannot simply add a "using" statement because WinForms types will clash with the IP2003 ones. However you could use aliases in your using, for example:

    using WF=System.Windows.Forms;

    Scenario 2 – Show a custom dialog box


    Showing a custom dialog box is as simple as adding a new WinForm class to your project. Simply right-click the project in SolutionExplorer, select "Add" and then "Windows Form".

    Here is source code example for a Message Box that can show/hide additional details:

    To invoke it, call the following: new MessageBoxWithDetails(caption, message, details).ShowDialog();

    MessageBoxWithDetails is good to show exception data with the stack trace going into details, for example.

  • Implementing Cascading Dropdowns in Forms Server

    The InfoPath Team Blog has a great article on how to implement cascading dropdowns in InfoPath Forms Server (IPFS) without writing code: Unfortunately, this approach does not work in repeating context for the same reason Cascading Dropdowns are so hard in IPFS: there is no filtering on dropdown values.

    However, if you absolutely have to have those in a repeating table or a section, there is a workaround. It is not pretty because it requires you to write code (hence the form needs admin deployment which is much harder), it pollutes your main DOM and it is less performant (postbacks are needed any time you change the "master" dropdown). However it works!

    The approach relies on the fact that the data source for a dropdown can reside in the main DOM as well. Consider the following schema:


    There are two dropdowns in the repeating table, one bound to myCategory and one to mySubCategory. If the values for the second dropdown come from a secondary data source, they will be the same for all rows which is obviously not desired. However, adding the source under myRepeatingTable solves the problem:


    Now all you need to do is to bind the second dropdown values to mySubCategoryValues and then write an OnChange handler for myCategory to modify those dynamically.

    You can find a fully functional example here: 

    The zip file contains the ready-to-deploy XSN as well as the source code.

Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.