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.
Board index FiveWin for Harbour/xHarbour RADIO "ON CHANGE" FIRES WHEN DIALOG UPDATED (WAS PAINTED)
Activate Dialog etc.. On Init SetRadioChange()
Procedure SetRadioChange()
oRadio:bChange := {|| MyFunctionWhenChange() }
Return
[;)]
Email: SamirSSabreu@gmail.com
xHarbour 1.2.3 + Fwhh 20.2
xHarbour 1.2.3 + Fwhh 20.2
Please try and review FWH\samples\TestRad.prg
That example uses the ON CHANGE clause and here it works fine
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:
The problem is here:
My fix is here:
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:
// 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:
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 nilMy fix is here:
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 nilWhat do you need this clause for ?
try to remove it. Unless I am missing something, I think that you don't need it
... ON INIT ( oDlg:Refresh(), oDlg:Update() )try to remove it. Unless I am missing something, I think that you don't need it
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:
Andy
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:
// 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
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
FWH 18.05/xHarbour 1.2.3/BCC7/Windows 10
Andy, James,
Got it 
Already implemented as proposed for next FWH 9.10 build
Thanks!