View previous topic :: View next topic |
Author |
Message |
steveDoyle
Joined: 04 Sep 2009 Posts: 108 Location: Manchester
|
Posted: Mon Jul 17, 2017 4:38 pm Post subject: %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" |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Mon Jul 17, 2017 6:04 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
steveDoyle
Joined: 04 Sep 2009 Posts: 108 Location: Manchester
|
Posted: Tue Jul 18, 2017 7:14 am Post subject: |
|
|
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 |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Jul 18, 2017 8:54 am Post subject: |
|
|
... the excuses some people make for still still supporting XP , you don't work in the NHS do you ? ! :O)
... please send a cheque for lots of dosh to ....... LOL |
|
Back to top |
|
|
steveDoyle
Joined: 04 Sep 2009 Posts: 108 Location: Manchester
|
Posted: Tue Jul 18, 2017 9:14 am Post subject: |
|
|
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 ) |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Tue Jul 18, 2017 10:11 am Post subject: |
|
|
Steve,
If it is a salflibc.dll problem, then perhaps your XP machine has an obsolete salflibc somewhere. Worth a look.
Eddie |
|
Back to top |
|
|
steveDoyle
Joined: 04 Sep 2009 Posts: 108 Location: Manchester
|
Posted: Tue Jul 18, 2017 4:11 pm Post subject: |
|
|
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
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Tue Jul 18, 2017 4:36 pm Post subject: |
|
|
Have you tried an explicit window_update@ or failing that update_window@?
Eddie |
|
Back to top |
|
|
steveDoyle
Joined: 04 Sep 2009 Posts: 108 Location: Manchester
|
Posted: Tue Jul 18, 2017 5:03 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Tue Jul 18, 2017 5:22 pm Post subject: %bb |
|
|
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 |
|
Back to top |
|
|
steveDoyle
Joined: 04 Sep 2009 Posts: 108 Location: Manchester
|
Posted: Tue Jul 18, 2017 6:35 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sun Jul 23, 2017 7:02 pm Post subject: |
|
|
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:
Code: | 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 |
|
Back to top |
|
|
steveDoyle
Joined: 04 Sep 2009 Posts: 108 Location: Manchester
|
Posted: Mon Jul 24, 2017 10:23 am Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Mon Jul 24, 2017 12:16 pm Post subject: |
|
|
If ClearWin+ can be demonstrated to behave inconsistently then please post a simple demo so that it can be fixed. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Mon Jul 24, 2017 12:45 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
|