![forums.silverfrost.com Forum Index](templates/subSilver/images/logo_phpBB.gif) |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Sun Jul 31, 2016 8:20 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sun Jul 31, 2016 10:39 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Mon Aug 01, 2016 7:13 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Chemie
Joined: 07 Mar 2015 Posts: 49
|
Posted: Mon Aug 01, 2016 10:17 am Post subject: Re: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Aug 02, 2016 12:00 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Chemie
Joined: 07 Mar 2015 Posts: 49
|
Posted: Tue Aug 02, 2016 5:05 pm Post subject: Re: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Aug 02, 2016 6:37 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Chemie
Joined: 07 Mar 2015 Posts: 49
|
Posted: Sat Aug 13, 2016 4:08 pm Post subject: Re: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Thu Aug 18, 2016 9:36 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Aug 19, 2016 1:46 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Chemie
Joined: 07 Mar 2015 Posts: 49
|
Posted: Mon Aug 22, 2016 10:02 am Post subject: Re: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Aug 22, 2016 11:16 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Mon Aug 22, 2016 1:24 pm Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Mon Aug 29, 2016 11:03 am Post subject: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Chemie
Joined: 07 Mar 2015 Posts: 49
|
Posted: Mon Aug 29, 2016 7:13 pm Post subject: Re: |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|