|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Mon Oct 05, 2009 3:23 pm Post subject: How to know that graphics screen is closed |
|
|
Unfortunately graphics functions like
CALL DRAW_LINE@(ix1,iy1,ix2,iy2,icolor)
do not have handle and error message (*) so if you closed your graphics window and called such routines the program will crash.
Usually I do workarounds by opening graphics window %gr with a handle %hw and leave control %lw and using some manipulations tell the program not to do nasty things of self-termination if graphics window is closed.
But may be there exist better and easier ways to find if there is no graphics windows available?
------------------
(*) I mean having functions like
CALL DRAW_LINE@(ix1,iy1,ix2,iy2,icolor,ihandle,ierr)
would be ideal to simultaneously open and plot in several graphics windows without difficult logical trickery of switching graphics screens which eventually fail if you close one window
At least CALL DRAW_LINE@(ix1,iy1,ix2,iy2,icolor,ierr) has to be done so that subroutine does not crash the program |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Mon Oct 05, 2009 7:08 pm Post subject: |
|
|
What's wrong with IQ=SELECT_GRAPHICS_OBJECT@(iHandle)?
If you can't select it, there ain't no point in drawing to it! (Check the return code IQ)
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Mon Oct 05, 2009 11:30 pm Post subject: |
|
|
Yes it works, thanks for reminding me, I used it before but, frikin Altzheimer, just completely forgot
But would still be probably nicer (great if other folks and Silverfrost will comment) if such routines do not crash the code like in this simplest example
Code: |
use clrwin
ix1=1;iy1=1;ix2=10;iy2=10; kol=12
CALL DRAW_LINE@ (ix1, iy1, ix2, iy2, kol)
end
|
Crashing is so DOS FTN77-ish. I do not know how much slower will be routine after adding two more dummy arguments. But in this case we could open, say, a hundred graphics windows (like some codes are doing, QuoteTracker for example) just by writing one by one
i=winio@('%`^gr', lx1,ly1, ihandle1, cb1)
i=winio@('%`^gr', lx2,ly2, ihandle2, cb2)
i=winio@('%`^gr', lx3,ly3, ihandle3, cb3)
............
and inside callbacks simply calling graphics routines one by one without worrying about crashing, errors...
CALL DRAW_LINE@ (ix1, iy1, ix2, iy2, kol, ihandle1, ierr)
CALL DRAW_LINE@ (ix1, iy1, ix2, iy2, kol, ihandle2, ierr)
CALL DRAW_LINE@ (ix1, iy1, ix2, iy2, kol, ihandle3, ierr)
.........
...and without heavy thinking how to switch graphics windows to write graphics there
This is how it is done for example with text window %cw. You open them of different sizes and colors with different logical unit numbers
i=winio@('%50.10cw', lun1)
i=winio@('%50.10cw', lun2)
i=winio@('%50.10cw', lun3)
and then just write there without worrying about switching windows or crashing the code due to some stupid error
write(lun1,*,err=1) 'hello world'
write(lun2,*,err=1) 'hello world'
write(lun3,*,err=1) 'hello world' |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Tue Oct 06, 2009 11:02 am Post subject: |
|
|
Hi Dan,
There's nothing to stop you writing your own routine to which you pass the handle, and whatever other baggage you want. Me, I can do the mental gymnastics for one screen, maybe two, but after that I'll leave it for clever folks!
Regards
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Tue Oct 06, 2009 1:22 pm Post subject: |
|
|
I think that it would be fairly easy to provide additional routines but they would have to have new names.
I will look at the way in which these routines fail. Maybe there is a better way to solve the problem. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Wed Oct 07, 2009 9:47 am Post subject: |
|
|
I have had a look at this and there is no simple way to fix the library.
I was looking for a way to allow the program to continue to run but the internal coding of the library does not allow for this. For the same reason it would not help if you tried to trap the exception.
What is needed is a TRY and CATCH mechanism and this is not available for Win32 (i.e. not .NET).
There again I do not see how it would help to change the error reporting mechanism since this is normally a programming error that needs to be fixed during development. Otherwise Eddie's suggestion seems like a good idea. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Oct 07, 2009 10:39 am Post subject: |
|
|
Paul,
Thanks for looking.
I do agree with you that in every case I can think of it counts as a programming error that will need fixing. Quite properly, from your perspective, the error message and traceback information is a completely satisfactory treatment of the problem. From the perspective of Dan (or myself) - the error message and traceback information causes a sinking feeling in the stomach, and often an involuntary groan! These errors often arise when you are trying to fix something else, and it means more mental gymnastics trying not to let the fix for the new problem cause more difficulty in solving the original one.
I think that this is behind every request to be able to carry on regardless through what is properly a terminal error. Looking to see if the graphics object can be switched to is a "TRY and CATCH" system. If you know the graphics object isn't selectable, then writing to it is obviously an error.
I discovered that it was essential to do the test each time I started to draw something, but not for every drawing operation, because in my programs, the drawings are done quickly, and the chances of someone having the lightning reactions to close the graphics screen while drawing is in progress were miniscule. This may not be the case for some more complicated drawings, but I still don't see the need to check on the continued existence of the graphics object for every drawing operation.
Eddie |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Wed Oct 07, 2009 12:33 pm Post subject: |
|
|
I may have got hold of the wrong end of the stick, but what would happen if there was a dummy offscreen graphics area and this was the default selection when no other existed. You may have to select it using the appropriate function under program control. The graphics calls would never fail!!!!
Regards
Ian |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Wed Oct 07, 2009 3:20 pm Post subject: |
|
|
Ian,
You could always slip that in if the SELECT_GRAPHICS_OBJECT@ showed that the one you thought was there, actually wasn't. But that comes down to catching your own errors, not FTN95 catching them for you.
Eddie |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Thu Oct 08, 2009 3:35 am Post subject: |
|
|
Yes, thanks Paul if you will look at that. And think about this: imagine surgery simultaneously with tomography. You see slowly appearing picture and by mistake you click on wrong 'x' in the screen corner.
Program crashes...
Unacceptable!
Fortran is strict language and prefers to crash instead of doing something wrong. C++ would not notice and continue plotting to the screen in somewhere else surgery.
But lets not sacrifice strict fortran design and still do the job correctly and safely.
First, it would be nice that graphics library utilities at least never crash the code if it is possible. Second, that means adding one more parameter - the error message - the generated in the case of closing graphics object error message would help to resolve the problem (we have too many in complex codes). And third, with adding one more parameter, the handle, (everyone can omit them if additional graphics screens or error message are not needed), the simplicity for multi-object this approach is obvious: you write on specific graphics screen marked by the handle instead of always first do switching to a handle of graphics screen and then plotting. Right now with multiple graphics surfaces you are permanently switching graphics objects and in slow graphics like the surgery above the code will crash without checking each and every plotting operation if you close 'x' the damn screen.
In new approach, say, you have closed the graphics screen for some specific handle. First, it will never crash the code, then error message will inform you and you will or not close the screen, or stop plotting, or direct the stream to another graphics screen. Or routine will plot on some default graphics screen with handle = 0, and if it is not there then go to error message. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Thu Oct 08, 2009 7:58 am Post subject: |
|
|
One way to fix this problem in your code would be to wrap each block of drawing instructions in a IF construct of the form
IF(clearwin_info@("GRAPHICS_HDC") /=0)THEN
! call drawing routines here
ENDIF |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Thu Oct 08, 2009 9:51 pm Post subject: |
|
|
Nice one Paul, it's a clear alternative to SELECT_GRAPHICS_OBJECT@ - and a new one on me - but it begs the question as to what to do in the ELSE case. Dan wants the graphics to go somewhere. I just can't see why they should, if there is nowhere for them to go (no matter how vital it may be).
My problem was that a callback was happily getting ready to draw something on the main window, and the user closed that, so the graphics had nowhere to go. The solution was to find out they graphics object had disappeared, so then don't even try writing to it because the user obviously doesn't want it.
Dan's problem appears to be that he wants the graphics to appear whether or not he's got somewhere for them to be drawn. In my book, if it's that vital for them to appear, it's up to the programmer to create the graphics object in the first place.
Unless, of course, someone has an elegant solution to the ELSE case ....
Eddie |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Fri Oct 09, 2009 8:48 am Post subject: |
|
|
If the HDC turns out to be zero then you could create a %gr region in a new window before drawing to it. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2813 Location: South Pole, Antarctica
|
Posted: Fri Oct 09, 2009 6:29 pm Post subject: |
|
|
Are
clearwin_info@("GRAPHICS_HDC")
and
SELECT_GRAPHICS_OBJECT@ same things in terms of speed and usability?
in sumamry, right now we can compare such functions like
CALL DRAW_LINE@ (ix1, iy1, ix2, iy2, kol)
with fortran "PRINT *" with its default output device and no error handling while seems natural for Fortran to have also "Write(lun,format,err=)" type of graphics routine calls. This is why i'd like to see error and handle arguments added. User then can make Write(*,*) from it if he is very lazy by just omitting these additional dummy arguments. Adding them though, specifically a handle improve the code substantially, *making it actually much simpler* for multiple graphics screens. Simplicity is one of key properties why Fortran survived better then any other then mainstream C++ compilers. Clearwin is also kind of ultimate simplicity and probably even must be promoted as a default (for sure if it can be extended to Linux/Unix world) |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7916 Location: Salford, UK
|
Posted: Fri Oct 09, 2009 6:50 pm Post subject: |
|
|
Speed is not an issue in either case and both are simple to use.
I have understood what you would like and I have tried to explain why I am unable to supply it in this particular case. Sorry but even I have my limitations! |
|
Back to top |
|
|
|
|
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
|