As not totally unexpected, I'm tracking the SAVEWARN property to determine why spurious savewarn messages are appearing when ported to OI10. For instance, flicking through a browse list without making changes or changing focus may or may not produce a savewarn message.

I'm trying to understand what/where the various hooks mean (eg CHECKTOCLEAR, SETRESULTROW, DATA_VALIDATION, ..)

How are these hooks determining what value to set SAVEWARN? What are they comparing? - CHANGED/MODIFIED properties, GOTFOCUS_VALUE, or even SubRows@ ?

I believe DATA_VALIDATION is within the system handler for LOSTFOCUS on a control. It seems this is being setting SAVEWARN to TRUE regardless, in this case. No doubt this will be due to application event code that is affecting internal variables.

Does setting DEFPROP set SAVEWARN to TRUE regardless, or does it set SAVEWARN according to some comparison?

Cheers, M@

Vernon Systems

As not totally unexpected, I'm tracking the SAVEWARN property to determine why spurious savewarn messages are appearing when ported to OI10. For instance, flicking through a browse list without making changes or changing focus may or may not produce a savewarn message.

I'm trying to understand what/where the various hooks mean (eg CHECKTOCLEAR, SETRESULTROW, DATA_VALIDATION, ..)

How are these hooks determining what value to set SAVEWARN? What are they comparing? - CHANGED/MODIFIED properties, GOTFOCUS_VALUE, or even SubRows@ ?

I believe DATA_VALIDATION is within the system handler for LOSTFOCUS on a control. It seems this is being setting SAVEWARN to TRUE regardless, in this case. No doubt this will be due to application event code that is affecting internal variables.

Does setting DEFPROP set SAVEWARN to TRUE regardless, or does it set SAVEWARN according to some comparison?

Cheers, M@

Vernon Systems

There is an issue (Fixed in 10.2.2) where setting DEFPROP value in a NON databound field will set the savewarn

Hi M@,

DATA_VALIDATION is indeed the core part of the promoted LOSTFOCUS handler. SAVEWARN is set to TRUE$ if:

1) The current DEFPROP value is not equal to the GOTFOCUSVALUE, and

2) The control in question is databound,

3) The control in question is not a key prompt.

CHECKTOCLEAR and CLOSE: Sets SAVEWARN to TRUE$ if the DEFPROP and GOTFOCUSVALUE properties of the currently focused control are different - i.e. they are simulating part of the LOSTFOCUS event - you didn't move the focus but did the data change?

Everything else is not compared as such - e.g you click a checkbox - SAVEWARN is set, you insert a row, SAVEWARN is set and so on.

The MODIFIED property and the CHANGED event are not used. Neither is SubRows@ (While I personally prefer the Arev-style method of basically comparing @record to ORec to see if anything has changed, the original OI authors went down the route of setting a flag as the user changes individual prompts, so that's what we have to work with :) )

»Does setting DEFPROP set SAVEWARN to TRUE regardless, or does it set SAVEWARN according to some comparison?

Setting DEFPROP always sets SAVEWARN to TRUE$, unless it's a non-DB control (as of v10.2.2). This is what "[DEFPROP]" in the SAVEWARN tracking indicates. There is no comparison performed.

Cheers

Carl Pates

Ah - thanks both. Good info :)

Sets SAVEWARN to TRUE$ if the DEFPROP and GOTFOCUSVALUE properties of the currently focused control are different - i.e. they are simulating part of the LOSTFOCUS event - you didn't move the focus but did the data change?

In OI9, GOTFOCUS_VALUE for edittables is the transpose of DEFPROP - ie, it is in LIST format rather than ARRAY format. There are places where we needed to cater for this.

In OI10, GOTFOCUSVALUE (== GOTFOCUS_VALUE) is consistent with DEFPROP. So I'll need to refactor that cater code.

Setting DEFPROP always sets SAVEWARN to TRUE$, unless it's a non-DB control (as of v10.2.2). This is what "[DEFPROP]" in the SAVEWARN tracking indicates.

Ah, yes! I hadn't yet tried to change data, so hadn't yet come across "[DEFPROP]". More to explore..

Cheers, M@

Vernon Systems

There is an issue (Fixed in 10.2.2) where setting DEFPROP value in a NON databound field will set the savewarn

Well, I've just tried today's 10.2.2 beta beta, and SAVEWARN is mostly behaving now! :)

Cheers, M@

Vernon Systems

I have a case where the QBFLIST needs to be nulled, without prompting to save any changes to the record. However the following code isn't sufficient to do this silently

Call Set_Property_Only( @window, 'SAVEWARN', FALSE$)

Call Exec_Method( @window, 'QBFSETLIST', '', '', TRUE$) ;// clear QBFLIST and suppress events

The QBFSETLIST method calls OIWIN_QBFCLOSE directly (ie, not sending a QBFCLOSE event), which calls OIWIN_CHECKTOCLEAR - which does its own savewarn check regardless:

CHECKTOCLEAR and CLOSE: Sets SAVEWARN to TRUE$ if the DEFPROP and GOTFOCUSVALUE properties of the currently focused control are different - i.e. they are simulating part of the LOSTFOCUS event - you didn't move the focus but did the data change?

The SUPPRESSSAVEWARN property appears to be effective in the CLEAR and CLOSE event handlers, but not directly within OIWIN_CHECKTOCLEAR.

Is there a way to suppress CHECKTOCLEAR within QBFCLOSE?

Cheers, M@

Vernon Systems

Hi M@,

Fixed for v10.2.3

Cheers

Carl Pates

Fixed for v10.2.3

Great stuff - thanks Carl :)

I take it this means I'll be able to set SUPPRESSSAVEWARN around the QBFSETLIST method?

Cheers, M@

Vernon Systems

View this thread on the Works forum...