Some suggestions for future enhancements to Clearwin+

Given some of the excellent enhancements Paul has made to Clearwin+ recently, here is my first wish list for future Clearwin+ enhancements.

1. A mouse-hover or mouse-over function for %tb like the one Paul developed for %ib.
2. Ability to specify the colour for the outline and area selection in the area selection mode (and colour for the rubber band selection line).
3. More functionality in %lv, including more Excel-like features. (See forum discussions passim)
4. A windows 8 type application manifest, so that existing code would instantly get a make-over, like the 1 24 default.manifest achieved for the XP look and feel. (Or several, enabling user to choose from a family of themes).
5. An enhancement to %il so that if the limits turned out to be the same, that value would be locked into the corresponding %rd or %rf, instead of creating an error.
6. Some more primitives in the graphics area. Examples could include:

1. Line ends, including arrow-heads
2. Arcs
3. Spline or Bezier curves
4. Gradient fills for objects
5. Dotted or dashed lines more than 1 pixel wide

7. Ability to detect a double-click without a left-click before and after.

8. A vertical line or horizontal line to fill a box or complete window – suggest %hl and %vl as those format codes are not used at present – with the ability to choose colour. If for example, a 3 pixel wide line was used, then (say) %3hl, with the colours being given as parameters, as in:

   IA=WINIO@(‘%3hl&’, RGB@(192,192,192), RGB@(100,100,100),RGB@(0,0,0))

Within a %ob...%cb box, the lines would extend to the height or width of the box only. 9. A REBLANK@ function to match the UNBLANK@ function. 10. The ability to put a string into an effectively initially_blank edit box that disappears when the box gets the focus, for example like the Windows boxes that contain “Type your password here...” 11. More ability to include things in the status line at the bottom of a window: the existing one is very Windows 95 in appearance and limited in functionality. 12. %ob...%cb boxes with rounded corners. And this one, which is very clearly a fantasy: The ability to declare a whole sequence of Clearwin+ format codes make up a button in their own right! (This to match the very elaborate clickable areas in Windows 7). Maybe this could be an enhancement to %ob...%cb, e.g.

IA=WINIO@('%ob[invisible,button]&', button_callback)

Does anyone else have some favourites to add?

Eddie

Most of these would need some further explanation and discussion so I suggest you rank them in order of importance and then let's take them one at a time.

Hi Paul,

These are suggestions - for consideration - and not a list of definite requests. I'm content (happy overstates it!) to be told *'No', *or 'not yet', or 'too difficult' or even *'over my dead body!'. *I was hoping to provoke other users into saying either *'Yes, I like that one', *or 'I would like something else', so that you have a steer from the community at large. I completely understand that your priorities are set by yourself and the rest of Silverfrost, which is right and proper. As there are 13 points in my list (12 numbered, and 1 thrown in at the end) I'll have a go at each of them in a separate post. I don't have a specific priority associated with the numbering, as they were just random ideas that occurred to me over the last year, and had got to the point that I had a list long enough to consider posting.

I'll try to amplify each in a separate post if you don't mind me appearing to monopolise the forum for a while (at least in this thread).

Best regards

Eddie

I was hoping that we could just take one at a time so I suggest that you start with the top of your wish list.

Suggestion No 12: Rounded corners for %ob ... %cb boxes.

I’ve edited a screen-grab from a simple program to show the effect in the first labelled box “Readings”. I haven’t gone very rounded, but you can see the effect relative to the square corner boxes – aesthetically it reflects the rounded corners on the buttons when using the Windows XP manifest.

Difficulties obvious even to me: There look to be multiple cases to address, particularly where different 3_D styles are in use, e.g. raised, depressed, panelled etc. Just how rounded should the corners be? What about %n.mob? I suggest that the rounded corners should be for the outermost box line only. Clearly it is incompatible with the invisible style – could be an error message or just ignored. Suggestion as to how it might look in Clearwin+ code: Probably to invent another style option: rounded Priority: Nice to have, but far from critical. Present workaround: Use a background bitmap, although these have the potential to be huge.

Is this the degree of detail that you wanted?

Eddie

Yes this is very helpful. I think that I can do this one but, to help me with my work load, can you wait till I report that I have completed this one before posting another.

Thanks.

Paul

Of course. I will try to present the ideas in as helpful a manner as I can.

Eddie

Eddie, I have a routine for drawing dotted or dashed lines. It is a bit rough but here it is:

      subroutine line_pattern(x1,y1,x2,y2,step,ipattern,npatt)
      dimension ipattern(npatt)
      dx = x2-x1
      dy = y2-y1
      alen = sqrt(dx**2+dy**2)
      nstep = nint(alen/step)
      delta = alen/float(nstep)
      dx = dx/alen*delta
      dy = dy/alen*delta
      x = x1
      y = y1
      call vecto2(x,y,0)
      do 10 i=1,nstep
        x = x + dx
        y = y + dy
       j = mod(i-1,npatt)+1
        call vecto2(x,y,ipattern(j))
   10 continue
      end

