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 

%ss and browse_for_folder@ under 64bit
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


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

PostPosted: Sun Jul 31, 2016 8:20 am    Post subject: Reply with quote

Maybe you could use a ClearWin+ progress bar as illustrated here...

Code:
      winapp
      integer i,winio@,RGB@
      integer,external::cb
      double precision d
      common d
      d = 0.0d0
      i=winio@('%ca[Progress Bar]&')
      i=winio@('%dl&', 0.1d0, cb)
      i=winio@('%20br',d,RGB@(255,0,0))
      end

      integer function cb()
      double precision d
      common d
      d = d + 0.01d0
      cb = 1
      if(d > 0.99d0) cb = 0
      end
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



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

PostPosted: Sun Jul 31, 2016 10:39 am    Post subject: Reply with quote

Paul,

I think Chemie knows about %br, and was asking if the get and put subprograms could somehow provide a value (equivalent to your 'd').

Chemie,

I think the answer is for you to change the cursor. The classic method is one change to an hourglass, but if you have several cursors you can flip them (using %dl). Alternatively, there are animated cursors. 'Vlasta' has a 'Smooth' set of common design cursors including an animated hourglass. (See, for example, http://www.rw-designer.com/cursor-detail/55).

Eddie

Edit: This is the sort of free download that needs 'attribution' somewhere in your software. A good place is in the 'About ...' sub menu item of your Help menu.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Aug 01, 2016 7:13 am    Post subject: Reply with quote

Eddie

A ClearWin+ library function could be created that users would call before calling display_dib_block@ etc. but to do this properly would involve a few hours work. For the moment I will add this to the wish list.

My sample is not far short of what is needed. Its main limitation is that the length of the bar is not connected to the amount of progress. On the other hand a ClearWin+ function could do everything for you even to the point of creating and destroying a temporary progress bar window. Then ClearWin+ might add a cancel button....
Back to top
View user's profile Send private message AIM Address
Chemie



Joined: 07 Mar 2015
Posts: 49

PostPosted: Mon Aug 01, 2016 10:17 am    Post subject: Re: Reply with quote

Eddie,
I use the cursor_wait, but with this, I can't see the end of (in my example) the loadingtime. A sliding bar, which reaches 100% at the end of loading is more comfortable.

Paul,
thank you for putting my proposal on the wish list. My proposal was only a contribution for helpful programming. It is not essential for me, I can live with the hourglass cursor.

Chemie
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Tue Aug 02, 2016 12:00 pm    Post subject: Reply with quote

Chemie,

The sliding bar is only possible if you know how far you are through the process, and axiomatically you cannot know this unless Clearwin+ tells you, or you have some other method of finding out.

Obviously, if you have control, say by executing a long DO loop, you know well enough to run the bar (even if the steps are uneven in execution length, you know well enough). You could calibrate the time on a particular machine by running a trial, and then use the results of that to inform your progress bar. If the software runs on different machines, you could have the calibration run as part of the installation process.

Another alternative is to run the file loading activity in an independent window so that it doesn't matter how long it takes, your machine isn't unresponsive.

On the whole, I prefer Paul's acknowledgement that he could arrange for progress information to be produced. With the file sizes now possible, and cpus not getting much faster, the issue is bound to become more evident in the future.

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



Joined: 07 Mar 2015
Posts: 49

PostPosted: Tue Aug 02, 2016 5:05 pm    Post subject: Re: Reply with quote

Eddie,
it's not only, that the loading is different for different pcs, but in the same pc the loading time is also dependent from the storage medium. I have tested the loading of a 9gb bmpfile, the loadingtime is for a SSD-disk 30 seconds and for a normal hard disk 80 seconds. I have not tested for an USB Stick, but I believe the time will be much larger. Sure, I can calibrate for several pcs or storage media und save the values, but is this comfortable?
In the case of bmpfiles, I have my own bmpload subroutine and there the progress is calculated and updated in the loading DO loop. The sliding bar is terminating exactly, when the loading process is finished. For jpgfiles I had similar subroutines in c, but with 64bit the c-compiler produces many errors when I compile the subroutines. This happens not under 32bit, therefor I have to use get_dib_block@ or transform the jpgfile to bmp.
I agree with you, that we wait for Paul's acknowledgement.

Chemie
Back to top
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Tue Aug 02, 2016 6:37 pm    Post subject: Reply with quote

My guess is that until Paul has had time to put in the necessary timing information hooks, calibration and estimation is all you can do. At least the animated cursor Castle shows you that the programme has not hung up. Another thing that Windows does is to lie to you saying things like "completion in 30 seconds", when several minutes later you realise that you had been deceived!


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



Joined: 07 Mar 2015
Posts: 49

PostPosted: Sat Aug 13, 2016 4:08 pm    Post subject: Re: Reply with quote

Hi,
I've another problem, a mysterious, not understandable phenomenon in the call of resize_window@. Look at my testprogram:

winapp

module size
integer*4 a,xresize,yresize,xpic,ypic,picctrl,bildhandle
end module size

program resizewindowtest
use mswin
use size
implicit none

integer*4,external :: cb_resize

xpic=1000
ypic=800

a=winio@('%ca[Picture]&')
a=winio@('%mn[Resize]&',cb_resize)
a=winio@('%gr&',xpic,ypic)
a=winio@('%hw&',bildhandle)
a=winio@('%lw',picctrl)

end

integer*4 function cb_resize()
use mswin
use size
implicit none

cb_resize=0
xresize=1500
yresize=1000

call resize_window@(bildhandle,xresize,yresize)

! a=winio@('%ca[Meldung]&')
! a=winio@('%nl%wd %wd&',xpic,ypic)
! a=winio@('%2nl%cn%9`bt[OK]')

print*,xpic,ypic

return
end

here, I never alter the value of xpic, but after the call of resize_window@, the value is changed to 0 and not 1000, as shown in the print command. Under win32 and also, when I use the last three winio@ calls, there is the correct value for xpic.
Ok, I can correct this by

xsave=xpic
ysave=ypic
call resize_window@(bildhandle,xresize,yresize)
xpic=xsave
ypic=ysave

but is this a good solution?
I have tested the program on three computers, the results are always the same.

Thanks
Chemie
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Aug 18, 2016 9:36 am    Post subject: Reply with quote

I can't reproduce the behaviour that you describe but try returning a value of 1 from the cb_resize callback.

Note also that the dimensions for %gr are constant values - they are not dynamically linked to the variables xpic and ypic. %gr uses the values and not the addresses of xpic and ypic.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Aug 19, 2016 1:46 am    Post subject: Reply with quote

The problem is that bildhandle should be integer(7) for both 32 and 64 bit. Try the following changes:
Code:
winapp

 module win_size
  integer*4 a,xresize,yresize,xpic,ypic,picctrl
  integer(7) bildhandle
 end module win_size

 program resizewindowtest
 use mswin
 use win_size
 implicit none

 integer*4,external :: cb_resize

 xpic=1000
 ypic=800
 xresize = xpic
 yresize = ypic

 a=winio@('%ca[Picture]&')
 a=winio@('%mn[Resize]&',cb_resize)
 a=winio@('%gr&',xpic,ypic)
 a=winio@('%hw&',bildhandle)
 a=winio@('%lw',picctrl)

 end

 integer*4 function cb_resize()
 use mswin
 use win_size
 implicit none

 cb_resize=1 ! 0
 xresize=xresize + 20
 yresize=yresize + 15

 call resize_window@ (bildhandle,xresize,yresize)

 print*,xpic,ypic
 print*,bildhandle

 return
 end
Back to top
View user's profile Send private message
Chemie



Joined: 07 Mar 2015
Posts: 49

PostPosted: Mon Aug 22, 2016 10:02 am    Post subject: Re: Reply with quote

Hi John,
with integer(7), it works well.
But, excuse my ignorance, I don't know the type integer(7), google don't knows it too and also in the help of plato and in the doc files I can't find any explanation of integer(7).
Must I change all my handles from integer*4 (some are also integer*2 i.e. openf@, readf@ or writef@) to integer(7)?
Thanks for your help
Chemie
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Aug 22, 2016 11:16 am    Post subject: Reply with quote

The type INTEGER(7) is described in http://silverfrost.com/ftn95-help/devel/x64_compiler.aspx . Under "Differences between 32- and 64-bit Fortran", you can see the statement:

Quote:
64-bit Microsoft Windows HANDLEs are addresses (64-bit integers). So if a Windows handle is used explicitly in Fortran code, it will currently appear as a 32 (KIND=3) integer and must become a 64-bit (KIND=4) integer for 64-bit applications. FTN95 has a special KIND value (7) that is interpreted as KIND=3 for 32-bit applications and KIND=4 for 64-bit applications.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Aug 22, 2016 1:24 pm    Post subject: Reply with quote

You should be careful when searching the net for any statement like INTEGER(7) or others, like INTEGER(2) or INTEGER(4), as the values 7,2 and 4 respectively are all values of kind that are assigned by the particular compiler, which can arbitrarily be related to an integer precision.

FTN95 broke the mold many years ago, when they used kind values 1,2 and 3, then later 4, and recently 7, while most other compilers use values 1, 2, 4 and 8, which relate to the byte length of the integer variable.

many compilers will give a warning when using integer(4), to let you know that using the value of kind is not portable, which FTN95 clearly demonstrates.

INTEGER(7) is an interesting change in the way kind is used, which FTN95 is able to do, in that it refers to integer*4 for 32-bit and integer*8 for 64-bit. Unfortunately, I have often forgotten, and tried to use INTEGER*7. The resulting error message quickly reminds me of the mistake.

The main problem with the use of INTEGER(7) is to know which types of handles vary from *4 in 32 bit to *8 in 64 bit, as there are different (other) handles that do not change. We need a list of all routines and clearwin+ codes that use handles and a definition of what type of handle they are, ie if they are INTEGER(7) or if they are a supplied or returned value. It all gets very confusing if you stop coding clearwin+ for a while.

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Aug 29, 2016 11:03 am    Post subject: Reply with quote

Chemie

I have added a new routine PROGRESS_BAR@ for the next release that can be called before each call to DISPLAY_DIB_BLOCK@. For example...

Code:
c_external progress_bar@ "__progress_bar"(REF)
double precision fill
....
a=winio@('%10br&',fill,255)
....
call progress_bar@(fill)
call display_dib_block@(i1,i1,picture,xsize,ysize,i1,i1,xpic,ypic,func,mode,errcode)


At the moment PROGRESS_BAR@ is only linked to DISPLAY_DIB_BLOCK@ but there may be the potential to link it to other routines later.
Back to top
View user's profile Send private message AIM Address
Chemie



Joined: 07 Mar 2015
Posts: 49

PostPosted: Mon Aug 29, 2016 7:13 pm    Post subject: Re: Reply with quote

Paul,

thank you for progress_bar@, I can't test it now, I have to wait for the next release. But I think, display_dib-block@ is so fast, that I don't need a progressbar, on the other side, the loadingtime for get_dib_block@ (in some cases up to few minutes) or put_dib_block@ is more interisting for the use of progress_bar@.
Perhaps you can link progress_bar@ also to get_dib_block@ and put_dib_block@.

Thanks
Chemie
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 4 of 6

 
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