ProjectSaving and Save As...

JohanAlthoff wrote on 3/1/2012, 5:15 AM

...Is a bit broken. If the user chooses a new name for the project using Save As..., the ProjectSaving event cannot access the newly given name, making things a bit difficult if you, like me, are trying to write a Perforce plugin for Vegas =)

Does anyone know of a reasonable workaround?

Comments

Gary James wrote on 3/1/2012, 7:44 AM

Are you saying the Vegas.Project.FilePath property is returning the wrong file path?

JohanAlthoff wrote on 3/1/2012, 8:58 AM

In a word: Yes.

The situation is this: Two project files, foo.veg and bar.veg, are both under source control. The user Opens foo.veg, and saves it as bar.veg, but bar.veg isn't checked out. It is flagged as read-only, and cannot be saved to. My intended behavior for the script was to intercept this failure, present the user with an option to check out bar.veg, and then allow the saving to proceed gracefully.

The problem, as I described above, is that myVegas.Project.FilePath is still set at foo.bar during the ProjectSaving event, even though the user is actually trying to save bar.veg. While it can be argued that this behavior is intended -- while ProjectSaving is running, Vegas hasn't actually saved anything -- it screws with the usability of the whole process, as I have no way of determining that the project file name is about to change.

My workaround right now is to have the script bypass my Perforce code if the Shift key is held, and instruct my team to utilize this workaround when using Save As. It's very, very ugly, but it's the only thing I can think of.

My suggestion for a fix would be that myVegas.Project.FilePath would be changed prior to ProjectSaving firing, so that the property always reflects the file that is about to get saved.

Gary James wrote on 3/1/2012, 9:33 AM

I'm using the ProjectSaved event in my free Sony Vegas Pro (SVP) extension utility Timeline Tools to save the utility configuration settings along with the project .veg file in the same sub-directory.

For backward compatibility for SVP v8.0 and up, my DLL is linked to the version 8.0 Sony.Vegas.DLL. There isn't any event in this dll named ProjectSaving. This must be a feature of a later version of SVP. I agree with your suspicion that ProjectSaving must be an event that's fired at the start of the file save process. I would guess at the time the event is fired, the file doesn't actually exist yet; at least not until the ProjectSaved event is fired later.

Although Vegas has an extensive set of events and API functions, it still has a long way to go before it can be used in a co-operative environment like your application requires. My biggest gripe is the lack of programmatic control of all the FX plug-in and generated media configuration settings. The only control I have over these is to load a saved preset.

It sounds like your only solution is to make sure the user checks out both project files at the start of a Vegas editing session.

Gary ...

JohnnyB wrote on 3/22/2012, 1:12 PM

Yes, there is a problem here. The new name isn't available at the point you get the event.

In the true tradition of bodging known and loved by programmers, I've done a workaround for this, which works ok.

Basically, I remember what the project is/was, and when the event happens, I check the project name a little while later, and at that point it knows the correct new name. Silly, but the window before it knows the real project name is fairly short, and the user's unlikely to have done anything substantive in that time.