topic This is just a guess (flying in Intel® Fortran Compiler

Failure to write to Edit boxes

BearofLittleBrain — Sat, 04 Mar 2017 17:58:39 GMT

I'm back after a retirement break, and am still using CVF6.6C - with the aid of XPMode on my current 64-bit machine.

I've tried to use an old program but could not resist improving it. This has led to aproblem that I haven't been able to solve. I have changed the creation of some of itsDialog boxes from using the QuickWin DlgInit to using calls eg:

iRet = DialogBoxParam(0,MakeIntResource(IDD_DLG_MENUMAIN),0,loc(MainProc), 0).

The use of DialogBoxParam works well on the first usage on a small dialog with 13 controls, but on the next call to the Main Menu with about 420 controls the program crashes when it tries to write/read text in/out any Edit boxes. As an aside, the resource wizard only works up to 255 controls, so I produced the other controls by editing the resource file in Notepad.

The trouble occurs in the callback procedure MainProc in the Message case WM_INITDIALOG. I can write text successfully to a Static control using eg:

bRet = SetDlgItemText(hDlg, IDC_STATIC_GTVER, Cstring(TrimAll(NameVers))),

but as soon as I try to write to an Edit control it goes ape. I have made sure the controls are enabled and I have tried amongst other variations:

bRet = SetDlgItemText(hDlg, IDC_EDIT_MV, '878.00000'C)),
iRet = SendMessage(GetDlgItem(hDlg, IDC_EDIT_MV), WM_SETTEXT, 0, loc(TestStr)),
iRet = SendMessage(GetDlgItem(hDlg, IDC_EDIT_MV), WM_PASTE, 0, 0).

None of them work, just crash the program. I inserted a DialogBoxParam test dialog with one Edit box immediately before the call to the Main Menu. It works fine.

Due to size limitations I cannot attach a screen shot of the complete dialog box, so I attach two partial screen shots of the dialog when it was working with a DlgInit call - TopGtjDlg.jpg and BtmGtjDlg.jpg. In the current version, bypassing all the initial write instructions leads to a dialog with blank Edit boxes where clicking on any Edit box causes a program crash.

Do you think the large number of controls is the cause? Am I doomed to set it back to its old QuickWin version? Any help or suggestions gratefully welcomed.

Bear

Are you compiling Win32 or

jimdempseyatthecove — Sat, 04 Mar 2017 19:02:54 GMT

Are you compiling Win32 or x64?

You might be running into a number of handles limit see. Look at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota

You may need to increase this value if too low (max value is 65,536).

If it is not a handle issue, then you likely made an edit error. Check your edits to assure you have not used the same control ID more than once. I do not recall at this time if you are permitted to have gaps in the ID's

Jim Dempsey

Also, be aware that HANDLE is

jimdempseyatthecove — Sat, 04 Mar 2017 19:08:02 GMT

Also, be aware that HANDLE is:

type PVOID HANDLE;

Older programs (CVF era) assumed HANDLE and DWORD (and INTEGER) were interchangeable. On Win32 they are, on x64 they are not.

Jim Dempsey

CVF was 32-bit only.

Steve_Lionel — Sat, 04 Mar 2017 19:10:52 GMT

CVF was 32-bit only.

Jim, Steve,

BearofLittleBrain — Sat, 04 Mar 2017 22:15:11 GMT

Jim, Steve,

Thanks for your responses: as Steve says, I run 32-bit CVF on my Windows 7 64-bit machine (by using Windows XPMode, so CVF is actually run as it was in Windows XP). XPMode is not the most stable application, but has been running smoothly now that I have got used to it.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota gave a value of 10,000, so I upped it to 20,000 - but no change - the program still crashes. I don't think that I have programmed anything into the code that creates thousands of extra handles, so the result does not surprise me. I have carefully looked through the resource .h & .fd files because my first thought was that there was some duplication or other error in IDs that the compiler had not flagged up. But they look OK. The .rc resource file itself has not changed from when it worked with QuickWin dialog calls, and the IDD_DLG_MENUMAIN dialog coding looks perfectly OK.

Bear

Nowhere do I see the actual

Steve_Lionel — Sat, 04 Mar 2017 23:56:34 GMT

Nowhere do I see the actual error message - just a mention that the program "crashed". The full and complete text of the error message, ideally with a traceback and identification of the lines in question, are the very basic information needed to help resolve any problem.

Steve,

BearofLittleBrain — Sun, 05 Mar 2017 15:12:17 GMT

Steve,

Enlightenment starts to dawn (I think): - it's a .dll problem. Because all my other programs with dialogue boxes that I had converted to DialogBoxParam calls have worked perfectly, I have been disregarding the fact that I was getting a load of .dll warnings on running the programs:

Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information found.
- plus all the rest of the usual .dlls.

The code snippet below fails on the last line shown, emits a WM_COMMAND message with IDC = IDC_EDIT_MV, comes back into MainProc again and goes to the IDC_EDIT_MV case in the WM_COMMAND section. The program then fails because a load of settings in the WM_INITDIALOG section have not been made.

