The control logic in Enterprise’s datacards can only include logic based on file’s variables. Weak. Life is more than just variables isn’t it?

The admin training manual shows a nice little trick of how you can control what people see on a datacard using tabs. You can control which tab is visible depending on a few factors…but even that is limited and tragically you can only show one tab at a time.

So here was my recent real world problem. Imagine having a card containing several edit boxes. Each edit box can only be modified by a certain corresponding user group….if a user is a member of more than one group, he needs access to the proper set of controls -users could be members of any combination of groups.

!!!!

Here was my solution:

1. On the card, I created a checkbox for each group
2. I set the control logic on these checkboxes so they would always be invisible. [Something like if the description contains the letter "A" or does not contain the letter "A" turn off the visibility. Even though they are invisible, you do want these to look rather neat because they can still be seen if being used as a search card.]
3. I set the control logic on the edit boxes I ultimately wanted to manage to look at the proper corresponding checkbox created in step 1.  i.e if the checkbox was checked, enable; else disable.
   (Click on thumbnail to enlarge)
4. I wrote an Enterprise add-in that fires anytime a file is checked out. This addin ensures only the proper checkboxes are checked. (i.e. if he is member of the group, check the checkbox, else clear it.)

Setting the proper checkboxes automatically enables the proper edit boxes. That’s it. Four easy steps. You owe me a turkey sandwich pizza.

(There is no reason to bother clearing the checkboxes at checkin, they are always correctly set when a user again checks out the file, and when the file is checked in all controls are disabled anyway.)

In a previous post, I spent a lot of time bashing my new friend, the Enterprise PDM function “GetVar”. The help file skims over the differences between “GetVar” and “GetVarFromDB”. So I thought it may be helpful to the world if I list them here.

[This would be so much easier to read in a table; but using this WordPress is like writing a novel with a crayon -not the skinny ones, the big fat ones that come eight in a box.]

If the file is checked out:
GetVar – retrieves the value the checked out person sees in his datacard
GetVarFromDB – retrieves the value from the version back in the vault

If the file is checked in:
GetVar – whines and cries like a baby and won’t work
GetVarFromDB – retrieves the value from the latest version in the vault

***
One other problem I have found with the help file. . .

Several times you’ll see an example that looks like this:
varEnum.GetVar("comment", "", value)
I’ve been told by API support that passing an empty string for the configuration is not proper etiquette. While it is true that it still works, there is an SPR out that may soon prevent this from working. The code for getting the part level variable should look like this:
varEnum.GetVar("comment", "@", value)

Keep an eye on this one when upgrading.

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!