Some suggestions for future enhancements to Clearwin+

The get_mouse_info@ and the clearwin_info@ equivalent methods only provides the shift and control information if a mouse button is pressed prior to and held during the mouse wheel action. The states can be obtained at any time, see code below. I have shown it called from within one of my mouse wheel callback routines to show the information is available, but I only print the info.

      Integer*4 function OnMouseWheel()
      implicit real*8 (a-h,o-z)
      include <windows.ins>
      include 'params.inc'
      include 'drawtool.inc'
      include 'f77pcs.for'
      integer*4 wheel_rot,wparam,zoom_back,zoom_in
c     and get the wheel scroll values from WPARAM in OnMouseWheel: 
      OnMouseWheel = 2
      if(mod(idraw_mode,2) .eq.0)then   !Normal P&ID window

        wparam = clearwin_info@('MESSAGE_WPARAM') 
        wheel_rot = HIWORD@(wparam) / 120 ! rotations reported as *120 
        call set_zoom_factor(sqrt(sqrt(2d0)))
        if(wheel_rot .eq. 1)then
          i = zoom_in()
        elseif(wheel_rot .eq. -1)then
          i = zoom_back()
        endif
        call set_zoom_factor(sqrt(2d0))
        i = i
      endif
      print *,modkeystates()
      end

      integer*4 function modkeystates()
! get states of shift, control and alt modifier keys - not left right dependent
      include <windows.ins>
      integer*4 test_bit@
      integer*1 key_shift,key_control,key_alt
      key_shift   = GetKeyState(VK_SHIFT)
      key_control = GetKeyState(VK_CONTROL)
      key_alt     = GetKeyState(VK_MENU)
      modkeystates = test_bit@(key_shift,7)     +
     &               test_bit@(key_control,7)*2 +
     &               test_bit@(key_alt,7)    *4
      end

      integer*4 function modkeystates1()
! get states of shift, control and alt modifier keys - left & right dependent
! bits 0 to 2 are identical to non-handed version
! bits 3 to 5 are left hand sensitive
! bits 6 to 8 are right hand sensitive
      include <windows.ins>
      integer*4 test_bit@
      integer*1 key_lshift,key_lcontrol,key_lalt
      integer*1 key_rshift,key_rcontrol,key_ralt
      key_lshift   = GetKeyState(VK_LSHIFT)
      key_lcontrol = GetKeyState(VK_LCONTROL)
      key_lalt     = GetKeyState(VK_LMENU)
      key_rshift   = GetKeyState(VK_RSHIFT)
      key_rcontrol = GetKeyState(VK_RCONTROL)
      key_ralt     = GetKeyState(VK_RMENU)
      modkeystates1 = modkeystates() +
     &                test_bit@(key_lshift,7)  *  8 +
     &                test_bit@(key_lcontrol,7)* 16 +
     &                test_bit@(key_lalt,7)    * 32 +
     &                test_bit@(key_rshift,7)  * 64 +
     &                test_bit@(key_rcontrol,7)*128 +
     &                test_bit@(key_ralt,7)    *256
      end

This is my code for setting the zoom factor:

C ====================================================================== CCCC
c     define zoom steps

      MODULE ZOOM_STEPS 

      integer*4,dimension(20)::ztab=(/10,13,18,25,35,50,71,100,141,200,
     *              283,400,566,800,1131,1600,2263,3200,4525,6400/)
      end

C ====================================================================== CCCC

      INTEGER FUNCTION MAUS_ZOOM()

c     zoom with mouse wheel

      USE ZOOM_STEPS

      IMPLICIT NONE
      INCLUDE <WINDOWS.INS>

      integer*4     i,j,WPARAM

      WPARAM = CLEARWIN_INFO@('MESSAGE_WPARAM')
      i = HIWORD@(WPARAM)

      do j = 1,20
        if (zoom == ztab(j)) exit
      end do
      if (i > 0) then
        if (j < 20) zoom = ztab(j+1)
      else
        if (j > 1) zoom = ztab(j-1)
      end if
c
c     refresh the graphics
c
      maus_zoom = 3
      end

There is no influence by any keys pressed or not, including Shift, Ctrl and combinations of keys, also no influence by any mouse button pressed or released.

Wilfried

Various conversations...

John

Not sure about your comment. I tested without pressing a mouse button. Only mouse wheel movement and hold key down. Granted you would normally hold the key down a little before moving the mouse wheel.

Eddie

I have now fixed the %sy[3d] and %ob[rounded] combination. However, it doesn't look good to me because the various shades of grey do not work well together (the background colour matches one of the scoring colours so two of the corners don't look right).

Ian,

Most useful. I presume that the three includes aren't really required, and the + in the penultimate line isn't either.

Eddie

Eddie, Absolutely correct, the includes in the first routine were specific to my code and can be omitted for other users, but was just there as a demo.

