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 

How to know that graphics screen is closed

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Mon Oct 05, 2009 3:23 pm    Post subject: How to know that graphics screen is closed Reply with quote

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
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Mon Oct 05, 2009 7:08 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



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

PostPosted: Mon Oct 05, 2009 11:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
LitusSaxonicum



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

PostPosted: Tue Oct 06, 2009 11:02 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Oct 06, 2009 1:22 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Wed Oct 07, 2009 9:47 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
LitusSaxonicum



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

PostPosted: Wed Oct 07, 2009 10:39 am    Post subject: Reply with quote

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
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Wed Oct 07, 2009 12:33 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
LitusSaxonicum



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

PostPosted: Wed Oct 07, 2009 3:20 pm    Post subject: Reply with quote

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
View user's profile Send private message
DanRRight



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

PostPosted: Thu Oct 08, 2009 3:35 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Oct 08, 2009 7:58 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
LitusSaxonicum



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

PostPosted: Thu Oct 08, 2009 9:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Oct 09, 2009 8:48 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
DanRRight



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

PostPosted: Fri Oct 09, 2009 6:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Oct 09, 2009 6:50 pm    Post subject: Reply with quote

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
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
Page 1 of 1

 
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