RADIO "ON CHANGE" FIRES WHEN DIALOG UPDATED (WAS PAINTED)

[arpipeline]

I am having a problem with the ON CHANGE clause of the Radio class(es). It seems the ON CHANGE event is firing when the dialog or window containing the Radio button is updated, even when the value is unchanged. Is this by design or a bug?

Thanks.

[sambomb]

Activate Dialog etc.. On Init SetRadioChange()

Procedure SetRadioChange()
oRadio:bChange := {|| MyFunctionWhenChange() }

Return


[;)]

[Antonio Linares]

Please try and review FWH\samples\TestRad.prg

That example uses the ON CHANGE clause and here it works fine

[arpipeline]

Antionio,

Here is a modified testrad.prg to demonstrate the problem. It's a silly example, but it demonstrates how many times the bChange block is exectued. See below for the problem id and fix:

Code: Select all | Expand

// Radio Buttons management sample

#include "FiveWin.ch"

//----------------------------------------------------------------------------//

function Main()

   local oDlg, oRadMenu
   local nOption := 2

   SET _3DLOOK ON

   DEFINE DIALOG oDlg RESOURCE "Radios"

   REDEFINE RADIO oRadMenu VAR nOption ID 110, 120, 130, 140, 150 OF oDlg ;
      ON CHANGE MsgInfo( "Hello" ) ;
      UPDATE

   REDEFINE BUTTON ID 100 OF oDlg ACTION oRadMenu:GoNext() ;
      WHEN nOption == 3

   REDEFINE BUTTON ID 102 OF oDlg ACTION oRadMenu:GoPrev()

   ACTIVATE DIALOG oDlg CENTERED ;
     ON INIT ( oDlg:Refresh(), oDlg:Update() )

   SET _3DLOOK OFF

return nil

//----------------------------------------------------------------------------//
 

The problem is here:

Code: Select all | Expand

METHOD nOption( nNewOption ) CLASS TRadMenu

   if nNewOption != nil
      Eval( ::bSetGet, nNewOption )
      if ::bChange != nil                         
         Eval( ::bChange, Self )        /* <--- This runs every time the container is updated or painted */
      endif
   else
      return Eval( ::bSetGet )
   endif

return nil
 

My fix is here:

Code: Select all | Expand

METHOD nOption( nNewOption ) CLASS TRadMenu

   if nNewOption != nil
      IF Eval( ::bSetGet ) != nNewOption                  /* <----- Added this to check if we even need an update, value may already be set!! */
        Eval( ::bSetGet, nNewOption )
        if ::bChange != nil
           Eval( ::bChange )                   
        endif
      ENDIF
   else
      return Eval( ::bSetGet )
   endif

return nil

 

[Antonio Linares]

What do you need this clause for ?

Code: Select all | Expand

...  ON INIT ( oDlg:Refresh(), oDlg:Update() )

try to remove it. Unless I am missing something, I think that you don't need it

[arpipeline]

Antonio,

As I said, it's a silly example, but it causes the event to fire repeatedly. In the real world, I have calculations tied to the ON CHANGE clause. The problem is, they run even if the value is already set and unchanged. The fix in my original post solves the problem.

My ultimate question, regardless of the silly example, is...why does the bChange block execute *at all* during dialog updates or refreshes *if* the value is unchanged. BTW, I was mistaken, the initial dialog painting does not cause the bChange eval.

Here is a more realistic example - click either the "Prev" or "Next" button to see the behavior:

Code: Select all | Expand

// Radio Buttons management sample

#include "FiveWin.ch"

//----------------------------------------------------------------------------//

function Main()

   local oDlg, oRadMenu
   local nOption := 2

   SET _3DLOOK ON

   DEFINE DIALOG oDlg RESOURCE "Radios"

   REDEFINE RADIO oRadMenu VAR nOption ID 110, 120, 130, 140, 150 OF oDlg ;
      ON CHANGE MsgInfo( "Hello" ) ;
      UPDATE

   REDEFINE BUTTON ID 100 OF oDlg ;
      ACTION oDlg:Update()

   REDEFINE BUTTON ID 102 OF oDlg ;
      ACTION oDlg:Update()

   ACTIVATE DIALOG oDlg CENTERED

   SET _3DLOOK OFF

return nil

//----------------------------------------------------------------------------//
 

Andy

[James Bott]

Andy,

>why does the bChange block execute *at all* during dialog updates or refreshes *if* the value is unchanged.

This does seem like a valid point and it also seems you have found a good solution.

Antonio,

Do you see any problems with his proposed change?

James

[Antonio Linares]

Andy, James,

Got it

Already implemented as proposed for next FWH 9.10 build

Thanks!