forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

64 bit ClearWin+
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Wed Jun 12, 2013 9:01 am    Post subject: Reply with quote

I tried to create a test application calling 64 bit ClearWin+ dll by means of the INTEL 64 bit compiler (ifort).

To this end I created the modules necessary (clrwin$.mod etc.) by compiling file clearwin64f.f95 (having exchanged suffix f95 for f90) and linking against library clearwin64.a . This worked fine, all symbols (especially winio$) were resolved.

However, the executable crashed at runtime with a message saying that entry point "SymCleanup" was not found in dll "clearwin64.dll". We have not yet found a solution how to resolve symbol "SymCleanUp".
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Wed Jun 12, 2013 11:37 am    Post subject: Reply with quote

Meanwhile I found out that the missing of entry point SymCleanup is a problem related to using INTEL 64 bit compiler ifort.

It seems that for some reason I do not yet know this problem does not occur if I compile the fortran test application with the /debug option set.

After having compiled the test application with option /debug set the call to winio$ from within the test application worked properly.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Jun 12, 2013 1:32 pm    Post subject: Reply with quote

This is very encouraging. Please let us know if you find a way to resolve the missing entry point. Sounds like a problem for the Intel Fortran Forum (if there is one).

If the ClearWin+ DLL can be fixed in some way then please let us know.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Jun 12, 2013 2:33 pm    Post subject: Reply with quote

Hi Paul,

There is one. And my, isn't it long. The bug fix list in FTN95 looks like a single footnote in comparison. You should take a look. Google will find it.

Eddie
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jun 25, 2013 9:34 am    Post subject: Reply with quote

Meanwhile we have started porting a first application from Salford ftn95 (32 bit) to INTEL 64 bit/ ClearWin64+ . Some calls worked without major changes others did not. Currently we have problems with using winio$ and format code %lv. The example following is nearly the same as the one referring to format code %lv in the documentation of ClearWin+ (32 bit). It compiled under Intel64/ClearWin64+ and gFortran/ClearWin64+. However, it caused runtime errors when executing call winio$ in both cases. Please note that the code has been compiled successfully under ftn95 and executed successfully and as expected. Here is the sample code:

Code:
      program test
      USE CLRWIN$
      character*80 items(4)
      integer num_items
      integer sel(3),view
      integer width,height

      items(1)='|Header_100|Test_50'
      items(2)='|Item1|Data1'
      items(3)='|Item2|Data2'
      items(4)='|Item3|Data3'

      sel(1)=1
      sel(2)=0
      sel(3)=0
      view=1

      width=300
      height=200
     
      i=winio$('%lv',width,height,items,3,sel,view)
     
      end


We looked at the examples of ClearWin64+ and recognized that the first parameter in call winio$ was '%lv[edit_labels,single_selection]' in the corresponding example code. We added this option (i.e. [edit_labels,single_selection]) to our winio$ call and the example worked as expected under Intel64/ClearWin64+ and gFortran/ClearWin64+.
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jun 25, 2013 11:17 am    Post subject: Reply with quote

We observed an inconsistency when using files$ from ClearWin64+. Parameter 2 of call files$ should return the number of files specified via pattern (parameter 1). However, parameter 2 seems to return a number which is 1 less than we expect. We temporarily modified file clrwin.f95 and changed subroutine files$ as appropriate. This made files$ return the value we expected.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Jun 25, 2013 3:03 pm    Post subject: Reply with quote

I have logged these issues for investigation.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Jun 26, 2013 11:50 am    Post subject: Reply with quote

I have fixed these two bugs for the next beta release of 64 bit ClearWin.
Back to top
View user's profile Send private message AIM Address
dgurok



Joined: 26 May 2011
Posts: 66

PostPosted: Fri Jul 12, 2013 8:51 am    Post subject: Reply with quote

I am working with DietmarSiepmann on the same project together. A big part of our main gui application is ported. Now I have discovered another problem using the format code %mn %dl and %lw. The problem occurs with the Intel Fortran (64bit) Compiler and the ClearWin64 dll only. With Salford FTN95 (32bit) and gFortran (64bit) there is no problem and the test program works fine. Maybe there is a bug? But on which side?

The following source code demonstrates the problem:

Code:
      program test
     
      use mswin$
     
      integer*4 i, j,control,F_TIM1
      REAL*8 R8
      external F_TIM1

      i=winio$('%ww[no_border]&')
      i=winio$('%mn[open]&',F_TIM1)
      R8=3.0
!      i=WINIO$('%dl&',R8,F_TIM1)
      i=winio$('%pv%fr&',400_4,300_4)
      i=winio$('%lw',control)   
     
      do j=1,10
       i=F_TIM1()
      enddo

      end

      FUNCTION F_TIM1()
      INTEGER*4 F_TIM1,I4
      LOGICAL*4 LOGIC
      I4=70
      WRITE(*,*)' F_TIM1'     
      INQUIRE(UNIT=I4, OPENED=LOGIC) !+ INQIURE closes the program used with %lw %dl or/and %mn
      IF(LOGIC) THEN
       WRITE(*,*)' LOGIC TRUE'     
      ELSE
       WRITE(*,*)' LOGIC FALSE'     
      ENDIF
      F_TIM1=1
      END