iRet = DialogBoxParam(0, MakeIntResource(IDD_DLG_MENUMAIN), 0, loc(MainProc), 0)
return
end subroutine MainMenu
!
!-------------------------------------------------------------------------------
integer*4 function MainProc(hDlg, Message, wParam, lParam)
!DEC$ ATTRIBUTES STDCALL :: MainProc
! Main callback for IDD_DLG_MENUMAIN
!
implicit none
integer*4, intent(inout) :: hDlg      ! Dialog box window handle.
integer*4, intent(in)    :: Message   ! Integer identifying the window message.
integer*4, intent(in)    :: wParam    ! Message-specific information (hdcCtrl).
integer*4, intent(in)    :: lParam    ! Message-specific information (hwndCtrl).
integer*4                :: hdcCtrl   ! Control DC handle.
integer*4                :: hwndCtrl  ! Control handle.
integer*4                :: iRadio    ! Radio button index.
logical*1                :: ErrA      ! Error flag.
logical*1                :: NonZero   ! NonZero flag - true if data present.
hdcCtrl  = wParam
hwndCtrl = lParam
IDC      = GetDlgCtrlID(lParam)
select case (Message)
  !
  case (WM_INITDIALOG)            ! Message: initialize the dialog box.
    bRet = SetDlgItemText(hDlg, IDC_EDIT_MV, '878.0'C)

I have tried a number of settings changes in Project/Settings/Fortran/Libraries/Use run time library and Project/Settings/C++/Code Generation/Use run-time library as suggested by Jugoslav and you in the thread "Visual Fortran - Access Violation (ntdll.dll)" of 1 Sep 2004 to no avail. I suspect that it fails because the program is QuickWin and I am trying to do too much in Windows programming. Why it works for smaller dialogs is odd.

Bear

This is just a guess (flying

jimdempseyatthecove — Sun, 05 Mar 2017 15:47:37 GMT

This is just a guess (flying leap). Due to smaller dialogs working, I suspect that for the 32-bit CVF generated program that an I/O buffer for reading the resource file is too small. This is something outside your control. A work around (hack) might be to split your massive dialog box into two windows:

1) A window showing the static text with background as seen
2) A window with all your modifying controls... with transparent background

Then Launch the static window (1) as modless dialog, then launch to dynamic window (2) anchored at the coordinate of the static window.

Prior to a formal conversion/test, (after backing up your current resource file) try (quickly) stripping out all the static text of your resource and making the background transparent. See if this runs .AND. has see-through. If that works, make the dialog 1 from your old resource as modeless, and anchor the edit controls window 2 to the static text window 1.

Jim Dempsey

Jim,

BearofLittleBrain — Sun, 05 Mar 2017 17:11:05 GMT

Jim,

Thanks for your comments. Whatever the cause of my problem, the Dempsey kludge is worth trying. I will give it a whirl. Don't hold your breath because it is Sunday evening over here.

Bear

Jim,

BearofLittleBrain — Sun, 05 Mar 2017 17:55:31 GMT

Jim,

I stripped out all but the 62 Edit boxes & 5 buttons - alas no change at all, but thanks for an excellent suggestion. I have checked some of my other QuickWin programs where I use DialogBoxParam and they all complain about the .dll files (but they work). So I will have another hard look to see if there is anything significantly different about this program.

Bear

Quote:BearofLittleBrain wrote

IanH — Sun, 05 Mar 2017 19:44:00 GMT

BearofLittleBrain wrote:

Enlightenment starts to dawn (I think): - it's a .dll problem. Because all my other programs with dialogue boxes that I had converted to DialogBoxParam calls have worked perfectly, I have been disregarding the fact that I was getting a load of .dll warnings on running the programs:

Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information found.
- plus all the rest of the usual .dlls.

Those messages are unlikely to be relevant. They just indicate that the debugger is unable to find the matching symbol file for the particular DLL, most likely because the symbol files are not installed on your computer. The presence or absence of a symbol file should not change run time behaviour, it just provides additional information to the debugger if you are debugging inside one of those DLL's.

These days Visual Studio can automatically download the relevant symbol files for operating system DLL's on the fly, in eras past you needed to do this ahead of time.

Perhaps there is some interaction between quickwin and your code that is problematic, but without seeing code that lets us reproduce the problem, we are likely all just guessing.

(Where is the WM_COMMAND coming from?)

In the debugger "Loaded 'C:

andrew_4619 — Sun, 05 Mar 2017 21:16:56 GMT

In the debugger "Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information found". warnings are quite normal it just means the Microsoft system dll's do not have debug symbols available.

CVF is a long time ago for me but I know with IVF you can have some issues using Quickwin and SDK dialogs (rather than IFLOGM) dialog boxes due to windows message processing. When you write to an edit box there will be a message generated to say it has changed, with a static I don't think you get that.

Ian, Andrew,

BearofLittleBrain — Sun, 05 Mar 2017 22:07:52 GMT

Ian, Andrew,

Thanks for your comments - all the 32-bit dll files are in the XPMode C:|Windows\System32 directory as one would expect, so I am relieved that they are not the basic trouble.

Jim's suggestion led me to try successively removing controls from the dialog and I finished up with just 1 Edit box (IDC_EDIT_MV) & 1 Button. It still fails. This tells me that I have screwed up somewhere in writing MainProc. I will retreat to my lair and start writing it from scratch again (together with its companion update subroutine, about 1360 lines of code in total). I will let you know how I get on when it is working, but in the meantime thanks to all of you who have responded and helped me clarify my thoughts.

Bear

BTW Poo Bear looks like he is

jimdempseyatthecove — Mon, 06 Mar 2017 13:00:14 GMT

BTW Poo Bear looks like he is working on your resource file....

Jim Dempsey