- Code: Select all Expand view RUN
:bOnPostEdit := { |o,x| ::oBrw:oTreeItem:Cargo[ _PAID ]:= x , ::ReCalculate() }
may please be replaced with the standard construct:
- Code: Select all Expand view RUN
:bOnPostEdit := { |o,x,k| If( k == VK_ESCAPE, nil, ( ::oBrw:oTreeItem:Cargo[ _PAID ]:= x , ::ReCalculate() ) ) }
which is safer.
With this change, the program works the same way as it was working in FWH 12.02 (the version I tested).
Standard safe practice is to assign the new value after considering the 3rd parameter nKey and the 2nd parameter xValue and then decide to assign the new value. Normal checks are that the nKey is not Escape key and 2nd parameter is not nil.
As we keep recommending and requesting from time to time, safer way would be to assign a SetGet block as bEditValue and let the XBrowse construct a safe bOnPostEdit codeblock. If there are some actions to be taken comsequent on a change in the value, as always we recommend using oCol:bOnChange codeblock. These recommendations apply to 2012 versions also as much as they apply to current versions. Our standard recommendation is not to code bOnPostEdit in the application program.
For example ( FWH12.08 till FWH15.03 )
- Code: Select all Expand view RUN
ADD TO ::oBrw DATA { |x| If( x == nil .or. ::Brw:oTreeItem:nLevel < 2, ::oBrw:oTreeItem:Cargo[ _PAID ], ;
::oBrw:oTreeItem:Cargo[ _PAID ] := x ) } ;
HEADER "AmtPaid"
<other statements>
::oBrw:AmtPaid:bOnChange := { || ::Recalculate() }
I find all my apps break when executing xbrowse's makeTotals() method after a cell is changed. This happens when MakeTotals is called on bchange or on bOnPostEdit.
We are surprised and also pained to learn that all your appls are breaking with makeTotals(). Please let us know any other cases and we are too eager to support you.
For your information MakeTotals() today is the same as it was in the beginning of 2012. There are only two improvements (including 15.04 to be released) but those two are only improvements and method is fully backward compatible.
I understand how new enhancements to the xbrowse class makes it unnecessary -at least on most cases- to execute MakeTotals after a cell is changed.
There is nothing new. This was there prior to 2012 too. And it remains the same even today.
Trust me, there are legitimate reasons to call MakeTotoals
We do agree. The automatic recalculation of totals is not adequate in all cases and there are always good reasons to call :MakeTotals() again and again consequent on some changes. And please trust us too when we say there is no change in MakeTotals() method that breaks earlier code.
We may like to make one or two suggestions to the sample code provided.
MakeTotals() is not very appropriate to this case. Method Recalculate() which calculates the group totals can also calculate grand totals and displayed with oCol:bFooter codeblock.
The main problem is MakeTotals() by default total all rows. In this case it totals both group totals and also the leaf values resulting in the footer totals being twice the actual totals. You may see that the footer total of the "Paid" column in the above sample is displayed as 4000 whereas the correct total is 2000. (Whether you use 2012 or 2015 versions)
At the same time XBrowse provides for conditional totals similar to SUMIF(....). In this case
oCol:bSumCondition := { |n,o| o:oBrw:oTreeItem:
nLevel == 1 }
totals only values for the Level 1 items. If you use this for columns 2,3,4, MakeTotals() gives the correct totals.
This feature was available in FWH12.02 too and continues to function the same way even today.
But the limitation is that the automaic retotal feature dose not work correctly We need to call MakeTotals() whenever there is a change.