mightyBrowser – personalize your Inventor browser


Last week, we release a new app for Inventor: mightyBrowser. It updates the Inventor browser names, reflecting those iProperties that matters to you. Now you can finally recognize the components in your browser by the information that mean something to you!

Let’s say you like to see in the Inventor browser the title and the part number. With mightyBrowser you configure which iProperties shall be used in order to form the text that will be displayed in the browser. You can combine as many properties you like and mix them with plain text, such as separators and the like.

mightyBrowser works for both, Inventor stand alone and in combination with Vault. Just configure which iProperties shall be displayed, and you are good to go. In the standard, the title and the part number is configured. But feel free to configure it as you think is appropriate.


Once installed and configured, you will have to update the browser names manually. This is deliberately, as we don’t want to change your environment. However, if you like the outcome, you can configure the browser name update to be performed automatically on open and/or save. You can also configure whether in an assembly just the first level of the tree shall be updated or all levels. At any time, you can reset the browser to the original names.

There are some Inventor file types that are ignored by the mightyBrowser, such as functional documents and standard parts. Also the top display name of iFactories will not be changed, as this has an impact on the iMembers, so mightyBrowser does not touch this.

In the configuration file, you can find all the settings. Just have a look to the wiki. In case you like to see mightyBrowser in action, check out this video.


We hope you enjoy this new app!

Posted in Inventor | Leave a comment

Unique part number check


About a year ago, we posted how to pick a Vault item from within Inventor. It’s a simple Data Standard customization that helps designer assigning a Vault item right during the design process and so set the part number appropriately.

Recently we got a question, whether it’s possible to check if the part number is already used on another file – so is it unique within Vault. Obviously this is doable.

For this, we simply subscribed the property changed event of the part number in the Inventor Data Standard dialog. Whenever the part number gets set or changed, the event is triggered.

