Silverfrost Forums

Welcome to our forums

Not all the routines in FTN95 are available for .NET?

26 Jun 2007 10:46 #1995

I am writing an FTN95 .NET DLL. I found in the user's manual that 'readf@' is currently only available for Win32. I tried to call it in my .NET DLL. It gives me 'An unhandled exception of type 'System.InvalidProgramException' occurred' error. It worked perfectly in my Win32 DLL. Is there any other routine to call for performing the same task in .NET? When will be the new version, in which all the routines in FTN95 are available for .NET, to be released? Thanks.

27 Jun 2007 4:36 #2001

readf@ is a Win32 specific routine that uses the Win32 API to achieve its business - it is not of course standard Fortran. This routine will not be ported to .NET. An alternative using .NET would be to use the routines that the .NET libraries provide, you can find these in the System.IO namespace for file operations and will have to use .NET extensions to call them.

27 Jun 2007 5:47 #2003

Thanks Andrew! I will try the System.IO Namespace.

6 Jul 2007 2:14 #2030

READF@ should work although it is not portable to other operating systems. The following code runs OK for me under .NET...

integer(2) handle, error_code integer(3) nbytes, bytes_read character(512) buffer buffer = 'READF@ failed' call OPENR@('data.txt',handle,error_code) print*, error_code,handle nbytes = 1000 call READF@(buffer, handle, nbytes, bytes_read, error_code) print*, error_code,bytes_read call CLOSEF@(handle, error_code) print*, error_code print*, buffer(1:64) end

There is a problem with OPENF@ under .NET which we will investigate.

6 Jul 2007 2:30 #2031

Thanks Paul. It also worked for me when I used it to read characters. But it gave errors in .NET, when I tried to use it to read integer values which were saved in binary format.

6 Jul 2007 11:41 #2033

The readf@ and related routines have been ported to .NET and should also be cross platform (although they probably haven't been tested on other systems for a while).

The System.InvalidProgramException could be caused by a bug. If you can supply us with (ideally as short as possible) example code so we can reproduce the issue we will take a look at it.

Please login to reply.