Thank you for the detailed

dboggs · ‎11-30-2016

I use Quickwin a lot, but not usually with customizations to the menu bar. When I have tried this, I have been bamboozled by its interaction with child windows. Specifically, sometimes, a "rogue" window "Graphic1" is created, which persists throughout the program, as I am not able to delete it programmatically.

Recently through LOTS of trial & error study, I have learned how to control the problem, so I wanted to (a) share it, (b) find out if this is the normal behavior, and (c) suggest better documentation.

As explained in the documentation, child windows are invisible until they are written to, or if SETWINDOWCONFIG is called. What should be added to this list is customizing the menu bar using DELETEMENUQQ, APPENDMENUQQ, etc. Apparently, these calls attempt to display the current child window. If there is none, then it will create and display a "rogue" child window "for it's own use"?

Apparently, as I have found in various example programs I have found, these menu calls are commonly made *after* the creation of a child window using an OPEN call, for example OPEN (unit=1, file='USER). In this case, the menuqq calls execute with no problem: They don't actually write anything to the open window, although if nothing has yet been written, the window will be invisible, the menu call will make it visible, and it can then be deleted if the user wants.

But to me, it is generally logical to customize the menu bar before doing anything else with child windows, including any OPEN statements. This is when I run into trouble--the menuqq calls create this rogue window that is visible and persists, and resists efforts to CLOSE it. The solution is to code something like this:

PROGRAM MenuDemo
: various initializations
! Assume menu manipulations are the first thing to me done.
OPEN (0, file = 'USER')
lreturn = DELETEMENUQQ (menuno, itemno)
: Additional menuqq calls
CLOSE (0)
! Program continues

I wish I had discovered this years ago--would have saved me hours of frustration and coping.

Is this behavior well known or considered standard, or acceptable? I think the documentation should describe this undesirable side effect of the menuqq functions, along with some discussion of how to control it.

Kevin_D_Intel · ‎12-01-2016

Thank you for the detailed description. I do not know whether this is well known or considered standard, or acceptable. I need to discuss with others.

dboggs · ‎12-17-2016

It seems as though no users of this forum are really interested in the menu customization offered by Quickwin (or else they have no answers or just don't want to bother). That is fine, but I wonder--how does Intel view the future of Quickwin in general? I am well aware that there are some users here who hate it, but I think they represent the high-level, almost "professional programmer" type who can afford to learn then write "real" Windows code--even though it is, in my humble experience, up to about 10 times longer than a Quickwin solution (when that works). I represent the occasional programmer who just wants a solution. I thought Quickwin had great promise, but now I'm beginning to wonder. Help, Intel, I think there are many of us out here!

I's just like to know if I am misunderstanding this family (menuqq) of commands, or if, truly, the documentation is limited and a small addition would be of great help.

andrew_4619 · ‎12-17-2016

I have not used QuickWin for quite some time but I think the Graphic1 window occurs when you have graphic output that is not directed to a specific child window. I think for example if you have graphics output at a time when you have no child windows or you directed it to a "unit" (the child windows have unit numbers from the open) that does not exist so the system creates one.

I don't recall any particular issues with creating menus other than I recall just deleting all the menu's and then recreating them was much easier than trying to add/insert/delete .

NotThatItMatters · ‎12-17-2016

I have used QuickWin as the driver for my application for 10+ years. There are limitations, but it works well. I created my own InitialSettings function to create all the menus and menu items I needed. I also use application input arguments to customize this InitialSettings function.

The one limitation I have found with QuickWin that made me use the Windows API was the ability to create "dynamic" menus. This IS doable in QuickWin, but I did not have the control I needed to make it work properly. So, aside from that, I have found QuickWin works appropriately. Yes, it is old coding structure (no classes, no oop, etc.) but for the most part it is what I need. Most problems I encounter with it are more a question of my own design than its limitations.

My two cents.

Neels · ‎12-17-2016

I use QuickWin extensively combined with some functionality of Xeffort.

In some cases I use menu modification but through the "InitialSettings ()" function.

Kevin_D_Intel · ‎12-19-2016

QuickWin is a supported feature and will continue to be in future releases. We’ll also try improving documentation.

The Development feedback regarding your issue is that it is not defect but how the *menuqq functions are expected to operate. The user must first open a Qwin window before doing *menuqq operations to it. In your case, you wanted to do these operation before creating the window. There is a feature where one can modify the window (e.g., APPENDMENUQQ, DELETEMENUQQ, etc …) while opening the qwin window. This is done via the declaring a function in your code named INITIALSETTINGS (). All QuickWin applications will try to call a user defined INITIALSETTINGS function during the creation of a QuickWin window.

The sample program below utilizes a user defined INITIALSETTINGS() function.

I also found our QuickWin samples, Calendar and Poker, both make use of this function. Product samples are available online here (or as part of the installed image prior to the PSXE 2017 release).

I will consult our Technical writers about adding mention of this function in the Using Fortran QuickWin Application Projects topic in our User’s guide. It is already listed among the others in the QuickWin Library Routines topic.

! ===========================================================================
! ifort /MW qwin_inq.for
!
! Example of using INITIALSETTINGS
! ---------------------------------------------------------------------------
      PROGRAM TestingQW
      USE IFQWIN
      INTEGER(4) ONEXIT, STATUS, i
      LOGICAL(4) RES
      TYPE (QWINFO) WC

      INTERFACE
        LOGICAL(4) FUNCTION INITIALSETTINGS
        END FUNCTION
      END INTERFACE

      RES = ABOUTBOXQQ('Version 18.0'c)

      open (unit = 11, file='user', title='Main')
!     Set the size of window Main
      WC.TYPE = QWIN$SET
        WC.X  = 0
        WC.Y  = 0
        WC.H  = 22
        WC.W  = 45
        RES = SETBKCOLOR(15)
        RES = SETTEXTCOLOR(0)
      CALL CLEARSCREEN($GCLEARSCREEN)
      STATUS = SETWSIZEQQ(11,WC)

      open (unit = 12, file='user', title='Convergence')
        WC.TYPE = QWIN$SET
        WC.X  = 48
        WC.Y  = 0
        WC.H = 22
        WC.W = 45
        RES = SETBKCOLOR(15)
        RES = SETTEXTCOLOR(0)
      CALL CLEARSCREEN($GCLEARSCREEN)
      STATUS = SETWSIZEQQ(12,WC)

      open (unit = 13, file='user', title='Warnings')
        WC.TYPE = QWIN$SET
        WC.X  = 0
        WC.Y  = 25
        WC.H  = 12
        WC.W  = 96
        RES = SETBKCOLOR(15)
        RES = SETTEXTCOLOR(0)
      CALL CLEARSCREEN($GCLEARSCREEN)
      STATUS = SETWSIZEQQ(13,WC)

      WRITE(11,*) 'I am Child 11.'
      WRITE(12,*) 'Hello World. I am Child 12'
      WRITE(13,*) 'I am Child 13. I am the youngest one.'

      RES = SETWINDOWMENUQQ(3)
      read(13,*) i
      ONEXIT = MESSAGEBOXQQ('Simulation terminated.\n Exit Window?'C,
     &                      'Mother 1.0'C,
     &               mb$iconquestion.or.mb$yesno.or.mb$defbutton1)

      IF (ONEXIT .EQ. 6) THEN
          RES = SETEXITQQ(QWIN$EXITNOPERSIST)
      ELSE
          RES = SETEXITQQ(QWIN$EXITPERSIST  )
      ENDIF

      END PROGRAM


      LOGICAL(4) FUNCTION INITIALSETTINGS()
      USE IFQWIN
      LOGICAL(4) RESULT
      TYPE (qwinfo) qwi
      EXTERNAL USERTILE 

  !   Set window frame size
      qwi.x = 100
      qwi.y = 45
      qwi.w = 800
      qwi.h = 700
      qwi.type = QWIN$SET
      i = SetWSizeQQ (QWIN$FRAMEWINDOW,QWI)
!     Creates first menu called File
      RESULT = APPENDMENUQQ(1,$MENUENABLED, '&File'C, NUL)
!     Add items under the menu File.
      RESULT = APPENDMENUQQ(1,$MENUENABLED, '&Print'C, WINPRINT)
      RESULT = APPENDMENUQQ(1,$MENUENABLED, '&Save 'C, WINSAVE )
      RESULT = APPENDMENUQQ(1,$MENUENABLED, '&Exit 'C, WINEXIT )
!     Creates second menu called View
      RESULT = APPENDMENUQQ(2,$MENUENABLED, '&View'C, NUL)
!     Add items under the menu File.
      RESULT = APPENDMENUQQ(2,$MENUENABLED, '&Size to Fit'C,
     &                      WINSIZETOFIT)
      RESULT = APPENDMENUQQ(2,$MENUENABLED, '&Full Screen'C,
     &                      WINFULLSCREEN)
!     Creates third menu called Window
      RESULT = APPENDMENUQQ(3,$MENUENABLED, '&Window'C, NUL)
!     Add items under the menu File.
      RESULT = APPENDMENUQQ(3,$MENUENABLED , '&Cascade'C,    WINCASCADE)
      RESULT = APPENDMENUQQ(3,$MENUENABLED , '&Tile'C,       USERTILE  )
      RESULT = APPENDMENUQQ(3,$MENUENABLED , '&Status Bar'C, WINSTATUS )
      INITIALSETTINGS = .TRUE.
!     Creates fourth menu called About.
      RESULT = APPENDMENUQQ(4,$MENUENABLED, '&About'C, WINABOUT)

      END FUNCTION INITIALSETTINGS


      SUBROUTINE USERTILE(item_checked)
      USE IFQWIN
      INTEGER(4) STATUS,st
      LOGICAL item_checked,opn
      TYPE (QWINFO) WC

!     Tile opened Child windows.
      WC.TYPE = QWIN$SET
        WC.X  = 0
        WC.Y  = 0
        WC.H  = 22     
        WC.W  = 45
      STATUS = SETWSIZEQQ(11,WC)

      WC.TYPE = QWIN$SET
        WC.X  = 48
        WC.Y  = 0
        WC.H = 22      
        WC.W = 45
      STATUS = SETWSIZEQQ(12,WC)

      WC.TYPE = QWIN$SET
        WC.X  = 0
        WC.Y  = 25
        WC.H  = 12     
        WC.W  = 96
      STATUS = SETWSIZEQQ(13,WC)
! unit 13 is locked for input wait so it is not available
      inquire(unit=13, opened=opn, iostat=st,err=100)
100   write(11,*) "Status from Inquire unit=13", opn, st

! unit 11 is open and available (not locked)
! note it is being used in the callback to write
! out the results of the INQUIRE
      inquire(unit=11, opened=opn, iostat=st,err=110)
110   write(11,*) "Status from Inquire unit=11", opn, st

! unit 20 is not open and available      
      inquire(unit=20, opened=opn, iostat=st,err=120)
120   write(11,*) "Status from Inquire unit=20", opn, st
      END SUBROUTINE
! --------------------------end end end-----------------------

Quickwin MENUQQ operations and control of child windows