CALLBACK_REASON response ? in %gr callback

Paul, I expect that dll is work in progress but in case this is news, I'm finding the return value from winio for a window containing buttons is not returning the index of the clicked button, just 0.

This that just with the latest download? Can you provide a demo?

This is happening in both the 279 beta and the last download. It's okay with the 8.30 release. Expected 1 for Yes, 2 for No but all winoio ever returns is 0:

winapp
  use mswin

  integer:: res
  res = winio@('%ca[Confirmation]Yes = 1, No = 2: %bt[Yes] %bt[No]')
  print *, res  ! expect 1 for Yes, 2 for No
end

From my experience, the use of %bt without providing a call back, %bt will always return a zero.

Interesting - I've never had any problem before whether using a callback or not. It is certainly supposed to work otherwise there'd be no way of telling which button caused the window to close without using a cb.

Interesting... I didn't knew this, but I found information in the file cwplus.enh, topic No. 357, which says:

'A new format code %id has been added in order to specify the button number (ID) of the next %bt, %tt or %bb button. The button number provides the winio@ return value when a button is clicked and the button is not given a callback function. So %id values can be used in conjuction with the winio@ return value when button callback functions are not needed. By default, button numbers are provided automatically in the order that the buttons are defined.'

Alternative coding:

res = winio@('%ca[Confirmation]Yes = 1, No = 2: %id%bt[Yes]%id%bt[No]',1,2)

Wilfried

I did not know about the %id, so this is good. For simple selections, I can see that this would be helpful.

Personally, I use a specific value, and have a set of generic callback functions (1 through 10, for my case).

I have discovered a regression that is the probable cause of the '?' failures. I have also fixed a recent regression regarding the return of the button index.

Here is a new download to test...

https://www.dropbox.com/s/g3ir4nx0wjxqba1/acw.zip?dl=0

Wilfried,

I think it is a sort of madness to set the return code for the buttons.

By default, they are numbered in the order in which the buttons are specified, with 0 reserved for the close box. Once you start explicitly numbering them you have a potential to confuse which is which.

On the other hand ... while developing a window, you can be adding or removing buttons, and the return code from a particular button may change, and specifying the return code may be sensible (although if I plunged headlong into the madness I would be using high numbers like 50, 100, 150 etc not 1, 2, 3 etc.).

If the button exits from a window immediately, you process the action after the window has closed, whereas if you put the action code in a callback, it executes before the window closes. Sometimes the latter is preferable, but not always.

Clearwin+ gives you multiple options.

ACW - your code works for me and returns sensible numbers.

Eddie

That's great Paul thanks. No more ?s and dialogs are working. It also feels more responsive on redraw. 😄

Eddie,

I'd agree you don't really want to be manually setting the ID for every button. I tend to only use the return code for basic Ok/Cancel/Yes/No buttons, with any other buttons on the window being handled by a callback. So assigning a few specific IDs for those buttons would allow you to add and remove buttons elsewhere (and use constants rather than magic numbers) without having to recode your end of dialog handling every time something changes. As you say, using some bigger numbers is the sensible way to go.

The return value problem was only with the recent beta dlls Paul has been generating, but everything in the garden looks rosy with his latest.

Alan