Call native Vault commands on button

Call native Vault commands on button

Majjek
Advocate Advocate
1,544 Views
7 Replies
Message 1 of 8

Call native Vault commands on button

Majjek
Advocate
Advocate

Hi,

 

I'm just getting into Vault Extensions and want to know if below if possible:

I want to create some sort of pre-check on the Change State event.

So before I click on Change State, I want to pop up a form to fill in/check properties, then save the properties and then if I click proceed on that form, continue to the actual native Change State command from Vault.

Or if I click Cancel, it doesn't fire the Change State command at all.

 

So I can imagine the following:

1. Hide the original command button for Change State.

2. Substitute it with my own button+commanditem.

3. When I press a button on my form, execute the native Change State commanditem, which would normally fire when pressing change state.

 

I'm able to connect to the ChangeState event of the DocumentService, but I want to do something before the Change State window pops up.

I'm also able to catch the command via the CommandBegin event, so I know the id of the commanditem (ChangeLifecycleState).

 

But I don't know how to execute a native command from Vault, in this case Change State.

 

Can anybody help me with this?

I work with Vault Professional 2021 and my extension is in VB.net.

 

Thanks in advance.

0 Likes
Accepted solutions (1)
1,545 Views
7 Replies
Replies (7)
Message 2 of 8

Anonymous
Not applicable
Accepted solution

I posted a potential solution here:  https://forums.autodesk.com/t5/vault-customization/possibly-to-subscribe-to-file-status-changes-via-...

 

I'm not sure you can call the command in the Vault Client, because I believe it is just calling the API to trigger some events and then handling the events as it's own listener.  We certainly do something similar to what your talking about, maybe not exact, but similar.  what we do is listen for state changes, and if the state change is one in particular, we catch it, and then look at the file to check for things like missing properties, whether it's in the right lifecycle, etc.  If any of those things are out of whack, we stop the event and throw an error message back to the screen.  The basis of that behavior is a listening service as described in the link above, and then handling the events.

 

0 Likes
Message 3 of 8

Majjek
Advocate
Advocate

Hello,

 

First of, thanks for your response.

It's very interesting indeed, and maybe something I can use.

But for my current situation, I actually want to be able to check the properties before starting the change state command.

Because I also want to give warnings, for example on a combination of properties which are 90% of the times OK, but in some cases they need to be different.

So it's not always (only) checking if a property is filled in correctly or not.

Raising a restriction causes the Change State command to be undone.

0 Likes
Message 4 of 8

Anonymous
Not applicable

This is a case where you actually do have that capability.  Since the solution is essentially setting up a listener that catches every state change event, you will indeed have the opportunity to check your properties before the event actually happens.  If I remember, there is a pre-change event, a change event, and a post change event, you just setup on the pre-change event and do your stuff.  From there you can either do something to stop the event, or even handle PART of the event and then re-fire it to other subscribers.  This solution isn't really about properties, it's more about event handling in other places outside of the Vault client.  You can handle the events and do whatever you want - check the state of a file, check whether the file is in the proper lifecycle, check properties, you could even fire up ACCORECONSOLE of some Inventor logic to do something.  Once your done, you can, as stated, pass it on or raise your restriction and halt the event entirely.

0 Likes
Message 5 of 8

Majjek
Advocate
Advocate

Aha, then I didn't understand your post completely.

So what I should be able to do, is catch the event, pause/stop it, show my own userform, do checks, let users modify properties if needed and then choose to continue or stop the event.

0 Likes
Message 6 of 8

Anonymous
Not applicable

Correct, you should be able to accomplish what you are needing to do.  As an example, in the video above, we actually catch the pre change event (I think, can't remember which one), but we catch it, then check the selected files lifecycle to see if they are in the proper lifecycle, then we run though the list of selected files and verify certain properties have values and that the values meet certain critieria, and if ALL of the 'QARules' are met, we let the state be changed.  If ANY rule fails, we stop all files from transitioning and pop up a dialog with the list of issues on the files.  We use the standard Vault error dialog, but we could easily use another custom one.  We could also let certain files through, but we don't because we want the users to learn what to fix and why they should.  But we could certainly address certain things in code ourselves.  

 

I think maybe the only thing you might have to concern yourself with is that your working with web services so you have to consider timeout times and asynchronous operations and things, the devil is in the details of course.  But I feel pretty confident you can pull of what you need to do if you create yourself an 'interceptor' that grabs onto and handles those events from the WebServiceManager.

0 Likes
Message 7 of 8

Majjek
Advocate
Advocate

Then your solution sounds exactly like what I need 😁.

Thanks a lot for your input.

 

Unfortunately I can't start working on this right away, because of other priorities.

But this will save me a lot of time figuring things out!

 

When I actually start and run into some difficulties, can I send you a PM for details?

0 Likes
Message 8 of 8

Anonymous
Not applicable
Of course
0 Likes