How to cater for a Write that bypasses the Changed event.

Opto_Will

I will try to keep the description brief to not overcomplicate my question.

Basically, we have an ongoing issue where users enter information in an OI Edit Table and then trigger the Write Event (via F9 Save) without tabbing out of the current cell. The CHANGED event doesn't fire and data gets saved in an inconsistent state as that CHANGED event go off and does a number of important things for certain fields.

A workaround that was implemented was to trigger the CHANGED event Pre-Write. This is obviously not right but its effects were hidden because most users that Save without tabbing are doing so at the tail end of that Table (having finished entering the record) and not much happens in the CHANGED event there.

We have a couple of clients that have now complained about 'corrupt data' that is basically because they have triggered the Save from the start of the Table, without changing anything in the table, and this has triggered the CHANGED event for that Column and it has replaced lots of values with defaults for the row they were on.

Now I can easily fix this issue by removing the call to the CHANGED event in teh Pre-Write, but I still need to plug the original hole.
I need to find a way to make sure the user can’t Write if they haven’t moved off the field if they changed anything.

I have been playing around with LOSTFOCUS, POSCHANGED, NEXT, FOCUS, SELPOS etc but can’t seem to get the behaviour that I want.

So, my question is this:
What is the best way to ensure that we capture if the user saves the form without tabbing out of the current field where there has been an actual change, while ignoring capturing the same field without changes?

How do others handle this scenario?

DonBakke

Your solution to send the CHANGED event via the pre-WRITE event handler isn't a bad one. Why does the CHANGED event replace lots of values when the user is at the start of the EditTable (assuming they didn't enter anything)? Can you just not check for specific conditions and either avoid triggering the CHANGED event or avoid executing the logic within the CHANGED event handler?

AusMarkB

How much work would it be to replace the OI table with an SRP one? The additional events are usually what motivate me to put in the effort.
Sometimes, it's a complete replace and other times it's a combination of hiding the original OI table and providing the SRP one for the user interface.
The OI one exists for the read/write but the SRP one exists to make sure I don't get trapped with the limited OI events.

Granted, sometimes it's too much work for the overall benefit but I do go down that road whenever I can

Opto_Will

@DonBakke

I guess because I haven't been able to identify the ONLY time I need to fire it so it is firing all the time (which is bad)
The only time I want it to fire is if the field I am currently in has changed from before I entereed it time and I haven't left the field before saving.

Is there an OI property that says "You have done something while you were in this focussed field"? Basically what is the property that internally fires the CHANGED Event naturally? I know that OI is smart enough to not fire the CHANGED if nothing has been done so it is basing that logic on something. I just dont know what that is. Or if I can iterrogate it myself or if it is only available to internal routines.

@AusMarkB
We have done this a few time in places. In fact, in some of our 'heavy' screens with 'too many controls' we have dropped a single SRP TABLE control (to replace 8 or 9 OI Tables) displayable on all pages that will get dynamically created based on what Tab (Page) is selected. Generated info gets saved in a Form-level UDV so it doesn't have to generate data again as you go back and forth between tabs. Definately more powerful than a standard I OI Table so I understand your suggestion.

Unfotunately, while this specific case affects 2 forms, users do this all the time throughout the system so I wanted a solution I could easily roll out out to other forms where users get a little lazy (lets be honest, we all do it) and dont exit fields.

DonBakke

@Opto_Will - You might be able to use the MODIFIED property. Otherwise, you could always set your own UDP with the value of the ARRAY property whenever the user poschanges or loses focus and then compare this with the current ARRAY property in your Pre-WRITE event handler.

BarryStevens

@AusMarkB

Disable the F9 key whilst in the edittable and provide a 'Save' button at the bottom right of the edittable.
(provide an appropriate red text info message at the top of the edittable)

BarryStevens

@AusMarkB

Disable F9 'Rollout'

" if CtrlClassId = 'EDITTABLE' then"

1.
Do it in PBC_LOGIN->Write with a message re exit.
send_event(WRITE not executed

2.

Do it in promoted events on GOTFOCUS & LOSTFOCUS