You know the old joke: “I like to keep hitting my head against the wall because it feels so good when I stop.”?

I think I figured out why I like programming.

First, will all of you SolidWorks Enterprise PDM admins join me in protest of the function “IEdmEnumeratorVariable8:GetVar”? Why do I have to have write permissions of the file just to read the variable?! …but more on that later.

I just wrote a cute little routine that checks out a file, does some file manipulation, then checks the file back in. Easy and sweet. Worked great when I tested it on its own but I was getting many problems when I included it into my add-in.

Hours go by. Testing it outside works, testing it in the intended environment [within an add-in] no work-ie.

Any guesses? It is an obvious answer once you hear it.

Yeah, My add-in also did some small variable checks when the file got checked out [EdmCmd_PostLock] -these checks used the soon to be boycotted “GetVar” function. Thus my original routine was checking out the file, which was then calling the checkout hooks which were trying to checkout the file. Two separate routines trying to get write access to the same file. You don’t need to be an Engineering Data Specialist to know that is a bad thing.

Chant with me: “No more GetVar! With GetVar you won’t go far! No more GetVar”!

Please excuse me while I leave to get some ice for the bump on my head.

(Once I found the problem, the fix was easy. I had several options. I chose to change GetVar to GetVarFromDb.)

It appears the folks at SolidWorks heard my gripe about their naming convention. Though the name couldn’t be much longer.

SolidWorks’ virtual components are so, so sweet. The fact that SolidWorks Enterprise PDM supports them adds just a bit more butter on top of the piece of toast. …but…what if you need to assign a virtual component a part number before you save it out as its own file? You cannot use SolidWorks Enterprise PDM’s serial number generator because you have no way to get the number nor tell the generator you manually assigned a number.

Here is a nice little SolidWorks macro to get you started. It simply finds the next available serial number and returns it to the user in a message box. The user can use this assigned number in anyway he chooses.

