View previous topic :: View next topic |
Author |
Message |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Aug 16, 2013 4:59 pm Post subject: Format code problems with %hw , %lw |
|
|
Thanks a lot, Paul, this helped and made the 64 bit application react in the same way as the 32 bit application with respect to handle LHDLW1 retrieved by means of the winio call.
Unfortunately I do not know which of the handles need to be 64 bit and which need to be 32 bit for the Clearwin+ 64 bit dll. I'm afraid this problem will occur, as well, in other situations, hence I would appreciate any help how I could find out which of the handles need to be 64 bit for the Clearwin+ 64 bit dll. From your information, Paul, I think some of the handles are 32 bit, others are 64 bit. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Fri Aug 16, 2013 6:51 pm Post subject: |
|
|
You should have a text file with instructions.
Here is the relevant section...
ClearWin+ occasionally uses HANDLEs that correspond to Microsoft HANDLEs such as HWND, HDC, HFONT, HBITMAP etc. These are
all addresses (C pointers). So in 32 bit FTN95 they are stored in user code as INTEGER*4 variables whilst in 64 bit fx64 they require
INTEGER*8 variables. For this reason the clrwin$ modules define an INTEGER KIND called CW_HANDLE that matches the environment.
This means that relevant HANDLEs should be declared with type INTEGER(kind=CW_HANDLE). Note, however, that some HANDLEs described
in the ClearWin+ documentation do not represent Microsoft HANDLEs and these are invariably INTEGER*4. This includes the %gr handle
used in a call to select_graphics_object$. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Fri Aug 16, 2013 8:45 pm Post subject: |
|
|
Dietmar,
I can remember asking a related question in the forum under the title "When is a handle not a handle?" - although I can't seem to find it now. Certainly %gr asks for a Clearwin+ handle. I can't remember what other handles are Clearwin+ handles, and which are Windows handles - but there is probably a Clearwin+ handle associated with %dw as well as with %gr.
However, if you read the CHM file, there are some very subtle clues: if Clearwin+ gives you a handle, then it is a Windows handle. If you give it a handle, then it is a Clearwin+ handle. Often, Clearwin+ works even if you haven't presented the numeric value of a Clearwin+ handle, because arithmetic is never done with the handles, and any value works. Neglecting to set a Clearwin+ handle shows up as an apparently unsolvable problem (for example) if you have two %gr areas, and you have relied on the default for an integer when passing across handles to Clearwin+ for both of them.
It is all so much easier with 32-bit Clearwin+, as both handle types are 4-byte integers. One or two old FTN functions take 2-byte integers, and similar size problems arise there.
Eddie |
|
Back to top |
|
|
dgurok
Joined: 26 May 2011 Posts: 66
|
Posted: Mon Aug 26, 2013 11:23 am Post subject: |
|
|
We are trying to port opengl functionallity from 32 bit to 64 bit.
Our application makes use of call GLUTMOUSEFUNC.
This function is mapped to __cwMouseFunc in FTN95 (32 bit, salflibc.dll).
When we link our application to create a 64 bit executable (using the intel fortran 64 bit compiler and linking against the clearwin64+ dll) symbol GLUTMOUSEFUNC remains unresolved.
Looking at the clearwin64.dll we see that other functions concering the glut stuff have been mapped to functions of clearwin64.dll, for example glutDisplayFunc which has been mapped to function __cwDisplayFunc of cleawin64.dll.
We wonder if __cwMouseFunc should, as well, be contained in clearwin64.dll. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Mon Aug 26, 2013 2:16 pm Post subject: |
|
|
Yes it looks like the following functions have been left out by mistake...
__cwMouseFunc
__cwKeyboardUpFunc
__cwSpecialUpFunc
__cwGetUniqueMenuItem
glutExtensionSupported |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Mon Aug 26, 2013 3:13 pm Post subject: |
|
|
I have added the first three of these functions to the download.
Before using any of the files in the download, make sure that you have backed up your existing files.
I have not tested the bindings for the added functions.
These appear in source64\opengl.f95. If the compile does strong type checking then then the type of the argument will be wrong. |
|
Back to top |
|
|
GEWV
Joined: 25 Nov 2013 Posts: 19
|
Posted: Mon Nov 25, 2013 12:26 pm Post subject: Re: |
|
|
We try to port a big existing application from 32 bit to 64 bit.
I can not find the following functions in clrwin.f95
- GETENV
- CURDIR
- UPDATE_WINDOW
We need this functions. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Tue Nov 26, 2013 8:04 am Post subject: |
|
|
I am working on this. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Tue Nov 26, 2013 10:47 am Post subject: |
|
|
I have added getenv$ and you will be able to call this function from either FTN95 (with a new salflibc.dll) or from a new clearwin64.dll. But note that the bindings are different...
For FTN95 you declare
character(len=1024)::getenv$
otherwise you need to have
USE clrwin$
current_dir$ is already implemented and is preferred to curdir because its declaration is common to FTN95 and third party compilers.
However, I have added curdir$, but note that the bindings are different in the same way as for getenv$.
Note that update_window is an old routine used with ClearWin (%cw) windows. So check that it is used in a relevant way.
However, I have now provided access to it in clearwin64.dll via the name update_window$.
I will post another reply when the new version has been uploaded. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Tue Nov 26, 2013 11:34 am Post subject: |
|
|
A new 64 bit DLL has been uploaded to http://www.silverfrost.com/beta/clearwin64.exe
The default path for this self-extracting archive is C:\Program Files (x86)\Silverfrost
Please backup all related files before extracting.
Note that the argument in update_window$ is a 64 bit integer. |
|
Back to top |
|
|
GEWV
Joined: 25 Nov 2013 Posts: 19
|
Posted: Wed Nov 27, 2013 12:09 pm Post subject: Re: |
|
|
Paul, thank you for your work.
Do the functions also with LINUX? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Wed Nov 27, 2013 4:55 pm Post subject: |
|
|
I notice that Simfit is available for LINUX so I guess the answer is YES.
Perhaps other users might advise on how to do this (using Wine?). |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Thu Nov 28, 2013 8:51 am Post subject: |
|
|
I have uploaded a new ClearWin64.dll (same URL as above).
This brings the GDI+ additions up to date, including text rotation. |
|
Back to top |
|
|
GEWV
Joined: 25 Nov 2013 Posts: 19
|
Posted: Wed Dec 18, 2013 8:34 am Post subject: %im |
|
|
The function winio$('%im[image_name]') doesn't work on Windows 8 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7933 Location: Salford, UK
|
Posted: Wed Dec 18, 2013 9:55 am Post subject: |
|
|
I have logged this for investigation but a small sample program would help. |
|
Back to top |
|
|
|