Edit Record - recommendations

[kenneth2k8]

Hi all:

For most of my FM experience, I've been using fp5 technology. I recently got FM 11 advanced and I am struggling to catch up with some of the enhacements since my previous version, FM6.

I wanted to take advantage of the "new" feature of a layout where you can uncheck the "save record changes automatically." What I found is that I can tab to the fields all I want, but as soon as I click in an empty space or try to change the record, it will prompt me to save changes. I read the help file and this is indeed how this is supposed to work.

In my solution, I have an edit button on the main layout. When clicked it will go to another layout with the fields unlocked. I have a cancel and a save button. If they click cancel it's supposed to revert the record and go back to the original layout. But if the user clicks on an empty space or goes to the next record via the scroll wheel on the mouse then it will prompt. That kina defeats the purpose of my cancel button and now they still have to click my cancel button after clicking "don't save" to FM's dialog.

In the past I have used globals in my edit layout and then set them to the record fields when save has been clicked, or clear them and go back when I hit cancel. I am ok with this but I don't want them inadvertently updating another record if they were to use the scroll wheel (since on the edit layout they are seeing globals set from the record selected when they clicked edit). So my solution to that was to have the script omit record and then show omitted. But what if they cancel changes? I need to restore the last find request and go back to that record, because the user could have a found set from a custom find.

I haven't had any success with that last part. Ideally I would like to capture the current found set somehow when they click edit, then if they were to cancel then I can go back to the previous found set and record.

So I guess here are my questions:

1. Is there a better method in FM11 for committing record changes?

2. If not and I am going to set globals in the method above, what actions can I use to go back to the previous found set before I went omit record/show omitted so that it isolates the current record I am editing?

3. Is there a way to disable the scroll wheel on the mouse? If I could do that I don't think I would need to mess with finding the previous found set.

Thanks for any help on this!

[comment]

as soon as I click in an empty space or try to change the record, it will prompt me to save changes.

This (clicking) can indeed be indeed annoying, but can be solved by using an empty web viewer object as background.

As for scrolling, see if this helps:

http://fmforums.com/forum/showtopic.php?tid/194904/

[kenneth2k8]

Thanks for the info! I think since I have designed it to use the globals, I will stick with that. Your suggestion of locking the status area is perfect. It's not used anyways and I am going to lock it from the get-go so they don't mess with it.

That brings me to another question. One I've had since back using FM5:

How do globals behave in terms of a server-client environment? For example:

User1 updates the value in a global field. User2 also views that global field after the change is made. Will user2 see the change made by user1? I ask because I have some globals being set and records being set to those global values in a loop. If someone was to change those global values I am concerned that it can mark the records incorrectly.

Will this happen? I haven't been able to test the solution in a multi-user environment so any input on that would be great. Thanks again for your help with the scroll wheel!

[comment]

since I have designed it to use the globals, I will stick with that

I'd be very careful with that. At minimum, you need to lock the record before "going to globals" to prevent other users editing it at the same time. See here for more:

http://fmforums.com/forum/showpost.php?post/227590/

Will user2 see the change made by user1?

No. Global values are user-specific. More accurately, they are session-specific, i.e. they will lose all modifications when the user logs out.