crosshair cursor moves over mid grey area and disappears

Not really much of a problem, but if a crosshair cursor crosses an area filled with RGB (127,127,127) it disappears, probably because XORing mid grey with the cursor line colour gives you mid grey.

Visually it gives you the odd effect that looks as though the mouse pointer crosshair went under the filled area.

Eddie

Eddie

I am not clear about whether or not you are requesting a fix. After that it will be a question of who provides the cross-hair and who provides the grey background.

1. the user
2. ClearWin+ or
3. Microsoft

I use a crosshair in black with a one-pixel border in white. A collection of cursors is available in c:\windows\cursors.

Wilfried

Hi Paul,

No fix needed or expected for my original post. This was simply an observation of behaviour that surprised me until I thought about it. The answer was that it was my grey area and my cursor, programmed in Clearwin+.

The scenario is that the user picks first an object, then a coordinate within that object. The object selection is done with an elaborate cursor, and once an object is selected the cursor changes to a crosshair so that the resolution becomes one pixel.

I thought that I'd write a very simple demonstrator for the effect, as the default cursor in a %gr area is a small 1-pixel crosshair, viz:

      WINAPP
      OPTIONS(INTL)
      PROGRAM OLDGREY
      INCLUDE <WINDOWS.INS>
      IA=WINIO@('%ca[Old Grey Whistle Test]&')
      IA=WINIO@('%gr[COLOUR=#7F7F7F]&', 200, 200)
      IA=WINIO@('%ff%nl%bt[Quit]')
      END

I don't normally use the COLOUR (or COLOR) option, and I was surprised to be told that COLOUR was not a valid option. GREY works, but it isn't 127,127,127

This one works:

      WINAPP
      OPTIONS(INTL)
      PROGRAM NEWGREY
      INCLUDE <WINDOWS.INS>
      EXTERNAL iGREY
      IA=WINIO@('%ca[New Grey Whistle Test]&')
      IA=WINIO@('%sc&', iGREY)
      IA=WINIO@('%gr[rgb_colours,WHITE]&', 200, 200)
      IA=WINIO@('%ff%nl%bt[Quit]')
      END
      INTEGER FUNCTION iGREY()
      INCLUDE <WINDOWS.INS>
      CALL DRAW_FILLED_RECTANGLE@(0,0,100,200,RGB@(127,127,127))
      iGREY=2
      END

I was a bit surprised to see that %gr defaulted to VGA colours without the [rgb_colours] option, so my grey rectangle was black! Note that COLOUR option wasn't accepted in the first test even when I used rgb_colours.

For the test I used v 7.20 PE. Have I detected a regression? (Or two?)

Eddie

PS In the second program the cursor disappears in the mid-grey area on the left.

And Wilfried, thanks. I hadn't forgotten, but I haven't got round to thinking about whether it needs a change or not, or indeed, if it is a significant problem.

Eddie

So nobody cares that COLOUR= is not a valid option, or that VGA_COLOURS has reverted to being the default in v7.20?

I suppose I don't care much either, as I never used COLOUR= before, and all my programs started life when VGA_COLOURS was the default!

Eddie

Eddie, I always use constructions like

      j = winio@('%2cu[cross][hand]%`^gr[user_surface,full_mouse_input,'
     *    //'rgb_colours]&',icursor,size_x,size_y,ptr,1L,display)

for all kind of graphics output, together with

hand        CURSOR c:\lisa_g\cursors\hand.cur
cross       CURSOR c:\lisa_g\cursors\cross.cur

in the resource file *.rc. Therefore I don't notice a (possible) change in the default colour mode of different Clearwin versions. In the above example, 'cross' is the crosshair cursor I described above (black with 1-pixel white border), 'hand' the standard Windows hand, active when moving the graphics. I feel it very comfortable to use own / different cursors.

Regards and have a sunny weekend Wilfried

Eddie

I was not aware of a regression. Are you sure that you have used the latest DLL?

Paul,

You are right - I thought I was safe, with a brand new laptop and a first time install of the PE, but my editor was pointing at a USB stick and it was on there. I half expected to be told by someone that their installation didn't throw the error, but there you go.

Next time, I'll add IMPLICIT_NONE and never get a problem!

A useful addition sometime might be a routine:

DONT_RUN_WITH_SALFLIBC_OLDER_THAN@ (Number)

And maybe if Number = 0, then it is equivalent to specifying the version of Salflibc.dll that matches the FTN95.EXE in use (or later).

Anyway, did you see the effect with the cursor? Interesting. I'm going to investigate other cursors along with Wilfried's suggestion. I've already used custom cursors in a number of places.

Eddie

Eddie

I did not see the effect but I know exactly what you mean.

Eddie, I've also had some troubles with a non-actual version of the SALFLIBC.DLL. Therefore, all times when I get a new DLL version I update the number in the following code which I use at the beginning of every program:

ver_nr = scc_lib_version@()
if (ver_nr < 16352) then
  j = winio@('%ca[Error]%sy[3d_thin]%2si!File SALFLIBC.DLL is not actual!%2nl%cn%7`bt[OK]')
  return
end if

Wilfried

Wilfried,

Thanks - I was sure there was a routine out there somewhere. I don't see why FTN95 shouldn't lock the relevant version number into the executable, but that's probably undesirable for reasons I don't know about. In answer to having to change that version number each time you upgrade FTN95, surely you don't have to, because it is the minimum version number it will run with. In any case, your software has its own version number and you have to update that, don't you?

I've found various things in my collection of cursors that do show against a background of RGB@(127,127,127). The problem of looking in the \windows\cursors subdirectory is that they are different in different versions of Windows, so there are a lot, and choosing particular ones to put in my RESOURCES is going to need some experimentation.

As for /undef, I thought the answer was IMPLICIT NONE!

Eddie