Disabling (grey out) %dd spin wheel on %rd

I have noticed that when I grey out an %rd box which is equipped with a %dd 'spin wheel', the latter remains enabled, and can be used to increase/decrease the contents of the greyed-out box.

Since the format is %dd%~rd there is a question as to whether I can use %lc to get the handle of the spin wheel, and then EnableWindow (which paradoxically also disables windows and controls!) to do the job.

I have tried this out, and sadly it doesn't work: I tried both %dd%lc%~rd and %dd%~rd%lc

• the latter in the hope that as the spin wheel comes to the right of the input box it was 'after' it.

Does anyone know the answer?

My current workaround is to hold the value constant in the callback to the %rd box - as mentioned in other posts the limits on %il can't be the same.

Eddie

Consider the following code WINAPP integer i,winio@,ctrl,n ctrl=0 n=50 i=winio@('%il%dd%~rd',0,100,1,n,ctrl) end

The result is an edit box that cannot be changed directly but can be changed via the spin wheel.

Although this may not always be desirable, it has been a 'feature' for so long that it may be unwise for us to change it.

There may be a simple solution that you can recommend. If so then I will aim to implement it.

In the mean time, if you use %lc to get the handle of the edit box, then the spin wheel is the next control in the Z-order of the handles but this is not available via a %lc. Try using the Microsoft API GetWindow(hwndEdit, GW_HWNDNEXT) to return the handle of the spin wheel where hwndEdit is the handle of the edit box obtained from %lc.

We have looked at this again and propose to treat this as a bug so that the gray control on the edit will in future releases also disable/enable the spin wheel.

Please let me know if this change would be unwelcome.

Paul,

Linking the spin wheel 'grey state' to that of the %rd box (or indeed %rs) seems to me to be logical, and I find it difficult to imagine a situation where one would grey-out the %rd (so that its contents could not be altered) while allowing the spin wheel to be active (so that the contents of the %rd box *could *be altered), so as far as I am concerned, this is progress, although I suspect that the views of others need to be solicited.

Is perhaps the 'middle ground' to have an optional linkage with something like: %dd[link_grey] ... ? I'm not sufficiently knowledgeable to be able to identify any other controls that could usefully be linked in this way.

I had a go with your suggestion about finding the handle of the %dd, viz:

     WINAPP 
      integer i,winio@,ctrl,n,SET_GREY,iHWDC,jHWDC
      common ctrl,iHWDC,jHWDC
      external SET_GREY
      include <windows.ins> 
      ctrl=0 
      n=50 
      i=winio@('%il%dd%~rd%lc&',0,100,1,n,ctrl,iHWDC)
      jHWDC=GetWindow (iHWDC, GW_HWNDNEXT) 
      i=winio@('%ff%nl%cn%^bt[Toggle] %bt[Quit]',SET_GREY)
      end
      integer function SET_GREY()
      logical grey, done
      integer ctrl,iHWDC,jHWDC
      common ctrl,iHWDC,jHWDC
      include <windows.ins> 
      jHWDC=GetWindow (iHWDC, GW_HWNDNEXT) 
      CTRL = IABS(CTRL-1)
      grey = CTRL .EQ. 1
      done = EnableWindow (jHWDC,grey)
C      write(*,*) ctrl,grey,done
      SET_GREY=1
      END

... and this caught the button 'Toggle' as the next control. I also tried GW_HWNDPREV to no effect.

My workaround was to have a variable containing a copy of the value, and in the callback (i.e. using %^rd) to check the grey state, and if greyed-out, restore the original value.

Regards

Eddie