Charley, this looks perfect.
I just got a copy this morning and haven't had a chance to play with it yet, but reading through the documentation it looks like it will do what I need.
Wow, what a mess.
This is a perfect example of why I disagree with the way the EPDM design team thinks the solution to everything is an Add-in.
Basic functionality should be build into the program. If there are enough enhancement requests or complaints to compel them to write an add-in like this, then they should fix the program. I could see an add-in being a temporary stop gap if they are planning on implementing the changes in a service pack or next release, but that doesn't seem to be the case here given that the EdmVault5 object is 7 versions behind current (EdmVault13) I have to assume this sucker has been available for quite some time.
So what we have here is Add-in written by and provided by Solidworks corp.
There is little documentation on how to use it - barely a one page PDF that offers no explanation of the functions or limitations of the software, the underlying structure, etc.
All their little pdf shows is how to structure the command line arguments to launch their example file.
They give no explanation of what each argument does or how it is used.
The examples in the documentation don't actually work as written (have to change the filename and insert the path variable they instruct you on filling out, but which is not used at all by default when the add-in is first loaded).
On my first attempt to execute this program I got an error message stating there was an error in translating the arguments.
The error message informs me that I need to use the appropriate syntax and lists a syntax which is very different from what the documentation lists!
So which is it?!??
I ended up having to open the project in visual studio to see what the hell the syntax actually was.
The documentation does show the syntax that the program expects.
So the information contained in the error message is wrong. The "Catch" block for the arguments does not reflect the syntax of the arguments that are actually used.
My best guess is at some point in development the argument structure was changed, but that block of code was never updated because this is a poorly maintained bandaid solution.
It's poor code maintenance, and it's exactly why I think Add-in's are a terrible solution for core functionality behind an implementation.
As EPDM is a software designed to make document management easier/better I find it extremely ironic that their solution to everything is an add-in that is completely out of control as it is not under the project development umbrella. Seriously frustrating.
I wish I would have known how poorly written and maintained this software package was before we spent 10's of thousands on it.
Those are actually the reasons the code is available on the VAR portal but not the customer portal. It was only really meant as an example program for building out something more robust. I usually don't even bother with the compiled add-ins they put in these, I just take the code and strip it down and rebuild it anytime I find something like this because that's all it's really meant for anyway. Sorry about all the frustrations you're going through and I hope you're reporting everything to your VAR so they can create SPR's or get you attached to the right ones. SW has to prioritize bug fixes so they sort by the number of people affected, so getting attached to an SPR is the best way to get it fixed. Also you're a bit on the fringes with some of these issues, we do hundreds of implementations and I can only think of one or two that I had to get into input formulas or anything, I'd say 90% don't even use dispatch. Hope to see you in the Beta competition too, it's a great time to air your grievances directly to SW support guys and even occasionally the dev team.
I hear you on rebuilding the program. That's exactly what's so frustrating. I'm not a software developer. I have plenty of code experience, but that's not my job and it's not what makes my company money! On top of that, as someone with a lot of experience in this area, this becomes a VERY BIG maintenance nightmare. Oh, and let's talk about one more thing - with FDA and even some ISO regulations, auditors want to know how you've validated your software. Care to get into that can of worms when your functionality comes from a custom written program that was designed to work with a software you have no control over, and whose interop model changes constantly? (e.g. this addin uses EdmVault5 to login to the vault - a quick look at the EPDM interop namespace shows we are currently up to EdmVault13. Currently EdmVault5 still works, but it's already 8 versions behind - so for how long will it be supported?)
We were sold on EPDM being an out of the box solution that could be configured to handle our needs. Specifically, handle the document change management process. We were shown all these features and told how easy it was to setup conditional transitions and set variables and launch events/notifications based on state changes, etc. It all looks great in a couple hour presentation from your VAR, but the reality of getting this to work outside of what's been carefully setup for presentation is strikingly different.
For me, I'm frustrated because every single function in this software has a caveat. "Yeah you can do this, but only if you do that first, and not if you also want to do this." I'm also frustrated because the documentation sucks, and there are a ton of areas where the software acts differently than the documentation spells out. Oh, and error messages are the worst - they tell you nothing and often point you in the wrong direction. So now I just use them as a reason to check the log. Why even have an error message then if it's not going to be properly setup? Just have a message that says "error - check the log" rather than giving your users false information.
Yes I'm signed up for the beta challenge.
No, I haven't reported everything to my VAR. I vote for existing ER's and I start new ones when needed. My VAR has made it very clear to me that they only support troubleshooting bugs, and are not there to help me with my implementation issues.
While I may agree with you saying some of these questions I've posted are on the fringes of the capability of the software - keep in mind I explore multiple paths and do a lot of research before trying to do something. Most of the time if I'm posting a specific question on here, and it's a little out of the box, it's because the normal approaches DO NOT WORK and so I have to get out of the box.
I hate dispatch. It's a crap add-in and seems more of an afterthought meant to appease all the complaints against EPDM being so limited in what it allows you to do. Dispatch gives you extremely limited access to a handful of features and allows you to write 1970's spaghetti code scripts to execute in a singular instance. There is no modularity and it's shockingly ancient in architecture as well as laughably limited in it's reach through the EPDM object model landscape.
Okay, so off the EPDM bashing and on to trying to get this add-in working.
I did some digging and here is what I've determined each required argument is, and what it's function is.
I have not done any testing yet - just took a little time after hours to dig through the code. Plan to do some tests tomorrow.
The arguments are obtained from the Dispatch command line using Environment.GetCommandLineArgs() <- link to MSDN reference.
They populate a string array. The array index looks like this. I've listed what the argument should be, and how it is used by the program.
'0 = File name of the executing program. (path optional but not required - see the MSDN link above)
'1 = File name of the file you want to set a relation to. Poor coding practice - this AND argument 5 both control a single boolean variable. More poor coding practice, if you do NOT want to set any relation, you need to pass this argument as "N/A" . If you pass anything that is not a file location, or "N/A" then this looks like it will most likely will cause an error (untested). NOTE: This program appears to be designed around a single file being selected at a time. If you have a group of files selected and execute the action from a right-mouse click menu or something like that, I do not know what will happen. I assume it would just take the first file from the group and set the reference to it, but I could be wrong.
'2 = Name of a folder. As far as I can tell, this is used just to get the vault name so that the template can be found and executed in the correct vault. I would recommend simply passing this as the vault root folder e.g. %RootFolderPath%
'3 = This is the name of the template. According to the documentation this is "the string displayed in the SolidWorks Enterprise PDM menu for the template" - so whatever you typed there, make sure you copy and paste it here. (Just another reason to hate this Dispatch API solution - this is an extremely fragile relationship. There is nothing that would warn you that this relationship exists. So down the road, if you or some other admin decide to change the name of the template then all of a sudden you might have some serious workflow issues!)
'4 = I'm not entirely sure what the intent of this guy is. If you know what this is used for, please let me know - I'm very curious. It controls a boolean variable where "yes" = True, and anything else = False. If true then the program attempts to start a system process by passing the name of the file that was created by the template. If false no attempt is made. Now, I have no idea what scenario would generate a system process equal to the name of a file - it might be common, I'm just not familiar with that winAPI call and it's uses. Again, another example of poor coding practice - there is nothing to inform the user if this attempt was successful or if it failed. This does not appear to affect the execution of the template or the setting of references, so I'm really not sure what the point is.
'5 = This is another boolean argument for controlling whether or not a reference is to be set. "yes"=true, and "no" will set to false. Now this is a little tricky because if you pass the argument for file reference above, well then this guy gets set to true already and so you have to set it to "no" if you don't want it. Also, the conditions for setting the boolean value to true are a little strange to me: it wants this argument to be "yes" AND the file name argument to be a Null/Empty string. Now, that doesn't make a whole lot of sense at first glance because if the file name argument is null/empty then how could I set a reference?? I'll have to look more closely at this.
Anyways, if anyone else is having problems with this add-in maybe that will help you.
I'll probably end up customizing it to get my workflow to work the way I need, and I'm sure I'll regret it later when I end up with a maintenance issue on my hands - but I have no other choice at the moment as EPDM just cannot do what I need out of the box. (no matter how "on the fringe" i seem to get with it's basic functionality...)
Well, seems like I already have a maintenance nightmare on my hands - the code doesn't work out of the box.
This is the line that is failing.
I'm trying to debug now, but I can see in the locals window that the exception message is:
"You tried to log in twice."
And the error number is:
Going to start a new discussion on this...