Using ClearWin+ under .NET

A user has asked if ClearWin+ can be used in FTN95 .NET programs. The answer is a guarded YES. At least some of the ClearWin+ functionality runs perfectly well under .NET but at this stage I do not know what the limitations are (if any). You may like to try running your existing ClearWin+ code under .NET and reporting back your findings.

You will not be able to use the standard ClearWin+ modules but the corresponding standard INCLUDE files serve the same purpose and will produce executables for you.

I forgot to mention that you cannot use resource scripts or FTN95 'RESOURCES' under .NET.

We might be able to remove this limitation (and the issue about standard MODULEs) if there is sufficient interest.

However, ClearWin+ resides in salflibc.dll which may not be (.NET) portable to other operating systems (e.g. Linux, though there may be some potential for trying to use a .NET FTN95/ClearWin+ assembly with Mono under Linux).

Hi Paul,

I for one would be very interested in this.

I was able to remove all the references to modules in my code, but the resources limitation will prevent me from creating .NET code.

Any news about the resource inclusion (especially bitmapped buttons)? Or did anybody find a workaround for it? I've tried a few things but could not get it to work.

Thanks!

I am proceeding with the work to make ClearWin+ accessible under .NET but this will not be available for the impending release.

In the meantime the existing approach is to use 'Visual ClearWin'. Details appear in FTN95.chm and a set of samples is provided in the FTN95 download.

Nice to hear, please keep us updated about the progress (like workarounds which are helpful for the .NET/ClearWin+ combination). Our current applications use ClearWin+ a lot so directly switching to Visual ClearWin is not possible, but rather the final aim.

I've found window_update@ to not work when using it with different types of arguments (like a string in the first call, and float in the second). It seems possible to avoid this by specifying C_EXTERNAL for the window_update@, either in the include files or directly, instead of the EXTERNAL.

I am puzzled by your comment about window_update@. It is correctly defined as EXTERNAL in the standard header file. It is in effect an alias for a C_EXTERNAL '__window_update_f' but this definition is not required because it is hard wired into salflibc.dll.

If you want to post a code fragment that illustrates the problem that you describe then I may be able to better understand what is happening.

Small stripped-down program:

program test
!   C_EXTERNAL WINDOW_UPDATE@
   integer i
   real*8 rb_double
   character(len=5) rb_string
   rb_double = 1.0d0
   rb_string = 'test1'
   i=winio@('%5rs&', rb_string)
   i=winio@('%5rf&', rb_double)
   rb_double = 2.0d0
   rb_string = 'test2'
   CALL window_update@(rb_string)
   CALL window_update@(rb_double)
   i=winio@('')
end program

Compiled with 'ftn95 /checkmate /clr test.f95 /link' whereas the checkmate can be replaced with optimise, and the /clr_ver 2 be added without changing the error. Using the full /REF's of the assemblies results in the same crash when starting the compiled executable.

With the 'C_EXTERNAL WINDOW_UPDATE@' at the program start the application works fine, as the non-clr version does. Note that the IL disassembly contains 'WINDOW_UPDATE# : void(valuetype [ftn95lib]Salford.Fortran.Character*,int32)' whereas the IL disasm of the C_EXTERNAL version reads 'WINDOW_UPDATE# : void(valuetype [ftn95lib]Salford.Fortran.Character*)' (supposedly pointer-only usage, therefore omitted checking, or zero-terminated string).

Thanks for your help!

Thank you for the detailed explanation. I will add this to the list of issues that need to be resolved for a full implementation of ClearWin+ under .NET.