Where: x1,y1 = line start x2,y2 = line end step = length of each segment ipattern = array of 1 and 0 defining the pattern npatt = size of ipattern array

routine vecto2 is for line drawing with the third parameter being the 'visibility' 0 for off (i.e. 'move to') and 1 for on (i.e. 'draw to')

Pattern was defined as:

      dimension ipattern(17)
      data ipattern/1,1,0,0,0,1,1,1,1,1,1,1,1,1,0,0,0/

This produces a centreline effect, but any pattern can be specified.

For an arc I used this code:

      subroutine arc2_pattern(xcen,ycen,rad,theta1,theta2,step,
     &                       ipattern,npatt)
      dimension ipattern(npatt)
      angmax = step/rad*180/3.14159265359
      t1 = theta1/180.0*3.14159265359
      t2 = theta2/180.0*3.14159265359
      nseg = max(4,nint(abs((theta2 - theta1))/angmax+0.5))
      dt = (t2-t1)/nseg
      x = xcen + rad*cos(t1)
      y = ycen + rad*sin(t1)
      call vecto2(x,y,0)
      do 10 i=1,nseg
        t1 = t1 + dt
        x = xcen + rad*cos(t1)
        y = ycen + rad*sin(t1)
        j = mod(i-1,npatt)+1
        call vecto2(x,y,ipattern(j))
   10 continue
      end

I suppose for general code, the subroutines should remember how far through a sequence they have drawn and use this to start the next segment, e.g. for an arc changing to a line or another arc or a spline etc. It was not needed for my function so I did not code it. Regards Ian

My wish since years: Something like %12.3rf to define the numbers of decimals for the output of decimal values (similar to the Fn.m format descriptor in Fortran).

Another idea: When drawing a rectangle with set_graphics_selection@(1), it would be nice if after the release of the left mouse button, the window keeps visible and one can move the borders with the mouse (for instance, to define the area of a part of a displayed image).

Regards Wilfried

Thanks Ian and Wilfried.

I'll add Wilfried's precision format to my list, and think very hard about graphics facilities. Clearly most things can be done with very few simple primitives within a %gr area relatively easily in comparison to doing things in a format window.

Eddie

%ob[rounded] has been added and this can be tested with today's beta.

Both of Wilfried's suggestions are interesting but would require a significant allocation of development time.

Paul,

I'll go and test it over the weekend.

I suspected that Wilfried's suggestion(s) were difficult, but if you don't mind, I'll keep them onboard on the list.

With regard to the stretchable box, I can't see why it can't be programmed with existing Clearwin graphics features. My favourite application CorelDraw has such a feature. The stretchy box appears with 8 'handles', one on each corner, one on each midside.

I have programmed an example for this which I have put here https://dl.dropboxusercontent.com/u/76596632/Stretchy_box.zip on Dropbox - I can't post the code as it is too long and anyway the code needs 5 cursor resources.

As this isn't a real need of mine, I have left the code in a state where you can pick up a handle and do the appropriate stretching, BUT if you move too fast you drop the handle. I don't know how to fix that, but I suspect it is a matter of perseverance. Secondly, the code relies on setting XOR mode, and while when you draw something on a black background in XOR mode you get the correct colour, when you draw it on white you get the colour complement (I wanted blue for the stretchy box, which works over black, but over white you get yellow!).

