Trougle manipulating the Quickwin menu bar

Trougle manipulating the Quickwin menu bar

Quickwin programs open with a default project frame having a status bar and a set of default menus. My Quickwin program opens with a splash screen, composed of a minimalist project frame in which I have deleted the task bar (using CLICKMENUQQ) and the menu bar (using DELETEMENUQQ). This frame is then filled with a solitary child window. This works fine. Then when the program takes over, I wish to resize and reposition the frame, which also works fine. Finally, I wish to add a single menu to the frame, which does not work fine.

I try this using either APPENDMENUQQ or INSERTMENUQQ. Either one adds the menu OK, but it also creates an unintended child window for no apparent reason, having the generic title "Graphic1" and an unknown unit number. It interferes with the program display, and I cannot get rid of it.

Surely the menuqq operations are not supposed to work this way? It doesn't seem possible to create a menu after having deleted all of the default menus. 

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Further to this problem:

When I try to replicate it using a bare-bones single frame, all works OK. The problem must arise either (1) because I relocated/repositioned the frame after deleting the menus, or (2) by something my program does while working in the child window of the first frame.

I will continue to investigate, but any ideas are welcome.

I have done what you describe OK in th past and check the code that works for me.

I did everything within the "initialsettings" routine BEFORE creating any child windows in this order: :

create the frame window, delete all the menus (DELETEMENUQQ), create new menu's (appendmenuqq)


I don't know if the order is important/ relevant, just saying what I did. The graphic1 new window normally happens when there is some graphic output to an undefined child window unit number so quickwin creates a new default one.



I have finally had a chance to investigate this problem further. As it turns out, the phantom 'Graphic1' window will appear (and persist) when the menu bar is deleted, then a child window is closed, then the menu bar is resurrected. This behavior is demonstrated by the following program.

!  Experimenting with the Quickwin menu routines. Investigate what happens when
!  the menu bar is deleted and subsequently restored.

   LOGICAL lret

!  Use the default project frame. There are six default menus.
!  Use a child window to unit 1 for i/o.
      OPEN (1, FILE = 'USER')
      WRITE (1, *) 'Observe the default frame.'
      WRITE (1, *) '<Enter> to continue...'
      READ (1, *)
!  Delete all six menus.
      DO imenu = 1, 6
         lret = DELETEMENUQQ (1, 0)
      END DO
      WRITE (1, *) 'All menus have now been deleted; the menu bar is gone.'
      WRITE (1, *) 'The window position has moved up to take its place.'
      WRITE (1, *) '<Enter> to continue...'
      READ (1, *)
!  Try to close window 1.      
      !CLOSE (1) ! Comment this for successful operation.
!  Add a new (1st) menu, restoring the menu bar.
!  This causes a phantom 'Graphic1' window to appear, but only if window 1 was closed.
      lret = INSERTMENUQQ (1, 0, $MENUENABLED, 'NewMenu'C, NUL)
!  Alternate attempt to close window 1. This one works OK.      
      CLOSE (1) ! Uncomment this for successful operation.
!  Use a child window to unit 2 for i/o.
      OPEN (2, FILE = 'USER')
      WRITE (2, *) 'New menu added, menu bar restored.'
      WRITE (2, *) 'Is there a phantom "Graphic1" window present?'
      WRITE (2, *) '<Enter> to end...'
      READ (2, *)
      CLOSE (2)

!  Moral: If you want to restore a deleted menu bar, don't close any existing
!  windows until after the menu bar is added!

This behavior is disappointing to me because the opening frame and window is intended to be a standard library routine; after display the user takes over with his own code. The library routine should clean up after itself, i.e. close the first window, but it can't. I have to ask the user to clean up after it by closing the window in his own code, and after he configures the menu to boot.

Is there any explanation for this behavior, or is it a bug?

You need to create an INITIALSETTINGS routine and do the menus in this. There is a Quickwin topic on INITIALSETTINGS.

I know about initial settings, I often use it. It doesn't help. Are you saying you have tried to do this using initial settings and the problem doesn't occur?

Actually I compiled and built your #4 post and ran with and without  the close(1) and at no stage do I get the   problem you describe. This was a debug build BTW.

My build is debug also. I have tried it on two different computers/OS, with same results. When I return from vacation I will try it on one or two more. Perhaps others on this forum can also try, else I may have to question my sanity! (Note there are two lines that need to be changed to demonstrate the problem: lines 26 and 33.)

Leave a Comment

Please sign in to add a comment. Not a member? Join today