get_filtered_file@ and large array

Since moving to Windows 7, I have had problems with get_filtered_file@ when used in programs with large arrays (typically 500mbytes).

The dialigue box open ok, with all the filters set, set correctly. But, I find the edit box into which the file name is entered locks up when the <cr> key is pressed.

It makes no differnece wether the array is declared in common or the allocate command is used to set the array size.

I see from the forum that others are experincing problems wth large arrays. Does anyone els have this problem.

Here is the code

  MODULE DATA32
  INTEGER*4, DIMENSION(:),ALLOCATABLE::DATA
  END MODULE DATA32


  USE DATA32
  WINAPP
  PARAMETER(MBYTES=700)
  PARAMETER(MILLION=1000000)
  CHARACTER file*129,title*20,path*129
  INTEGER NFILTERS
  PARAMETER(NFILTERS=1) 
  CHARACTER*20 filtname(NFILTERS),filtspec(NFILTERS)

c------------------------------------ C*** allocate mbytes to array data ALLOCATE(DATA(MBYTESMILLION/4),STAT=istatus) IF(ISTATUS.NE.0)STOP 'CANT ALLOCATE MEMORY' c** populate array do j=1,mbytesmillion/4 data(j)=j enddo C*** Use clearwin - get_filtered_file title='Open Bitmap File' file=' ' path=' ' filtname(1)='All files' filtspec(1)='.' CALL get_filtered_file@(title,file,path,filtname,filtspec, * NFILTERS,1) END

On Windows 7 Home Premium X64, your program runs fine when compiled with FTN95 6.0.

Try removing all references to the data array first. Just call get_filtered_file@ and increase the number of characters in file and path to 256.

Thanks for the suggestions which I have followed up.

I have tried it now with version 6, and also made the changes Paul suggested but get the same problem once the array exceeds about 500mega bytes. As before all is ok below this size.

The problem is not with get_filtered file as such as I have tried replacing it with the api call getopenfilename.

I have also used c code to allocate a block of memory with the globalloc function which gets memory from the heap, and the problem is still there once the memory requested exceeds about 500mbytes.

I have also tried putting the get_filtered_ file call in a DLL to no availl.

The only way I can get it work is to put the get_filtered_file call in a separate application and use winexec to executes it, but this is a meesy solution.

I just wondered if any one out there can reproduce the problem.

I tried your code on XP x64 professional and FTN95 Ver 5.50 and had no problems. I modified your code slightly but could not identify the source of your error. I modified ALLOCATE, but the change is probably not required. FILE129 should only have to be increased if the file(tree) name exceeded 129 characters. I even tried FILE25 and the program ran successfully. I would not expect the error you are reporting.

MODULE DATA32 
  INTEGER*4, DIMENSION(:),ALLOCATABLE :: DATA 
END MODULE DATA32 

USE DATA32 

! WINAPP   !  this is probably not needed

integer*4, PARAMETER :: MBYTES  = 700 
integer*4, PARAMETER :: MILLION = 1000000 
integer*4, PARAMETER :: NFILTERS= 2 
!
CHARACTER file*256, title*20, path*20
CHARACTER*20 filtname(NFILTERS), filtspec(NFILTERS)
integer*4 istatus, j, n 
!
!------------------------------------ 
!*** allocate mbytes to array data 
n = MBYTES*MILLION/4
ALLOCATE (DATA(n),STAT=istatus) 
IF (ISTATUS.NE.0) STOP 'CANT ALLOCATE MEMORY' 
write (*,fmt='(a,i0,a)') 'Array DATA(',n,') allocated'
!
!*** populate array 
do j=1,n 
  data(j)=j 
end do 
!
!**** Use clearwin - get_filtered_file 
title = 'Open Bitmap File' 
file  = ' ' 
path  = ' ' 
filtname(1) = 'Bitmap files' 
filtspec(1) = '*.bmp' 
filtname(2) = 'All files' 
filtspec(2) = '*.*' 
CALL get_filtered_file@ (title, file, path, filtname, filtspec, NFILTERS, 1) 
write (*,*) 'File ',trim(file),' selected'
!
END

It seems that the common 'Open' dialog box can use large amounts of memory just to store its own data for all of the folders etc. This kind of problem as been reported a number of times over the years and to my mind there has never been a satisfactory explanation or solution. There ought to be plenty of memory available but for some unknown reason there is a conflict between what the Microsoft dll is doing and the Fortran executable.

The problem apears to occur in a random fashion across various operating systems.

Paul

Thanks for your comments.

I have found that the problem has nothing to do with the Fortran Compiler as I can reproduce the problem using the Silverfrost C++ compiler.

I have also used exactly the same code in Microsoft Visual Studio, and the problem did not occur (i.e. the keyboard did not lock up when pressing the <enter> key at the end of the filename). Further I was able to allocate 1.3gbytes of memory with Visual Studio compared with 500mbytes for Silverfrost.

Here is the code used with both c++ compilers.

// for silverfrost compile and link with // c:\win32app\salford\scc memtest.c /prototypes /ansi_c /no_line /windows /lgo //for visual studio used IDE.

#include <windows.h> #include <commdlg.h>

LRESULT WINAPI MainWndProc( HWND, UINT, WPARAM, LPARAM ); int CALLBACK WinMain(HINSTANCE hInstance,HINSTANCE,LPSTR,int);

int CALLBACK WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow) { HGLOBAL status; OPENFILENAME ofn; char banner[256] =' Visual Studio openfile test '; char filter[256] ='all files\0*.\0'; char filename[256],dirname[256]; filename[0]='\0'; dirname[0]='\0'; int memsize; / grab some memory */ // Visual Studio will get up to 1.3gb, Silverfrost will get up to 500mb) memsize=1300 * 1000000; status= GlobalAlloc(GMEM_FIXED,memsize); if(status == NULL)MessageBox(0,' Cant allocate memory',NULL,MB_OK);

/*open file*/
 
memset(&ofn,0,sizeof(OPENFILENAME));
ofn.lStructSize=sizeof(OPENFILENAME);
ofn.lpstrFilter = filter;
ofn.nFilterIndex=1;
ofn.lpstrFile=filename;
ofn.nMaxFile=256;
ofn.lpstrInitialDir = dirname;
ofn.lpstrTitle=banner;
ofn.Flags= OFN_PATHMUSTEXIST  | OFN_FILEMUSTEXIST ; 

GetOpenFileName(&ofn);
          
return 0;

}

LRESULT CALLBACK MainWndProc(HWND hWnd,UINT message,WPARAM wParam,LPARAM lParam)

{
switch (message)
{ return DefWindowProc(hWnd,message,wParam,lParam) ; }

}

I should have been more specific. Its not so much the Fortran compiler but the linker that is common to SCC and FTN95.

The problem may relate to the base addresses used by the Silverfrost linker and by the relevant Microsoft DLL. This being the case, you will not get the same problem if you were to test with a different C compiler.