Oh my! There has been quite a bit of activity here while I was asleep.
Peter: It looks like you've solved your problem. Congrats! In my case, there really wasn't any cancel-able SaveRecord event I could register against.
For others that may follow, what I've managed to deduce is that the DAG generates form and window objects in a fairly consistent manner, but the methods, events and properties obviously depends on the Dexterity implementer. Taking your PmTransactionEntry as an example, I can get hold of the form itself via the Microsoft.Dexterity.Applications.Dynamics.Forms.PmTransactionEntry reference. The consistent bits under each such form is the presence of the following standard object references:
- Commands
- Functions
- Procedures
- Tables
Again, the contents of each of these objects depends on the Dexterity implementer. In addition, the form object contains an object reference to each of the Windows owned by the form. In the case of the PmTransactionEntry, the main window appears to also be called by the same name; so: Microsoft.Dexterity.Applications.Dynamics.Forms.PmTransactionEntry.PmTransactionEntry. This window does have a SaveRecord event handler with a ComponentModel.CancelEventArgs parameter whereas my 3rd party Window does not. However, it did have a SaveRecord event handler under the Procedures object at the form level mentioned above, but without the ComponentModel.CancelEventArgs parameter. This is what I was trying but failing to use.
I ended up implementing this as I described in my second post. I register for both the "before" and "after" events for both the SaveButton and the ModalDialog handlers. The "before" events are used to validate that everything is as I need it to be before I allow the save operation to go through. By the time the "after" event is triggered, I know that the application MAY have already done its thing and saved some data. I say MAY because I've found that the event has been fired even when the Dexterity script had failed the request for some reason (e.g. mandatory field not filled in). As I didn't want to save my data in such a situation, I was forced to physically check the database to see if the Save operation had actually completed. This is certainly not as elegant as I'd like it to be.
Almas: I had somewhat arrived at the same conclusion about the SaveRecord as it isn't present consistently as you point out. That said, it is good to get the confirmation from a Dexterity developer. Thanks!
I am curious about your comment: "... as once we pressed the save button we can not make sanscript to stop...". Can you elaborate? This sounds to be what I am observing above.
Based on my limited experience so far, I had rather been assuming that the DAG tool used to generate the bridge DLLs auto-magically identifying the various... I'll go with the term "public Dexterity script artifacts" (until I know better) and insert pre and post events appropriate to the type of artefact (text control, window, form, etc). When the ComponentModel.CancelEventArgs is present in the generated event handler (not sure what decides this in the DAG), it seems to consistently work. Not so otherwise.
My simplistic view of the world is far from complete as I know very little about how Dexterity works. When I have time, I'd like to read through some of the Dexterity documentation to get my head around the basics. I'm convinced that some of the VBA and VST limitations will make sense then. If you can shed any light in that direction, that would be awesome.
The table triggers functionality you mention is interesting. This idea came up with a colleague when we thought we might need to delete our custom data entry after the fact... as you describe in your last paragraph. However, in our case we thought to add the trigger straight in SQL Server.
So your triggers are in Dexterity? And when you register for an Add or an Update, you still have the context of the relevant form or window? That functionality would certainly be nice. No, I haven't found anything of the kind in VST. Table objects relevant to the form are consistently located under the Tables object in the DAG generated form object (see above), but there don't appear to be any register-able events.
Anyway, good discussion all! Sorry for my long winded reply, but I figure I may need to refer back to my own findings at a later time. :)
Paul
