Differentiate Save from Save As... in AppEvents_OnSaveDocument?

[bshbsh]

Hi all,

I'm having a macro which updates our database when a file is saved. This uses the AppEvents_OnSaveDocument event (amongst others but this is the problematic one).

The (rare, but annoying) problem is, when someone imports like a STEP file or something, and instead of saving it, he saves it with "save as" under a different name.

However, the event triggered kAfter still thinks the document in question is the imported and unsaved one, it even provides (non-existent, since never saved) filenames and such things - and this is where the macro fails since the file doesn't even exists.

What would be the best and fastest way to circumvent this? Right now I'm checking if the filesavecounter is not 0 before calling the update routine.

I see in the event Context that there are two filenames: one is the imported (unsaved) one and the other is the "save as" name. Could this be reliably used to detect save as?

I just don't wanna check for FileExists every time, that is too slow.

Thanks for any ideas.

[jjstr8]

Context will work fine.  It will either have value named "SaveFileName" or "SaveCopyAsFileName" based on how it's saved.  Assemblies are a little more complicated since there will be a slew of kBefore/kAfter triggers in between the kBefore and kAfter for the assembly itself.  Just ignore them until you get a kAfter where the "TopLevelSaveFileName" value matches Document.FullFileName, and then grab the "SaveFileName" or "SaveCopyAsFileName" value, whichever exists.

[bshbsh]

I've never worked with context/namevaluemaps, gotta look into it. just simply adding a watch shows the usual "item1", "item2", etc, no name assigned to the values. seems to be hard to figure out which is the save as name, unless they are in a strict order.

Seems to be a lot of extra work, comparisons, etc. (=slow) For now, Savecounter=0 seems to work.

Will experiment with it though, thanks.

[jjstr8]

Check the API help for more information.  "Context" is just the name of the parameter in the ApplicationEvents.OnSaveDocument event declaration.  It's a NameValueMap type, which is essentially a collection of key-value pairs.  The help file has information on accessing a NameValueMap object.  Accessing "Context" shouldn't be slow, but if you run into anything that seem slow, post your code for others to look at.  Inventor doesn't have any checks when accessing a NameValueMap, so if the name doesn't exist it will throw an exception.  It's probably easier just to loop through based on Count and look for a specific name.  It's 1-based index not a zero-based index in case you've tried it and get an error.