As a note for Wilfried, the 8 handles are numbered clockwise from the top left corner. I got the cursors from Vlasta (http://www.rw-designer.com/cursor-set/antialiased-classic).

Eddie

Hi Paul, what am I doing wrong? My first box starts like this:

      IA=WINIO@('%bg[btnface]%sy[3d_thin]%ww[fixed_size,no_maxbox]&')
      IA=WINIO@('%ob[named_l][Readings]&')

I get a runtime error saying that the [rounded] is incompatible with the other options. I've tried:

      IA=WINIO@('%ob[named_l,rounded][Readings]&')

and also just

      IA=WINIO@('%ob[rounded]&')

Wilfried,

I solved the problem of dropping the handles, the revised code is here:

https://dl.dropboxusercontent.com/u/76596632/W1.for

Eddie

My request would be to

• general change: CWP has to align all controls on their bottoms or middle (for %rb) not on top which is already discussed here. That may require serious change in CWP or could be easy and offered as an option, only devs cvan know that

• develop CWP diagnostic tool which will tell the place causing CWP crashes. I am dying with my tricky and complex (and most probably buggy) GUI under Windows 8 right now. being huge and complex and impossible to shorten it conflicts with Win8, or with Win32 limit, or something else. The so called 'XP service pack 3 compatibility' and 'Run as Admin' helps a bit but after 3-4 successful attempts to open and close some windows the GUI always predictably crashes. So i sometimes compile and leave it with CHECK and crash disappears, but then reappears again after some non-related changes in the code.

• the OpenGL function which tells about pixel color under the cursor

Hi Dan,

In a manner of speaking, the alignment of some controls is at their bottom, because the coordinates are measured down from the top, so the top is really the bottom !

This coordinate system drives me mad, especially in graphics.

May I commend to you the %rp and %rp format codes (together with %ap and %ap, if you have to)? It is always worth working out what the Windows average character size is by displaying the grid with %gd. You can count the pixels by doing a screen grab, and pasting into the Paint application, then zooming. An alternative is to invest in 'Ruler by George' which gives you an onscreen pixel-calibrated ruler for measuring such things. This is usable as freeware, but to nag you to buy it the markings gradually fade away. (You can refresh them, but they stay visible if you spend the $17).

I can't help with the crashes, sorry.

Eddie

Eddie, Tried your stretchy box application and have made a few mods to allow any backgound colour and used 'RGB_COLOURS' option in the %GR. Ian

      WINAPP
      OPTIONS (INTL, DREAL)
      PROGRAM WILFRIED
C     ----------------
      COMMON /BOXCORNERS/ iX1, iX2, iY1, iY2, NCURS
      COMMON /PICKUP/ MOVING, NODE
      common /draw_mode/iback_colour,idraw_colour,idraw_xor,iwid,ihgt
      INCLUDE <WINDOWS.INS>
      INTEGER, EXTERNAL :: KALLBACK
      INTEGER, EXTERNAL :: iBOXPLOT
      INTEGER, EXTERNAL :: klear_screen
      iX1 = 100;  iX2 = 300;  iY1 = 100;  iY2 = 300
      NCURS  = 1
      MOVING = 0;  NODE = 0
      iback_colour = rgb@(255,200,200)
      idraw_colour = rgb@(  0,  0,255)
      idraw_xor    = xor(iback_colour,idraw_colour)
      iwid = 400 ; ihgt = 380
      IA=WINIO@('%ca[Test for stretchy box]&')
      IA=WINIO@('%sc&', '+', klear_screen, iBOXPLOT)
      IA=WINIO@('%5cu[arrow][updown][leftright][diag1][diag2]&', NCURS)
      IA=WINIO@('%`^gr[WHITE, full_mouse_input, rgb_colours]', 
     &           iwid, ihgt, iHANDLE, 
     &           KALLBACK)
      STOP;   END
      INTEGER FUNCTION KALLBACK()
C     ---------------------------
      COMMON /BOXCORNERS/ iX1, iX2, iY1, iY2, NCURS
      COMMON /PICKUP/ MOVING, NODE
      KALLBACK = 1
      iSENSITIVE = 8

      iXA = (iX1+iX2)/2
      iYA = (iY1+iY2)/2
      CALL GET_MOUSE_INFO@ (jX, jY, jFLAGS)
      IF (NODE .NE. 0 .AND. MOVING .EQ. 1) GO TO 100
      NODE = 0
      IF (ABS(iX1-jX) .LE. iSENSITIVE) THEN
          IF(ABS(iY1-jY) .LE. iSENSITIVE) THEN
             NCURS = 4
             NODE  = 1
             MOVING = 1
          ELSE IF(ABS(iY2-jY) .LE. iSENSITIVE) THEN
             NCURS = 5
             NODE  = 7
             MOVING = 1
          ELSE IF(ABS(iYA-jY) .LE. iSENSITIVE) THEN
             NCURS = 3
             NODE  = 8
             MOVING = 1
          ENDIF
      ELSE IF (ABS(iX2-jX) .LE. iSENSITIVE) THEN
          IF(ABS(iY1-jY) .LE. iSENSITIVE) THEN
             NCURS = 5
             NODE  = 3
             MOVING = 1
          ELSE IF(ABS(iY2-jY) .LE. iSENSITIVE) THEN
             NCURS = 4
             NODE  = 5
             MOVING = 1
          ELSE IF(ABS(iYA-jY) .LE. iSENSITIVE) THEN
             NCURS = 3
             NODE  = 4
             MOVING = 1
          ENDIF
      ELSE IF (ABS(iXA-jX) .LE. iSENSITIVE) THEN
          IF(ABS(iY1-jY) .LE. iSENSITIVE) THEN
             NCURS = 2
             NODE  = 2
             MOVING = 1
          ELSE IF(ABS(iY2-jY) .LE. iSENSITIVE) THEN
             NCURS = 2
             NODE  = 6
             MOVING = 1 
          ENDIF
      ELSE
          NCURS = 1
          MOVING = 0
      ENDIF

      IF (NODE .EQ. 0) RETURN

  100 CONTINUE
      IF (jFLAGS .EQ. 1) THEN 
         IK = iBOXPLOT()
         IF (NODE .GE. 1 .AND. NODE .LE. 3) THEN
             iY1 = jY
         ELSE IF (NODE .GE. 5 .AND. NODE .LE. 7) THEN
             iY2 = jY
         ENDIF
         IF (NODE .GE. 3 .AND. NODE .LE. 5) THEN
             iX2 = jX
         ELSE IF (NODE .EQ. 1 .OR. NODE .GE. 7) THEN
             iX1 = jX
         ENDIF
         IK = iBOXPLOT()
         ELSE
         MOVING = 0       
         ENDIF     
      RETURN;  END

continued

      INTEGER FUNCTION iBOXPLOT()
C     ---------------------------
      COMMON /BOXCORNERS/ iX1, iX2, iY1, iY2, NCURS
      common /draw_mode/iback_colour,idraw_colour,idraw_xor,iwid,ihgt
      INCLUDE <WINDOWS.INS>
      iBOXPLOT = 1
      CALL GRAPHICS_WRITE_MODE@ (3)
      iXA = (iX1+iX2)/2
      iYA = (iY1+iY2)/2
      CALL DRAW_RECTANGLE@ (iX1, iY1, iX2, iY2, idraw_xor)
      CALL DRAW_FILLED_ELLIPSE@(iX1, iY1, 4, 4, idraw_xor)
      CALL DRAW_FILLED_ELLIPSE@(iX1, iY2, 4, 4, idraw_xor)
      CALL DRAW_FILLED_ELLIPSE@(iX2, iY1, 4, 4, idraw_xor)
      CALL DRAW_FILLED_ELLIPSE@(iX2, iY2, 4, 4, idraw_xor)
      CALL DRAW_FILLED_ELLIPSE@(iXA, iY1, 4, 4, idraw_xor)
      CALL DRAW_FILLED_ELLIPSE@(iXA, iY2, 4, 4, idraw_xor)
      CALL DRAW_FILLED_ELLIPSE@(iX1, iYA, 4, 4, idraw_xor)
      CALL DRAW_FILLED_ELLIPSE@(iX2, iYA, 4, 4, idraw_xor)
      RETURN
      END
      integer function klear_screen()
      common /draw_mode/iback_colour,idraw_colour,idraw_xor,iwid,ihgt
      INCLUDE <WINDOWS.INS>
c clear screen to chosen background colour
      call DRAW_FILLED_RECTANGLE@(0,0,iwid-1,ihgt-1,iback_colour)
      klear_screen = 1
      end

      RESOURCES
      1 24 default.manifest
      arrow       CURSOR    'SmoothArrow.cur'
      updown      CURSOR    'SmoothVerticalSize.cur'    
      leftright   CURSOR    'SmoothHorizontalSize.cur'
      diag1       CURSOR    'SmoothDiagonal1.cur'
      diag2       CURSOR    'SmoothDiagonal2.cur'
      

Hi Ian,

I saw that you were on the forum. Let's hope that Wilfried takes something away from this: being able to do things in a %gr or %dw workspace is sometimes a matter of knowing a single trick. I hadn't mastered XOR in colour - it always worked on my Apricot with Green on Black without too much thinking about, and I hadn't used it since. I forgot to USE_RGB_COLOURS. Thanks for your input.

I think that my graphics callbacks are the longest and most complicated procedures I ever write.

An update to %lv - which is a matter of mutual interest - is still on my list.

Regards

Eddie

I thought the problem of 'dancing controls' is pretty obvious, i wrote many time about it.

Look at two first pics with GUI fragments again. First provided as is and in the second i placed red lines along to tops. Natural writing is aligned on the bottom as you can see from my words you read now.

Third pic shows misalignment of subscript and superscripts (guess, which subscripts are in the first black box? They were photoshopped below in the box - here is how they should look).

Two next ones marked in magenta show vertical spacing is different for radiobuttons versus %rd/rf making ugly congestions of lines with radiobuttons. All that were published here and is hidden somewhere in the forum messages

Magnify them to full screen. The controls alignment in the line on the common top and vertical spacing is very unnatural and sometimes looks really ugly, like a mess. What %ap %rp, that painful manual procedure is useful for correcting 1-2 controls, not each and every of them. If contols were visually mouse movable even then this would be a hell