Cancelling a "Next" command on a Form

dorenthas

Hi!

I am trying to figure out how I can add a small, "simple" functionality ( :roll: nothing's ever as simple as it seems), and I'm really not sure I'm going the right way with my solution. (For all I know, there may even be a built-in feature in NAV 5 SP1 that can solve my problem instantly...)

Here's what I want to do: I want a confirmation dialog to pop up anytime a form is about to save changes to the underlying record. That dialog goes along the lines of "You have unsaved changes. Do you want to save them?", with the following options:
- Yes (Save the changes and perform whatever action that triggered the dialog)
- No (Drop the changes, but still perform whatever action that triggered the dialog)
- Cancel (Don't do anything - stop closing, navigating away, saving, etc. -, leaving the form intact with its unsaved changes)

The first two options are trivial to deal with in the OnModifyRecord trigger of the form. The tough part is the "Cancel" option. I thought of setting a boolean variable (sort of a "ActionCancelled" flag) which would be checked by the OnQueryCloseForm trigger to prevent the form from closing, and by the OnNextRecord trigger to prevent the form from stepping.

That's where all hell breaks loose. I know that putting any code in the OnNextRecord trigger replaces the default system behavior, so I have to add code to replace it in addition of my small check. I tried doing the following:

Form - OnNextRecord(Steps : Integer) : Integer
IF gbActionCancelled THEN
  EXIT(0)  // I also tried EXIT(Rec.NEXT(0)) here, with the same result. See below.
ELSE
  EXIT(Rec.NEXT(Steps));

It almost works. Except...

When Steps = 1 and the THEN branch is selected (the gbActionCancelled flag is set to True), the record behaves as if it had been issued INIT, or as if I'd hit F3 to insert a new record: the form is blank, the focus is on the first field (the primary key), and moving the focus from that field validates it and creates a new record. Definitely not what I had in mind! :shock:

What boggles my mind is that the same thing doesn't happen when Steps = -1. In that case, it works. I'm guessing that whatever is calling the OnNextRecord trigger when I click the Next button or press PageDown has a special mechanism/case for when Steps = 1 and the return value is 0 - it must figure that it reached the end of the record list and that the user is attempting to move "beyond", to generate a new record, and so it obeys diligently.

Is there a better solution to this than hacking the OnNextRecord trigger? If not, does anyone have some advice on what else I must do to get this - uh - solution to work as I expect it to?

Thanks a lot for any input, it'll be greatly appreciated. (Oh, and I looked all over the forum for info before finally deciding to register and post - great community, by the way =D> )

- MB

kine

1) Do not do this, this is not how NAV is working and you can have bad side effects...
2) E.g. when OnValidate is modifying some other tables or records, canceling the OnModify can lead to inconsistency.

ajhvdb

First reread the above message but for understanding "how it works" and where to "step in", look at form 408.

Let us now how you solved it. If it's possible ...

dorenthas

Thanks for the quick responses.

I fully realize I'm attempting to solve this the bad way - not the Navision way. I got a better idea, but before trying it I'll go take a look at form 408, as you suggested. Stay tuned!

dorenthas

kine wrote:

2) E.g. when OnValidate is modifying some other tables or records, canceling the OnModify can lead to inconsistency.

Well, the form that would use this is not transactional by nature - it's form 5200. We're also going to prevent renaming records in table 5200, so that probably takes care of the most critical potential OnValidate-caused inconsistency.

But just to get this straight, you're advocating against returning FALSE in the Form - OnModifyRecord trigger at all? In that case, would it be better to use the advice from http://www.mibuso.com/forum/viewtopic.php?f=14&t=7730&start=0&st=0&sk=t&sd=a instead so that the Table - OnModify trigger still gets to run, but simply overwrites changed fields with the same values? Either way, these would take care of the "No" option to the "Do you want to save your changes?" dialog...

dorenthas

For the "Cancel" option (where I basically want to stop processing of the user action), maybe I could simply throw an ERROR with a message like "Action cancelled", which would effectively stop it. Not the sexiest way to deal with the problem, as the user would need to perform an extra click when cancelling... but maybe this wouldn't be the end of the world.

--> EDIT: Wrong. Just throwing an ERROR resets the values of Rec, so it completely defeats the purpose of the "Cancel" functionality...

Still, I'd like to discuss the other idea I had to handle the "Cancel" option (so I can learn why it is be a bad idea :oops: )

When the "Cancel" button is used, the content of Rec is stored in a temporary record variable and the changes in Rec are rolled back (using either method described above). OnNextRecord and OnFindRecord are not modified; instead, the OnAfterGetRecord checks if the ActionCancelled flag is up, and if so, it uses Rec.FIND and the key from the temporary record variable to return to that record, then copy the temp record values back into Rec.

Simply put:
1) Backup modifications into a temp record
2) Discard changes in Rec
3) Let system perform move/find action
4) Undo move/find action
5) Restore modifications from the temp record

kine

You can think about using temp table as source of theform and saving the data through C/AL code only when you want...

dorenthas

Yeah, that's pretty much what I was starting to think too. Unfortunately, time is too short so we've simply opted not to implement this feature for now.

Thanks again for the advice!