Silverfrost Forums

Welcome to our forums

Use of clearwin 32 vs 64 bit

12 Nov 2018 12:22 #22793

I have a code that uses clearwin for for graphics (contour plot) etc. on screen. Text output appears on a white window (windows). When moving it to 64 bit all works (after a few minor changes) except the graphics does not work and the text output appears in a black window (dos box). Bot pieces of code have clearwin64.dll and clearwin64f.dll as references. See https://1drv.ms/f/s!AuTT_gAwgmEIhYgSgFyHwtKCa0SQkg for output of 32 and 64 bit version. Could anyone comment what is going astray here? Thanks, Joost

12 Nov 2018 7:45 #22798

How big is your program? Can you post it somewhere so I can see the code?

12 Nov 2018 8:19 #22799

It is a large complex code of about 50 routines. I posted (see link in start of thread) 2 routines that compose the plot and the 'main' program. The 'Start window' of the Main program works fine. If you wish to see the whole lot, I also posted it in a ZIP file. Plato Project file is in root after unzipping. See if you can do something with this. Cheers, Joost

12 Nov 2018 9:20 #22800

OK. There is a lot of code there and it would take a good few hours to work out what is going wrong.

I am wondering if the code contains old ClearWin code (i.e. DBOS routines) that no longer works as intended.

Is it possible to locate and indicate the ClearWin+ code near the point of failure?

12 Nov 2018 9:46 #22801

There is one point where I inserted 'include <DBOS.INS>' as I got an erro message on a statement including 'GET_WKEY1@'

Could that be the problem???

12 Nov 2018 10:23 #22802

I disabled now GET_WKEY and DBOS but I have still the same problem . Another observation is that when I start the program the intro screen comes up but in the 64 bit version an additional DOS screen comes up (all this is generated by INTRO.F95). I put example and code of INTRO.F95 in link

12 Nov 2018 10:33 #22803

Sorry forgot to answer your question 'Is it possible to locate and indicate the ClearWin+ code near the point of failure?'

here is requested info