The function F_TIM1 works for itself fine. The program will be closed automatically only when I’m using the format code %lw in combination of %dl and %mn (clicking on the menu ,,open"). I need the ,,inquire” statement in this function and exactly this call provides the problem in combination of %lw %dl and %mn.

If I dont use the formate code %lw and use %mn and %dl only then the application works fine with all compilers (32bit and 64 bit). But I need the format code %lw in the application too.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Jul 12, 2013 4:56 pm    Post subject: Reply with quote

The instructions advise calling stop_when_windows_close$() after using %lw.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Jul 13, 2013 12:57 am    Post subject: Reply with quote

Never heard about stop_when_windows_close$()
How it works?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Jul 13, 2013 5:15 am    Post subject: Reply with quote

This subroutine is only needed for some 64 bit programs. It is effectively the same as yeild_program_control$(y_permanently).
Back to top
View user's profile Send private message AIM Address
dgurok



Joined: 26 May 2011
Posts: 66

PostPosted: Mon Jul 15, 2013 8:37 am    Post subject: Reply with quote

I have not heard about it. I have added this call into the program and everything works fine now. Many thanks for the advice.
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Tue Jul 23, 2013 4:23 pm    Post subject: Problems get_mouse_info@,get_mouse_info$ Reply with quote

We have a Salford application which creates a window using the format code "%gr". In the callback corresponding to "%gr" we retrieve and print out the mouse position as soon as the mouse pointer is moved (making use of function get_mouse_info@ (32 bit) or get_mouse_info$ (64 bit)).

This works properly for Salford 32 bit compile environment and for the 64 bit compile environments gFortran and ifort (64 bit).

We have a modification of that scenario: we implemented one more function, say F_TIM, which will be executed, if the user hits a push button (format code "%bt"). F_TIM contains a while loop which retrieves and prints out the mouse position. The while loop may be left by depressing the right button of the mouse.

This works fine for the Salford 32 bit compile environment. The mouse position is printed out correctly in function F_TIM and left correctly.

For 64 bit compile environments gFortran and ifort (64 bit) function F_TIM is entered correctly if the corresponding push button is hit. However, as soon as the loop is entered, the first mouse position is correct, but the mouse positions following do not change even if the mouse is moved. The loop cannot be left by depressing the right button of the mouse and hence we run into an endless loop.

This is a difference to the behaviour on 32 bit.

Here is our code for Salford 32 bit:
Code:
program test
!      USE MSWIN$
      INCLUDE <WINDOWS.INS> 
     
      integer*4 i,IGR,control,F_TIM1,w,h,F_GR,hwnd
     
      external F_TIM1,F_GR
     

      i=winio@('%ww[no_border,independent]&')
      i=winio@('%hw&',hwnd)
      i=winio@('%mn[open]&',F_TIM1)
      w=300
      h=300
      i=winio@('%`^gr[rgb_colours,black,full_mouse_input]&',
     * w,h,IGR,F_GR)
      i=winio@('%pv%fr%ff&',400,300)
      i=winio@('%^bt[Test]&',F_TIM1)
     
      i=winio@('%lw',control)   
     
!      call stop_when_windows_close@()
     
      end
     
           
      FUNCTION F_GR()
      INTEGER*4 F_GR
      F_GR=4
      RETURN
      END
     
      FUNCTION F_TIM1()
!      USE MSWIN$
      INCLUDE <WINDOWS.INS>       
      integer*4 F_TIM1,PAR1,PAR2,PAR3,I
      LOGICAL*4 LOGIC     
      F_TIM1=2
      LOGIC=.TRUE.
      I=0
      DO WHILE (LOGIC)
       I=I+1
       call get_mouse_info@(PAR1,PAR2,PAR3)
       WRITE(*,*)'get_mouse_info (loop 1): ',PAR1,PAR2,PAR3 ,I   
       IF(PAR3.eq.2) LOGIC=.FALSE.
      ENDDO
      END



We created the corresponding exe file for Salford 32 bit compile environment by means of command

ftn95 test.for /link /windows

If we do not use the /windows option for the Salford 32 bit compile, the behaviour for all the compiler platforms mentioned are the same (and do not produce the correct mouse pointer coordinates).

For gFrotran we also tried compiling with option -mwindows , but this did not work, as well.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Jul 23, 2013 5:56 pm    Post subject: Reply with quote

You should be able to see the source code for get_mouse_info$ in clrwin.f95 (this is from memory, I don't have the files to hand).

I will take a look when I can.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 2 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group