Background: QuickWin GUI code compiled with DF 6.0 on an XP system runs on my own Win7 system, but not on any other. Now a coleague in the UK has succeded in compiling with a current version of IVF, with the same bad result. This code segment works properly in all cases:
USE DFLIB
USE DFLOGM
TYPE (dialog) DBOX0, DBOX1
100 CONTINUE
LNEW = .FALSE.
LOLD = .FALSE.
MENUCODE = 0
DO WHILE (.NOT.LNEW .AND. .NOT.LOLD)
! Twiddle thumbs at 10Hz while waiting for menu selection
CALL SLEEPQQ(100)
END DO
Flags LNEW and LOLD are set in callback routines for mouse clicks on particular menu entries. Every callback routine also sets a specific value for MENUCODE.
However, the following code does not work in newer Win7 systems:
200 CONTINUE
PRINT *, 'Waiting for Menu Selection . . .'
LADD = .FALSE.
LEDIT = .FALSE.
LDELETE = .FALSE.
LVARY = .FALSE.
LVLIST = .FALSE.
LCNNCTIO = .FALSE.
LSRRND = .FALSE.
LSAVE = .FALSE.
LSAVEAS = .FALSE.
LGEOMETRY = .FALSE.
LMULTIGEO = .FALSE.
L3DVIEW = .FALSE.
MENUCODE = 0
DO WHILE (MENUCODE .EQ. 0)
! Another 10Hz twiddle while waiting for Menu selection
CALL SLEEPQQ(100)
END DO
Nothing ever sets a MENUCODE, so the loop is infinite (requires using taskbar to terminate). In fact, by the time execution reaches this point the Frame Window no longer responds to the mouse at all. The window can not be dragged, and never becomes active. What can I have done to lose all control of the Frame Window? The intervening code between these two wait-for-menu loops includes a MESSAGEBOXQQ window and also a sinple text Dialog Box. Both of these "appear" to work in all systems:
IF (LNEW) THEN
IF (FLAG) THEN
IF (MESSAGEBOXQQ('Overwrite existing file?'C, &
& FileName, MB$OKCANCEL) .EQ. MB$IDCANCEL) THEN
LNEW = .FALSE.
GO TO 100
END IF
ELSE
! Is the directory valid?
OPEN (2, FILE=FileName, IOSTAT=IERR)
IF (IERR .NE. 0) THEN
PRINT *, FileName(1:IDOT+4)
STOP '*** Can''t open above file - check Directory.'
END IF
CLOSE (2)
END IF
!
! Use text dialog box to get new Title
FLAG = DLGINIT(IDD_DIALOG0, DBOX0)
FLAG = DLGSET(DBOX0, IDC_List_Title, &
& 'Enter Title for first line of output files')
FLAG = DLGSET(DBOX0, IDC_EDIT1, GeoFile(1:IDOT+3))
ISTAT = DLGMODAL(DBOX0)
IF (ISTAT .EQ. IDOK) FLAG = DLGGET(DBOX0,IDC_EDIT1,DESCRIP(1))
CALL DLGUNINIT(DBOX0)
[similar code in the "LOLD" option]
Print statements after this point (up to and including the Print at statement 200) appear correctly in the control window. Does anyone have a suggestion for tracking this down? Perhaps the most confusing feature is that the code with the old compiler works on at least one Win7 system, but neither the old nor the new compiler generates code that works on most Win7 systems.
Please be specific about what is meant by "current version". We have had issues with QuickWin and Win7 in the past, but don't know of any in the latest version.
Started 2 years, 10 months ago by wladimir47
Windows 7 Basic, Visual Studio 2008, Intel Visual Fortran 11.0.061 & 11.1.051: 1) Exit from the dialog box (function DLGMODAL module IFLOGM) Quick Win projects leads to hang windows. This window can be closed only from the windows task bar. Stuck occurs without the use of dialogue, if at the end of the program to the message "Program Termonated with exit code 0. Exit Window?" answer "No". 2) ...
That's not the latest version, and could be any of 13 updates. Intel Visual Fortran Composer XE 2013 Update 1 is current. QuickWin/Win7 issues did exist in some updates to Composer XE 2011.
QuickWin Frame Window loses control
Background: QuickWin GUI code compiled with DF 6.0 on an XP system runs on my own Win7 system, but not on any other. Now a coleague in the UK has succeded in compiling with a current version of IVF, with the same bad result.
This code segment works properly in all cases:
Flags LNEW and LOLD are set in callback routines for mouse clicks on particular menu entries. Every callback routine also sets a specific value for MENUCODE.
However, the following code does not work in newer Win7 systems:
Nothing ever sets a MENUCODE, so the loop is infinite (requires using taskbar to terminate). In fact, by the time execution reaches this point the Frame Window no longer responds to the mouse at all. The window can not be dragged, and never becomes active. What can I have done to lose all control of the Frame Window? The intervening code between these two wait-for-menu loops includes a MESSAGEBOXQQ window and also a sinple text Dialog Box. Both of these "appear" to work in all systems:
IF (LNEW) THEN IF (FLAG) THEN IF (MESSAGEBOXQQ('Overwrite existing file?'C, & & FileName, MB$OKCANCEL) .EQ. MB$IDCANCEL) THEN LNEW = .FALSE. GO TO 100 END IF ELSE ! Is the directory valid? OPEN (2, FILE=FileName, IOSTAT=IERR) IF (IERR .NE. 0) THEN PRINT *, FileName(1:IDOT+4) STOP '*** Can''t open above file - check Directory.' END IF CLOSE (2) END IF ! ! Use text dialog box to get new Title FLAG = DLGINIT(IDD_DIALOG0, DBOX0) FLAG = DLGSET(DBOX0, IDC_List_Title, & & 'Enter Title for first line of output files') FLAG = DLGSET(DBOX0, IDC_EDIT1, GeoFile(1:IDOT+3)) ISTAT = DLGMODAL(DBOX0) IF (ISTAT .EQ. IDOK) FLAG = DLGGET(DBOX0,IDC_EDIT1,DESCRIP(1)) CALL DLGUNINIT(DBOX0)[similar code in the "LOLD" option]
Print statements after this point (up to and including the Print at statement 200) appear correctly in the control window. Does anyone have a suggestion for tracking this down? Perhaps the most confusing feature is that the code with the old compiler works on at least one Win7 system, but neither the old nor the new compiler generates code that works on most Win7 systems.
Thanks!