And yes, the '+' was just me getting carried away now edited from the post. Thanks Ian

Paul,

Regarding the rounded corners, when I did the mock-up on page 1 of this topic, I copied the colours from a screen grab. With 3d_thin, the background was 3240, the line was 3160, and there was a white highlight.

I see what you have done, using 3*240 to soften the curve (looking at the top left and bottom right corners as generated by your last beta). Is it really necessary to be that sophisticated? I had a little go with another mock up for top right and bottom left just using the dark grey and white and it looks OK - your curved corners are a little bigger radius than my original attempt, and I tried to match yours.

Incidentally, your rounded corners are as complex as the corners on a dialog box, mine were less complex than that, but more than a button (in Win 7). From left to right: Yours, mine, and a button corner

XXXXX                     XXXXX                     XXXXX
     XX                        XX                        X
       X                         X                        X
        X                        X                        X
        X                         X                       X
         X                        X                       X
         X                        X
         X

I guessed that it wouldn't be easy, but arranging the shading is easier the simpler the curve is.

Eddie

Eddie

Many thanks for your input and help on this topic. I am reasonably satisfied with the outcome so (apart from any remaining simple bug fixes) I am happy to leave things as they are.

Paul

Hi Paul,

My attempt to show corners with pixels as 'X marks the spot' in a CODE section looks fine on a PC, but rubbish on my Blackberry - I hope that you got the drift, and of course, there is always a point where future tinkering brings no further benefit.

My opening gambit to this thread was a whole list of ideas, and you did suggest highlighting one at a time. I don't even know what my own priorities are, so attempting not to be selfish, my guess that the next one that is worth looking at, and perhaps won't prove so difficult, is one that didn't even make it to my original list, and that is to revisit %ib and improve the conversion to greyscale of the 'greyed-out' icon variant.

To recap, an %ib button bitmap can be anything in terms of size and colours. If it has a complete border round all 4 sides of colour RGB@(R,G,B) then that is taken as background, otherwise a mid-grey RGB@(192,192,192) is taken as background. When converting to a greyed-out or inactive toolbar button, any colour pixel that isn't background is converted to dark grey. This does tend to make greyed-out buttons look like rather shapeless blobs. We did have a thread on this some years back, and it is possible to restore some semblance of the original icon (in the greyed-out state) by judicious use of background colour pixels within the design, and the optical illusion of a 3rd grey shade is achievable with a chess-board pattern of background colour and something else.

When you recently reworked the %bb button, you introduced a rather better algorithm for defining the greyed-out appearance, and (excepting some of my icons that had shadows!) they appear much, much, better than the %ib greyed-out blobs. Just a guess, but was the grey blob the best that could be done on a display without much colour depth?

Given that you already developed that better algorithm, and 24-bit colour is more or less universal, is it perhaps sensible to at least consider applying it to the %ib greyed-out state?

Eddie

Eddie

My immediate priority is to add a new feature to Plato. So can we come back to this ClearWin+ development in a little while (maybe a month or so).

I wrote most of the %ib code and in particular the multiple images part so I am a little apprehensive about the scope for improvement because I know how much work went into the original.

Having said this, there may be a simple solution (or alternative) along the lines you suggest or maybe just to allow the programmer to provide their own greyed image.

Hi Paul,

Getting a balance in the way the different parts of the FTN95/ Plato/ Clearwin+ system move forwards is probably the optimum solution. I am content to wait for however long it takes - just that my list usually gets longer with time (although it gets shorter too when someone posts a solution in the forum!).

Eddie

Quoted from LitusSaxonicum my guess that the next one that is worth looking at, and perhaps won't prove so difficult, is one that didn't even make it to my original list, and that is to revisit %ib and improve the conversion to greyscale of the 'greyed-out' icon variant.

Basic RGB-color conversion to greyscale is quite simple, below is a slow example in MINIBasic syntax:

func greyscaleBitmap(CBitmap bmp)
	int i,j
	POINT size

	size = bmp.GetSize()

	bmp.BeginDrawing()
	for i = 0 to size.y - 1
		for j = 0 to size.x - 1
			uint c = bmp.GetPixel(j,i)
			char r = c&0x0000ff
			char g = (c&0x00ff00)>>8
			char b = (c&0xff0000)>>16
			char gray = (30 * r + 11 * g + 59 * b)/100
			bmp.SetPixel(j,i,rgb(gray,gray,gray))
		next j
	next i
	bmp.EndDrawing()
endf

For 8-bit bitmaps, you could just modify the color table even without modifying the bitmap itself.

However, just converting the bitmap to greyscale won't work well as 'greyed-out' state indicator. Probably the best would be to use alpha blending: first draw the background rectangle and then the translucent button image on top of it.

Hi Jalih,

