Multiple call back ('+') issue

I have a control that, depending on value, is supposed to change the color of the control. However, when I used the '+' to get two call backs (one for color, one for an alternate action), the color would not change. The following code segment illustrates this.

In the second %rd control (two callbacks), when the callback function abcd() is executed, the clearwin_info@('CURRENT_CONTROL') now returns a control handle of zero. It matters not which of abcd() or efgh() is first. Both have the same result.

	winapp
    program main
    use mswin
    integer,external:: abcd,efgh
    integer:: i_xx=0,i_yy=10,i_zz=20
    integer:: i,j,k
    i = winio@('%wd loc(i_xx)  %wd loc(i_yy)%ff%nl&',loc(i_xx),loc(i_yy))
    i = winio@('Changes Color %^rd%ff%nl&',i_xx,abcd)
    i = winio@('No color changing %^rd',i_yy,'+',abcd,efgh)
    end
    integer function abcd()
    use mswin
    integer:: user_data,control_handle
    logical:: color_change=.false.
    abcd = 1
	USER_DATA = CLEARWIN_INFO@('LATEST_VARIABLE')
	CONTROL_HANDLE = CLEARWIN_INFO@('CURRENT_CONTROL')
    print *,'In abcd(), variable at ',user_data,' control handle ',control_handle
	if(color_change) then
			CALL SET_control_BACK_COLOUR@(CONTROL_HANDLE,RGB@(255,255,255)) ! white (normal)
	else
			CALL SET_control_BACK_COLOUR@(CONTROL_HANDLE,RGB@(255,255,0)) ! Yellow
    endif
	color_change = .not.color_change
    return
    end
    integer function efgh()
    efgh = 1
    return
    end

The simplest way to resolve this kind of issue is to insert print statements into the callbacks in order to determine if and when they are called and in which order.

Paul, as I said, it makes no difference the order of the 2 callbacks. clearwin_info@('CURRENT_CONTROL') returns a handle of zero.

Bill

How important is this? I am guessing that it won't be easy to fix.

Paul,

I hear you.

I have a 'workaround', so while it would be a 'great to have', I can deal with it other ways. Having the %ud available to both callbacks helps!

I would suggest that if it is in the 'too hard to do' or 'it breaks ...' category, just having it documented would be helpful. And, perhaps it can go on the 'to-do' list then.

Bill

I will take a look when I get a minute but I am not hopeful.

This has now been fixed for the next release of the DLLs.