GRFMAP line 134, 135, 218-280 TOPLIN line 26-35 (pretty much the whole routine

12 Nov 2018 10:36 #22804

Does your code assume the old VGA colour model? The move to RGB became standard several releases ago.

Eddie

12 Nov 2018 2:08 #22805

The extra DOS screen will be removed if you provide a 'Windows' directive directly to the linker (SLINK64). WINAPP etc. do not always work as they do for FTN95/SLINK.

13 Nov 2018 12:20 #22807

I added in the main program at the very start
call set_rgb_colours_default@(1)

As I am not completely sure whether to use 0 or 1 . Hence, I tried both and nether had the desired result.

Any further suggestions appreciated.

In the mean time I added the windows linker directive and that got indeed rid of the DOS window.

13 Nov 2018 7:11 #22808

After a bit more debugging the problem seems to occur because of a function GET_WKEY1. When this function is called (timstp.f95) the plot (which has been assembled via various routines, appears in the window.

This all works for the 32 bit version

When compile 64 bit, I have to include <DBOS.INS> otherwise I get a link error that GET_WKEY1 is not defined. As per the original post the code than runs ok but the plot does not appear.

From reading other posts on the forum I understand GET_WKEY1 is an outdated function, but I could not work out how to replace it. I had a crack at ADD_KEYBOARD_MONITOR@( CB_FUNC ) see https://www.silverfrost.com/ftn95-help/clearwinp/library/add_keyboard_monitor_.aspx but unfortunately could not work out the use of it.

14 Nov 2018 12:29 (Edited: 14 Nov 2018 12:30) #22810

I have narrowed down with the debugger that the key routine that puts the plot in the graphic window is TIMSTP.F95 (see https://1drv.ms/f/s!AuTT_gAwgmEIhYgSgFyHwtKCa0SQkg and also below in this post).

The statement 'jk=GET_WKEY1@()-314' in line 82 results in the graphic window showing (1st pass) and being refreshed (next passes). The other routines just prepare bits and pieces of the graphic window.

The statement in line 30 'include <DBOS.INS>' is NOT needed for the proper working 32 bit versions but is needed in the 64 bit version as the linker prompts GET_WKEY1@() as an unknown function. But, by including <DBOS.INS> in the 64 bit version the link error is resolved but the graphics window is not generated. So I suspect that I am missing a 64 bit clearwin library, but I can not work out which/what.

From reading other posts on the forum I also understand GET_WKEY1 is an outdated function, but I could not work out how to replace it. I had a crack at ADD_KEYBOARD_MONITOR@( CB_FUNC ) see https://www.silverfrost.com/ftn95-help/clearwinp/library/add_keyboard_monitor_.aspx but unfortunately could not work out the use of it.

Just for convenience I copied the source of the critical routine below.

Any help is much appreciated.

Joost herweijer (joost.herweijer@gmail.com)


  SUBROUTINE TIMSTP

! ! Purpose: ! Housekeeping at end of timestep ! ! Called by TRANS ! Calling CONREC, CONREC1, CONREC2, CONTRL, DBLMAP, DCLOCK@, GRFMAP, ! PRFGRF, SUMRYF, SUMRYW, TOPLIN, VPLT ! ! Record of revisions: ! Date Programmer Description of change ! ==== ========== ===================== ! 19/12/02 C.M.J. Verbeek Code for version 1.00 ! 09/09/05 C.M.J. Verbeek Code for F95 ! use hstop use isingle use lsingle use rarray use rsingle use wells use clrwin

  implicit none

! EXTERNAL CB_FUNC !JCH for SUBROUTINE ADD_KEYBOARD_MONITOR@(CB_FUNC)as pot replacement for GET_WKEY1

! JCH NOV 18 added following statement to avoid link error 'The following symbols were not defined: GET_WKEY1@' ! ! include <DBOS.INS> ! not needed for win32

! include <windows.ins> !JCH in stead of use clrwin

  integer :: jtrn,get_wkey1@,jk
  logical :: lsum1,lsum2,lsum3

  lsum1=(isumry == 3 .or. isumry == 4 .or. isumry == 7)
  lsum2=(isumry >= 9 .and. isumry <= 14 )
  lsum3=(isumry == 5 .or. isumry == 6)

  CALL DCLOCK@(time2)
  DIFTIM=TIME2-TIME1
  TIME1=TIME2
  PTIME=TIME
  IF(ISUMRY < 0 .and. TIME >= TIMCHG) GOTO 10
  IF(MOD(ITIME,LTAB) > 0 .or. ISUMRY == 0) GOTO 20

10 CONTINUE IF((lsum1) .and. IFLAG >= 0) THEN CALL GRFMAP IF(ISUMRY == 3) THEN CALL CONREC ELSE CALL VPLT ENDIF elseif(lsum2 .and. dflag >= 0) then call dblmap call conrec1 call conrec2 elseif(ISUMRY == 8 .and. hflag >= 0) then call commap call conrec ELSEIF(lsum3) THEN CALL PRFGRF ELSEIF(ISUMRY == 2) THEN if(nwel > 0) then CALL SUMRYW else CALL SUMRYf endif ELSE IF(ISUMRY /= 1) KFLAG=0 CALL SUMRYF ENDIF

! Test on Functionkey

20 CONTINUE if(isumry == 0) call toplin jk=0 !JCH found out that jk = -314 w/o screen interaction - GET_WKEY seems to trigger graphics eindow update ??? jk=GET_WKEY1@()-314 !JCh ! if (debug) write(,) jk

! call ADD_KEYBOARD_MONITOR@(CB_FUNC) ! jk=-314

   if(jk < 1 .or. jk > 9) goto 30
  if(nwel <= 0 .and. jk == 3) jk=1
  call contrl(jk)
  jk=0
  CALL TOPLIN
  IF(ISUMRY == 1 .or. ISUMRY == 2) THEN
    KFLAG=0
  ELSEIF(lsum3) THEN
    JFLAG=0
  ELSEIF(ISUMRY == 8) THEN
    hFLAG=0
  ELSEIF(lsum2) THEN
14 Nov 2018 1:52 #22811

As Paul said in other words, it is a major job to go through anybody else’s code and debug it. What you seem to be doing is plotting something and then expecting the user to press a particular key which triggers a new plot of something else. This strikes me as probably a sensible approach in the program that you are working on, although I wouldn’t do it that way.

The problem is, that it is a halfway house between how we would do things as a console application (i.e. in DOS) and a Windows application. In the Windows application paradigm you wouldn’t ask simply for a keypress but you would do something else like popping up a dialogue box, or expecting the user to select something from a menu, or click command button.

The nearest thing that you can do within a Windows paradigm (if GET_WKEYx doesn’t work) is to attach accelerator keys to your window. You have the choice of using the WINIO@ format codes to do this, or, looking at your program fragment for an idea of your programming style, I suggest that the routines

ADD_ACCELERATOR@ and REMOVE_ACCELERATOR@

are most likely the best solution for you. You can find details in the online help file FTN95.CHM under the Clearwin+ Library Reference heading.

How to use this is on entry to your graphics routine, add accelerator keys to represent all the user choices of how to replot with modification, and then before exit, remove them all.

The way that you would do this in a ‘traditional’ Windows way is to plot your graphics in a proper Window with a menu bar. One of the menu items might be ‘Plot options’. Dropping that menu bar down might give you a selection such as ‘All options’, which would present the user with a dialog box from which options could be selected, or there may be a set of options each with its own ‘radio button’. It strikes me that this isn’t an option for your program because (and correct me, please, if I’m wrong) that your program isn’t a complete Windows application.

There is a ‘Gotcha’ with the accelerator approach, and that is it needs the windows handle, not the %gr handle!

Eddie

15 Nov 2018 4:23 #22812

Would anyone have a simple example program using this ADD_ACCELERATOR@(W, KEY_NAME, F) ?

15 Nov 2018 11:34 #22815
program accel
use clrwin
integer iw,ictrl
integer(7) hwnd
integer,external:: cb
iw = winio@('Testing&')
iw = winio@('%hw&', hwnd)
iw = winio@('%lw', ictrl)
call add_accelerator@(hwnd, 'Ctrl+D', cb)
end program

integer function cb()
integer iw,winio@
iw = winio@('Hello')
cb = 2
end function

But %ac is simpler.

Please login to reply.