%BB behaviour in Win XP/Win10

i was trying yo convert my existing app from using %BT to %BB and i am getting unexpected behaviour. for the simple case below on XP when the top button is pressed the lower button goes blank until the cursor is placed over it. If I comment out the default.manifset entry the buttons teext get overwritten. ftn95 v8.05 salflibc.dll ver Xr1 (15:3938-17.6:2016). with ftn95 v8.1 salflibc ver xe! (12:39:56-13:7:2017) it does not have the greying issue but does not display the icons steve WINAPP PROGRAM BB_TEST c ============== IMPLICIT NONE INCLUDE <windows.ins> INTEGER BB_CB1, BB_CB2 EXTERNAL BB_CB1, BB_CB2 INTEGER GREY_BUT1, GREY_BUT2 COMMON /BB_TEST_X1/ GREY_BUT1, GREY_BUT2 INTEGER IWIN GREY_BUT2 = 0 GREY_BUT1 = 1 IWIN = WINIO@('%_{^bb[MN_but1/grey button 2]&', GREY_BUT1, BB_CB1) IWIN = WINIO@('%ff&') IWIN = WINIO@('%}^bb[mn_but2/grey button 1]&', GREY_BUT2, BB_CB2) IWIN = WINIO@('%ff') END

  INTEGER FUNCTIONBB_CB1()
  IMPLICIT NONE
  INTEGER GREY_BUT1, GREY_BUT2
  COMMON /BB_TEST_X1/ GREY_BUT1, GREY_BUT2
  BB_CB1 = 1
  GREY_BUT1 = 0
  GREY_BUT2 = 1
  END

  INTEGER FUNCTIONBB_CB2()
  IMPLICIT NONE
  INTEGER GREY_BUT1, GREY_BUT2
  COMMON /BB_TEST_X1/ GREY_BUT1, GREY_BUT2
  BB_CB2 = 1
  GREY_BUT2 = 0
  GREY_BUT1 = 1
  END

  RESOURCES
  1 24 DEFAULT.MANIFEST
  MN_BUT1 ICON \'MN_dnd_clsupd.ico\'
  MN_BUT2 ICON \'MN_dnd_clscan.ico\'

Works fine for me with FTN95 8.1 on Windows 10 (64 Home).

I suggest that XP isn't a good testbed: many versions old, unsupported for more than 3 years.

Also works fine with // instead of / between icon and text - that keeps the icon coloured when the button is greyed.

Eddie

Eddie. It didn't work on win 10 so i don't think XP was the problem It might be a salflibc.dll version issue. The example seems to work as expected on a win7/64 (salflibc.dll v 19.2.11.12). Many of my end users still have XP system so i need to keep them support. Also i have ancient 16bit code analyser/beautifiers which will not run on the latest versions of Windows but cannot find replacements for

thanks

steve

John

i think you would be surprise how many embedded systems are still using win 3.1 (POST/auto diagnostics)

Long Live XP!!!! (ps. and with the correct registry change its still supported by MS 😛 )

Steve,

If it is a salflibc.dll problem, then perhaps your XP machine has an obsolete salflibc somewhere. Worth a look.

Eddie

Hi all I managed to synchronise all my test machines to salflibc.dll dated 12:23:0 - 11/2/2017. The example now works with correct icon/grey refresh etc. on win 7/64 and win 10/64 pro but still has the grey refresh issue on XP (icon now visible. The odd thing is that it correctly refreshes button 1 but not button 2 😒hock: Application built under win 7 running on win xp still show the odd behaviour so i'm guessing it the way the dll talks to the OS.

thanks

steve

Have you tried an explicit window_update@ or failing that update_window@?

Eddie

Hi Eddie

I will try it as a academic test but in reality its a non-starter as it would mean added handle to all the buttons (numbering in there 000's across all the applications) and add adding the refresh to all the call-backs

thanks

steve

Steve,

Well yes, but in your demonstrator it could narrow down the nature of the problem. I'd have a go but can't reproduce the problem.

If it does turn out to be XP-related, you could update your code to retain %bt for OS versions before Vista, say.

Eddie

Hi Eddie

I tried the windows_update@ on the grey_but1 & grey_but2 variables with no effect. As the behaviour is asymmetrical i tried changing the order of the button calls and it seems that only the first button in the is refreshed. i tried extending the example to 3 buttons with even more oddball behaviour.

thanks

Steve

Steve,

I presume it isn't resolved. My final suggestion is instead of writing your %bb options in explicitly, splice in the appropriate parts of the WINIO@ formatting string dependent on which OS is being used, as in:

      CALL GET_OS_VER@( PLATFORMID, MAJOR, MINOR )
      IF (MAJOR .LE. 5) THEN
          TEXT1 = 't['
          TEXT2 = ''
          TEXT3 = ''
          ELSE
               TEXT1 = 'b['
               TEXT2 = 'ICON1/'
               TEXT3 = 'ICON2/'
               ENDIF
      IWIN = winio@('%b'//TEXT1//TEXT2//' etc ...
      IWIN = winio@('%b'//TEXT1//TEXT3//' etc ...

Setting up the things to splice in only needs to be done once somewhere central in the program.

Eddie

Eddie

I had come to the same conclusion myself. The fiddly bit is managing the options (default,grey,help,call-back func,width etc.)

i have about 10 standard button icons (ok,cancel,print,help ... etc) and my current approach is to have 2 routines for each icon. 1 with a CB and one without.

the positive side effects of having the buttons definition in one place is it cuts down on naming errors and it tidies up the main code.

it would save a lot of man-hours if clearwin behaved consistently

thanks

steve

If ClearWin+ can be demonstrated to behave inconsistently then please post a simple demo so that it can be fixed.

Paul,

I don't think he means inconsistently in the sense of differently every time it runs, which would be your business to worry about, but it certainly behaves differently with different versions of Windows, as illustrated by his example - and in everyone's personal experience.

Steve,

Too many icons in buttons begins to make the program look like one of those Borland Turbo-whatever programs. I recommend using sparingly, rather like icons in menus. As always, the User Experience Guide from Microsoft can be helpful, even though it is usually out of date and sometimes contradictory.

Eddie

Quoted from PaulLaidler If ClearWin+ can be demonstrated to behave inconsistently then please post a simple demo so that it can be fixed.

HI Paul

see my original thread. %bb does not refresh after change of grey control on XP. they go from greyed to blank. moving cursor over button then paints the button with un-greyed image

it works fine on win 7/win10

%bt behave on xp/7/10

Steve

I have had a look at this but unfortunately I have only just dismantled my XP testing environment. In mitigation I would point out that a) %bb may well have been developed post XP and b) there have been at least 4 versions of the OS since XP.

I recommend using %bt (for XP) rather than %bb. You could test the OS version (GET_OS_VERSION@) and switch between %bb and %bt in the code.

HI Paul

I have already started implementing such a os version based button system but with over 3000 %BB across 15 apps its going to be a labour of love

steve

HI Paul

Can i just confirm that you are stating that XP is no longer supported

regards

steve

Steve

No. Not absolutely. If a user encounters a XP bug that does not have a work-around then it may be possible for us to provide a fix particularly if it can demonstrated on a more recent OS.

Steve,

Have you experimented with providing an icon for a %bt using %bi, and does this work in XP? Reading FTN95.CHM suggests that such an icon is limited to 32x32 bits, which is rather large, but I do wonder if that is correct. The syntax for %bi suggests that it might be easier to splice that in to a WINIO@ than the ordinary syntax for %bb.

Eddie