You are running - we arenot even walking! If you take the two following 'Open' bitmaps for use with %ib:

[URL=http://imageshack.us/photo/my-images/14/qej8.png/][/URL]

and

[URL=http://imageshack.us/photo/my-images/41/o56.png/][/URL]

       WINAPP
       OPTIONS (INTL, DREAL)
       PROGRAM IMAGEBAR
       INCLUDE <WINDOWS.INS>
       INTEGER, EXTERNAL ::  OPEN_FUNCTION
       CHARACTER*(8) INSERT(3), INS
       N_IMAGEBAR_TYPE = 1 ! try all 3 modes by changing this 
       INSERT(1) = ''
       INSERT(2) = 'coloured'
       INSERT(3) = 'flat' 
       INS = INSERT(N_IMAGEBAR_TYPE)
       IA=WINIO@('%ca[Old Greyed Imagebar Test]&')
       IA=WINIO@('%th[delay,ms_style]  &', 1, 300)
       IMBAR1 = 1; IMBAR2 = 3
       IA=WINIO@('%?4.1ib['//INS//'][ Open1 ][ Open2 ]'//
     &           '[ Open1 Grey ][ Open2 Grey ]',
     &           'OPEN1',   IMBAR1,     Open_FUNCTION, 
     &           'OPEN2',   IMBAR1,     Open_FUNCTION,
     &           'OPEN1',   IMBAR2,     Open_FUNCTION, 
     &           'OPEN2',   IMBAR2,     Open_FUNCTION)
      END
      INTEGER FUNCTION OPEN_FUNCTION()
      OPEN_FUNCTION = 1
      RETURN;  END
      RESOURCES
      OPEN1 BITMAP 'OPEN_BASIC.BMP'
      OPEN2 BITMAP 'OPEN_VARIANT.BMP'

Save them as BMP to match the resource names above. With the demo you can try the 3 variants of %ib by making N_IMAGEBAR_TYPE 1, 2 or 3, and also see what both greyed out variants look like. Sorry this isn't sophisticated.

The point is that unless you work very hard on the base image, the greyed out version is a blob! Mapping 24-bit RGB to greyscale can be done with multiple algorithms, and I expect (from your other posts) that you are more knowledgeable than I am about these.

I know that when he looks at this, Paul will appreciate your code suggestions.

When I have looked at it, I can see multiple ways to map the RGB colour to greyscale, but it does look to me that what would work best depends on what the background colour is, and it will need a lot of experimentation to get it right.

I much prefer %tb because it gives me fuller control over what the different states look like, but it is a lot less effort to draw just one bitmap and let Paul's code do the work!

(Sorry to split the reply, but I hate it when the Forum truncates my post).

Eddie

Jalih: Many thanks for the suggestion. This looks similar (if not identical) to the code used for %bb.

Eddie: When I get to it, initially I may just offer the option of a second image provided by the programmer.

It occurred to me, late last night, after my 2 posts, that the [flat] mode already contains the 'map to more than 2 colours greyscale'. In this [flat] mode, the affordance (i.e. hint that the button is enabled, and might do something if pressed) comes from it acquiring colour when the mouse pointer passes over it. A greyed-out image without the affordance could - in principle - look no different to this base case.

It therefore occurs to me that the solution which creates least work for you, Paul, together with least chance of upsetting existing code and least extra work for the user, is to create an optional alternative greyed-out button appearance selected with a different stat_ctrl value - perhaps 5 instead of 3 - that is derived from the original bitmap exactly as per the preparation of the base-case [flat] button. There are, after all, almost unlimited unused stat_ctrl numbers that could be considered 'reserved for future use'!

This may prove easier than my original suggestion of using the %bb button code in a rather different context. (And %bb uses an ICO, whereas %ib uses a BMP, so code is not immediately reusable).

My apologies for continuing with this thread when you already said that you needed to work on something else.

Eddie

Many thanks.

I hope that this thread does not get forgotten, especially as some elements of the wish list have been provided e.g. in respect of rounded corners to %ob and dealing with %il limits.

I recognise that 64 bit FTN95 and solving bugs has higher priority.

Eddie

Thanks for the reminder but the port to 64 bits is all consuming at the moment.

Agreed, because 64 bit is the future. Even netbooks are being supplied with Windows 10 64 bit OS now, and the discontinuance of the 32-bit OS will be upon us before we know it.

While not asking for any action at this juncture, I am hoping that other contributors will add to the wish list.

At some point there was a request for a double precision equivalent to the standard SET callback. SETF will be available in the next release as illustrated here...

WINAPP
INTEGER w,winio@
DOUBLE PRECISION v,x
v=0.999
x=1.001
w=winio@('%`cn%^bt[Call SETF]&','SETF',v,x)
w=winio@('%2nl%8rf',v)
END