[You'll need to replace "Trains" with your vault name and "PartNumber" with the name of your serial number.]

'remember to add PDMWE Type Lib as a reference!
Sub main()
Dim objVault As IEdmVault8
Dim objSerNoGenerator As IEdmSerNoGen6
Set objVault = New EdmVault5
objVault.LoginAuto "Trains", 0 'use name of your vault
Set objSerNoGenerator = objVault
strNewNumber = objSerNoGenerator.GenerateSerNo(_
"PartNumber", 0, "", 0, 0, 0, 0)
MsgBox "The next avaliable part number is: " _
& strNewNumber
Set objSerNoGenerator = Nothing
Set objVault = Nothing
End Sub

Anytime you need the next avaliable serial number this could be used. i.e. files added via Pack and Go, drag and drop…

PDMWorks Enterprise 2008 introduced a new ability to automatically export your BOMs during transitions in your work flow. To date though I had not found any example code of how to extract the information from the XML file once it was created.

Luckily, I caught my buddy Philip Stears deep down in his dark lab writing this little diddy.

'Create the document object ready

Dim document As New XmlDocument()
Try
'Load the document from disk
document.Load("WorldDominationPlan.xml")
' Get hold of the root element in the XML file
Dim rootElement As XmlElement = document.DocumentElement
' Go through each element in it called "Property"
For Each childElement As XmlElement In _
rootElement.GetElementsByTagName("Property")
' Get the name and value attributes
Dim name As String = childElement.GetAttribute("Name")
Dim value As String = childElement.GetAttribute("Value")
'Do something clever with them
TakeOverTheWorld(name, value)
Next
Catch ex As Exception
' Foiled again, try again tomorrow
Foiled(ex)
End Try


He was in process of writing the “TakeOverTheWorld” subroutine, luckily I caught Philip just in time. Engineering Data Specialist Man saves the day again!

Friday I left my customer in New Philadelphia to look at his 5000 files (see part 2) for another customer in Cincinnati. They had just bought PDMWorks Enterprise and have asked me to convert their legacy data from Activault.

As you would expect, no Activault manuals could be found. It took me a while, but I was finally able to figure their Activault’s database schema. Once this was done I was pretty much home free to write code to find the old file, match it with the custom properties they wanted to keep then add it to the PDMWorks Enterprise vault.

I actually wrote the code in the Activault’s .mbd file. I am beginning to like witting code like this in MS Access. I find I get two great advantages: I don’t have to install Visual Studio on the customer’s machine, and the VBA in Access gives pretty quick ‘n’ easy access to the database.

….plus I got to enjoy the irony of using Activault’s database to contain code to cause its demise. (That being said Activault’s database structure is quite clean and appears to provide a snappy interface.)

The customer’s new PDMWorks Enterprise server is a Dell PowerEdge 2970. I cannot sing enough praises over this machine. I first ran a test conversion on my Dell M90 laptop and it took almost eight hours to convert their 19,752 files. Their PowerEdge did it in about 50 minutes.

Whooowee working with a database like found in PDMWorks Enterprise is a lot more fun than working with PDMWorks Workgroup! …Back to New Philadelphia next week to finish that project.

Okay, wow…the bulk load tool took nearly eight hours to check the files into the vault. The log reports that just under 11,000 files went into the vault. The remaining files appear to be duplicates of files already in the vault. A nice side benefit of the bulk load tool. We’ll have to spend some more time analyzing the 5,000 files that did not go into the vault to confirm this…

Looks like we just dodged a bullet. The legacy files are on the same server as the Workgroup vault. Essentially we duplicated 11,000 files and their server is dangerously full! (Need to confirm this is why 5,000 files didn’t make the trip!)

So looks like I need to write a routine to delete the legacy files. This means I need to do two things I don’t like to do:

1. Write code quickly with people looking over my shoulder
2. Write destructive code…I hate writing code to remove data. Too much stress! [A moment of prayer to the backup gods.]

The bulk load tool doesn’t store the full file path, so I need to search for each file one at a time. This code is going to run slower than the bulk load tool. Looks like another routine to run overnight. At least this can run as a parallel process to the rest of the import.

Customer is looking at the files that didn’t make the trip, if all looks good, it will be time for my programming to shine.

What does an Engineering Data Specialist do? Mostly I help people create engineering data [DriveWorks, SolidWorks, API, best practices] and maintain their existing data. [PDM, API].

I have just received an assignment to help one of our customers in New Philadelphia, Ohio (just south of Canton) move their legacy data into PDMWorks Workgroup. However there are a few twists:

• They have been using Workgroup for a while now, current assemblies can reference files in or out of the vault.
• The legacy files use a different naming convention than they use now. Most notably the file name contains the revision letter. They want all files that go into the vault to meet their current naming convention.
• The files need to go into the proper Workgroup project….this project is calculated by the file name.

So the battle plan is:

• use the bulk load tool to put the files into a temporary project
• use PDMWorks’ API to rename the files
• use API to delete all but the latest version of the files (first ensuring the files aren’t referenced somewhere)
• use the API to move the files into the proper project

Putting the files in early and using the bulk load tool, gives us a couple of advantages. I don’t have to write code to add the files, I can use Workgroup’s the API to handle the moving and renaming -the file references for the SolidWorks files should remanin intact.

We are looking at adding just slightly over 16,000 files. It took nearly four hours just for the bulk load tool to dig through their existing directories – looking for SolidWorks files to add. (We’ll do their AutoCAD files later.)

The files are being checked in now, it looks like it is going to be a long process. I’m going to let it run overnight and we’ll look at the report in the morning.

A common PDMWorks Enterprise enhancement request is to give the users the ability to pick and choose who gets notified when a document goes through a workflow transition.

While personally that request seems like it would make a loophole users could use to get around the system i.e. not notifying your manager or quality control if a document is approved. -I’ll grant there may be cases where it would be useful.

So I thought I’d give you a little application that could be used to get you started in creating your own. There are fancier ways this could be done but this provides a very flexible solution and the price is right eh?

The program would be kicked off as an “action” as a document goes through a transition. [As an example see screen shot.]

Note the full file name is sent as a command line argument using the “File Path” tag. This is how the file name gets sent to the program. Additionally, ensure the compiled .exe program is in a location where everyone has access to it.

Once started by the PDMWorks Enterprise transition, this routine simply creates a pre-populated Outlook message -populated with anything you choose. Typically the body of the message wouldn’t need to contain much -mostly just containing a link to the file that triggered the routine and some minimal instructions. The user would then, in this Outlook message, choose who to send the email to. He could also modify the body of the email if he chose. Then when the email looks as he likes he simply clicks “send”.

Here is the .NET code. Feel free to modify it to fit your needs, just keep the first comment line in!

Imports Microsoft.Office.Interop
Imports Microsoft.VisualBasic
Module modMain
Public Sub Main()
'by Jeff Sweeney, may he live long and prosper
Dim strFileName As String = Interaction.Command()
Dim objOutlook As Outlook.Application
Dim objNameSpace As Outlook.NameSpace
Dim objMailFolder As Outlook.MAPIFolder
Dim objMailItem As Outlook.MailItem
objOutlook = CreateObject("Outlook.application")
objNameSpace = objOutlook.GetNamespace("MAPI")
objMailFolder = objNameSpace.GetDefaultFolder(4)
objMailItem = objMailFolder.Items.Add
objMailItem.Subject = "A file needs your approval"
objMailItem.HTMLBody = strFileName & " has gone through a transition and requires you to do something"
objMailItem.Display()'gives the user a chance to modify
objMailItem = Nothing
objMailFolder = Nothing
objNameSpace = Nothing
objOutlook = Nothing
End Sub
End Module


Tip: Don’t forget you will need to add Outlook as a reference in your .NET project. Otherwise simply compile as a “Console Application” and you are set!

This is just the tip of the iceberg. You could change the routine to accept more than one parameter. An additional parameter could be the transition name, so you could get different emails depending on the transition that called it. You could have the routine examine the extension of the file and do different things depending on the file’s extension.

I’d love to learn how you end up using it!

Since PDMWorks Enterprise 2008 will not support custom applications written in VB6, I know a lot of you are busy converting your code to .NET. Here is a little “gotcha” to watch out for:

I had a little routine that would write to a file’s datacard at check in time. [EdmCmd_PreUnlock] It worked great in VB6 but when I converted it to .NET, PDMWorks Enterprise could not finish the check in operation telling me that the file was in use by another process.

I wept openly for about two hours before I finally found this little diddy in the help file:

The IEdmEnumeratorVariable interfaces are designed to keep the file open while the interface exists. This means that other operations on the file may fail with sharing violations while the interface exists. The recommendation in PWE 2008 and later is to always call the IEdmEnumeratorVariable8.CloseFile method when you are finished updating a file. The call will make it possible for other applications and API-functions to access the file again. This recommendation replaces the earlier work-arounds to explicitly clear IEdmEnumeratorVariable pointers (set them to Nothing in Visual Basic) and to call Marshal.ReleaseComObject in .Net applications.

The weird thing was that I was already setting my object = Nothing, but it still didn’t matter. (Nor did GC.Collect) When I added the suggested “CloseFile” method, all went smoothly!