function InitializeWindow
      #rules applying for Inventor
      $Prop['Part Number'].add_PropertyChanged({
        if($source.PropertyName -eq "Value")

As you can see, in the InitializeWindow we added in the Inventor section the subscription to the property changed event for the part number. On every change of such property, our function PartNumberChanged is triggered.

In such function we perform a search in Vault. We look whether a file with such part number already exists. If yes, then we bring up a message to the user, saying the part number is already taken.

function PartNumberChanged
  $srchCond = New-Object Autodesk.Connectivity.WebServices.SrchCond[] 1
  $srchCond[0] = New-Object Autodesk.Connectivity.WebServices.SrchCond
  $srchCond[0].PropDefId = 88
  $srchCond[0].SrchOper  = 3
  $srchCond[0].SrchTxt = $Prop['Part Number'].Value
  $srchCond[0].PropTyp = "SingleProperty"
  $srchCond[0].SrchRule = "Must"
  $bookmark = ""
  $status = New-Object Autodesk.Connectivity.WebServices.SrchStatus
  $files = $vault.DocumentService.FindFilesBySearchConditions($srchCond,$null,$null, $false, $true, [ref]$bookmark, [ref]$status)
  if($files -ne $null) { [System.Windows.Forms.MessageBox]::Show("Part number already exists!!!!","Wrong part number",[System.Windows.Forms.MessageBoxButtons]::OK,[System.Windows.Forms.MessageBoxIcon]::Error) }

As you can see, we define a search condition where we set the property ID, the search operator, the value we search for, etc. Then we perform the search via FindFilesBySearchConditions. If you wonder how do I know the ID, operator, etc., well I used the vapiTrace to spy the Vault API. I just run a search in Vault with such criteria, this way I saw how Vault is doing it, and then copied the code in my script. On the other hand, the search operator is described in the SDK help, and the property definition ID can be retrieved from another API call. But to keep it simple, and because this code does not change once working, I took the short way.

Now you can give a try. There is just only one remark. If you use the dynamic properties for setting the part number, then the event will be triggered on every character you type. This is because the binding is set in this way. Therefore, the search in Vault is executed on each character, which may slow down the key entry and causes some unnecessary searches. Fortunately the Vault search is quite fast, so you will not experience delay in typing.

Like we did this customization for the part number, we can apply this to any other property you like to check in Vault. And it’s not limited to files. You may look for unique project numbers, or some item properties, or figure out the next free number with given pattern, etc.

I hop this helps!

Posted in Data Standard | Leave a comment

Save the path

With Data Standard 2016, the selection of a Vault folder got strongly improved. A series of dynamic combo-boxes lets you pick step by step the folder in where you will store you file. From several sources, we heard the wish to apply a “memory” to such comboboxes, so that the next time you save a new file, the path is already set to the previous selected path.

The solution is pretty simple. When you hit the OK button, the selected path chunks of each combobox shall be stored somewhere, i.e. in a local text file. The next time you save a new file and the Data Standard dialog shows up, the stored selections shall be applied to the comboboxes.

Although the solution is simple, and it’s doable in few lines of code, it’s important to understand some basics. For instance, a combobox provides several properties, such as SelectedValue, SelecteItem, SelectedIndex. All of these properties sets the focus on a given position of the list of values. In the case of the folder navigation with Data Standard, also called BreadCrumb, the comboboxes don’t just contain the according folder, but also the folder Vault ID. So, by using SelectedValue with a folder name, nothing happen, as the object in the combobox is not a text, but a combination of text and ID. Using SelectedItem would be better, but then we would have to set the folder name and folder ID. SelectedIndex is just a number from 0 to xx. By setting the SelectedIndex to 1, the second element of the list is selected.

So, to keep it simple, I just store the SelectedIndex of each combobox into a little text file, and reuse such index in order to set again the comboboxes on the next dialog. In the InitializeWindow function, you will find at the end of such function the command AddCombo -data $root which adds the first combo to the dialog. Right after, I’ll read the stored index from a local text file and set the combos to the according index, like this

function InitializeWindow
  if ($Prop["_CreateMode"].Value)
    AddCombo -data $root
    $path = Get-Content c:\temp\breadcrumb.txt
    for ($index = 0; $index -lt $path.Count; $index++) 

The lines 10 to 14 are the one added by me. This basically sets the combo to a default value, and so when the dialog shows up, the path is set to the last saved path.

As you can see, I’m accessing the comboboxes by the name “cmbBreadCrumb_”. This is bacuse in the code for the BreadCrumb, the comboboxes are called cmbBreadCrumb_0, cmbBreadCrumb_1, cmbBreadCrumb _2, etc.

The comboboxes are added dynamically. When you select a value on the first one, the second one will be added automatically with according child folders. So, I just have to set the first index, this will cause the addition of the second combo. By setting the index of the second combo, a third will be added. And so on.

In the OnPostCloseDialog we will save the current state of the comboboxes. We go through the current comboboxes and store the SelectedIndex into the local text file, like this:

function OnPostCloseDialog
  $breadCrumb = $dsWindow.FindName("BreadCrumb")
  $path = @()
  foreach ($cmb in $breadCrumb.Children) 
    $path += $cmb.SelectedIndex
  $path | Out-File c:\temp\breadcrumb.txt

As you can see, I’m searching for a control called BreadCrumb. That is the place holder where all the comboboxes will be displayed. In the saving routine above, I’m going through the children of the BreadCrumb, which are the according comboboxes, and save the index in to a variable $path which I then store into the local file breadcrumb.txt.

Now, this all would already work, but there is one little problem. As mentioned before, the comboboxes are added dynamically to the window. Unfortunately those comboboxes are added but not registered, so when try accessing a “cmbBreadCrumb_1”, for instance, we get an error message, as this element is now known. In order to solve this problem, we have a improve the code for the BreadCrumb. In the function AddCombo we have to register the new added combo. And in the function OnSelectionChanged we have to unregister the combos that will be removed in case the user selects another path. Hiere is the code.

function AddCombo($data)
  $breadCrumb.RegisterName($cmb.Name, $cmb)
  $dsDiag.Trace("<< AddCombo")


function OnSelectionChanged($sender)
  while($children -gt $position )
    $cmb = $breadCrumb.Children[$children]

In the function AddCombo I’ve added line 5 and in the OnSelectionChange the line 8.

Once this is done, you should now see how the path will be reset every time you save a new file.


Posted in Data Standard | Leave a comment

Data Standard – Drawing with same file name as models


In a recent webcast, we’ve received the question on how to disable the number generation within Data Standard for drawings. So, when you place a component in a drawing (IDW, DWG), the drawing shall have the same file name as the inserted model.

There is a switch in the option dialog of the Vault add-in within Inventor, but unfortunately such switch is not evaluated (yet) with the current release od Data Standard 2016. However, Data Standard is highly flexible, so there is a simple workaround.

As the dialog shows up, the function GetNumSchms is called. Such function provides the available numbering schemes. It’s a perfect place for providing just a specific list of numbering schemes for the given file type, or whatever. If this function returns nothing ($null), then the Data Standard dialog uses the file name suggested by Inventor, which is by default the name of the inserted model.

So, just open the default.ps1 file in the folder DataStandard\CAD\addins and go to the GetNumSchms. In such function, we will return $null in case the file has the extension idw or dwg. Like this:

function GetNumSchms
  if($Prop['_FileExt'].Value -eq 'idw' -or $Prop['_FileExt'].Value -eq 'dwg') { return $null }

The next time you’ll save a drawing in Inventor, you will notice that the numbering scheme is disabled and that the file name already reflects the name suggested by Inventor.

That’s it! I hope you enjoy.

Posted in Data Standard | Leave a comment

Ways of integrating Vault with ERP


powerGate is become quite popular and more ERP system are now connected to Vault via powerGate. There are basically three ways for connecting Vault with an ERP system via powerGate:

  • Online via native ERP API (SAP, Navision, proAlpha, myfactory, etc.)
  • Online via database (Sage, etc.)
  • Offline via file transfer (Abas, etc.)

We usually prefer doing online integrations, as the user has immediate feedback whether the transfer did work or not, and there is less need for having data redundant in both systems. However, where an online integration is not possible or nor welcome, the good old fashion file transfer is also OK.

A few weeks ago I’ve wrote about the integration we made with Sage, online via database. Today I’d like to tell you about the integration with ABAS. The usual way to exchange data with ABAS is via XML files. ABAS provides scripts for importing and exporting XML files. Therefore, powerGate will in this case read and write XML from and to a folder.

We wrote a small powerGate plugin which reads and writes XML files from and to an exchange folder. The usual entities are items, BOMs and project data.

As powerGate is a push/pull system, so it reads data from the ERP when needed and writes data into the ERP when necessary, we will cache the XML data into a little database. When a write (create/update) operation from Vault goes to ERP, in this case ABAS, the XML files are immediately written in the according folder, and additionally, the data is also stored into a database. When information from the ERP system are requested by Vault, new XML data from the ERP will be processed into our database, and the data is then read from the database.

The result is a sort of faked “online” integration. We can read ERP data whenever we want, and we can write data whenever is needed. The XML files produced by Vault (on writing) in the according folder can be processed by the ERP system when appropriate. The XML files produced by the ERP are processed whenever a read operation is performed in Vault.

You may argue that even in this way we have a redundancy. Yes, sort of, but it’s in an interim database which we can access and change whenever we like. If all the information would be stored in Vault, then updating ERP information would become more complex, as files or items could be released, checked out, and so on. By having the ERP data in a separate database, the update of the ERP information can happen right away, independently from the permission situation in Vault.

In our case, we use SQLite for the database. It has the advantage that no backend is needed. The SQLite database is just a bunch of files in a folder, so it’s super easy to setup and maintain, and it’s still fast enough and the size limit is at 35 TB. There are several editors that allows reading and editing data with SQLite, so in case there is a need to check or clean up the database, it’s straight forward. One editor, our preferred, is LINQPad.

There are surely other ways of doing such integration. For instance, by using a full SQL Server, or relinquish the SQL database at all. If you have other preferences, feel free to implement powerGate in other ways. This is the beauty of powerGate. You can write your own server plugin and expose the needed services to Vault for further consumption.

Posted in powerGate | Leave a comment

Data Standard – Dynamic Properties


Data Standard 2016 introduces the “dynamic properties”. A brilliant feature that allows you to use Data Standard right away with less need for customization. If you have assigned Vault properties to a category, then the Data Standard dialog will show those properties as you select the according category. In this way, you can achieve quite flexibility in the dialog without the need to configure or customize the dialog.

In the case of Vault, all the properties assigned to a category shows up when you select such category. In case of CAD just those properties will show up, which are mapped to the according CAD file. This is because only those properties can effectively sync the value back to Vault.

Dynamic properties is really dynamic. You can configure in which order the properties shall be displayed, and whether some properties shall be hidden from the dialog. This can be accomplished via the VaultDynamicProperties.xml file in the Vault\Configuration or InventorDynamicProperties.xml CAD\Configuration folder.

Such file is generated while you work with Data Standard. So, after the installation of Data Standard the file is not there. Start creating files, folders and other objects, and you will see the files being created and grow while you select different categories. Such file can be edited with any editor, such as the XML Notepad. By changing the order of the properties in such file, the order of the properties in the Data Standard dialog will change too. If you add an attribute Hidden=”True” to a property, such property will not be displayed in the dialog.

<DynamicPropertiesCategory Category="Engineering" Type="File">
<DynamicProperty Hidden="True">Manager</DynamicProperty>
<DynamicProperty>Engr Approved By</DynamicProperty>
<DynamicProperty>Stock Number</DynamicProperty>

Another thing you will notice with dynamic properties, is the red border of some properties, in case those are not compliant. If for instance a property in Vault is set to be obligatory, a red border will show up on that property. The tooltip tells the user what is missing. The rules on the properties can be applied on the Vault property it self, or on the association with the category. Therefore the property can have different behaviours based on which category the property is assigned to.

In order to show the red border and bring the tooltip, the binding mechanism between the property and the control on the dialog has been improved. A new binding method has been introduced, called WPF:ValidatedBinding. Instead of using {Binding …}, by using {WPF:ValidatedBinding …} the control can get this new graphical behaviour. The ValidatedBinding also takes care about the activation of the OK button. So, instead of showing some red * in front of the control and then catch in the code wether the entry is correct or not, by using the ValidateBinding, all happens automatically based on the Vault property settings.

Try it with the Title. Replace the Binding with WPF:ValidatedBinding on the title control, and you will see the difference.

<TextBox Text="{WPF:ValidatedBinding Prop[_XLTN_TITLE].Value, UpdateSourceTrigger=PropertyChanged}" Grid.Column="1" Grid.Row="10" />

Of course, in case you still need even more flexibility, you still can create you own control mechanism, but I guess that for the most cases, this new Binding will do the job, and so reduce the need for coding.

It’s important to use Update 2 (or newer) of Data Standard, as important improvements have been made with such update.

Enjoy Data Standard and dynamic properties.

Posted in Data Standard | Leave a comment

VDS 2016 Quick Reference


A few months ago we published the Data Standard Quick Reference for 2015 R2, which had quite a success. Now you can download the updated version for 2016 from here…

With 2016 you’ll find a new way to bind your controls with CAD file properties or Vault properties and automatically validate the fields. In case a field is configured as obligatory and it’s still empty, a red corner will adorn the control and the OK button will be disabled. You just have to use WPF:ValidatedBinding instead of Binding, like this

<!-- before -->
<TextBox Text="{Binding Prop[TITLE].Value …/>
<!-- now -->
<TextBox Text="{WPF:ValidatedBinding Prop[TITLE].Value …/>

Additionally a new property _GeneratedNumber has been introduced on the Vault side. This property is set as soon a number is generated via the number generator. In the function GetNewFileName, the new file name is set based either on the entered file name in case no numbering scheme is active, or based on the selected numbering scheme. The Property _GeneratedNumber tells you which number has been generated.

Have fun with Data Standard and the new Quick Reference.

Posted in Data Standard | Leave a comment