Author |
Topic: Cascaded ON CLOSE (Read 1404 times) |
|
Michael Hutton
Developer
member is offline
Gender: 
Posts: 248
|
 |
Re: Cascaded ON CLOSE
« Reply #9 on: Oct 8th, 2010, 12:37pm » |
|
I think I understood the code but surely this is still a ON CLOSE LOCAL solution. I am not sure I can see how to incorporate this code into a library which would take care of it's own clean up of objects it creates unless you ask the programmer to put their main program in a PROC (in this case PROC2) which the library calls. Hence if an ON CLOSE is detected in PROC2 the cascading clean up is performed.
As soon as you exit the PROC2 all the ON CLOSE LOCALs are 'forgotten'. Or yet again have I missed the point.
Michael
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Cascaded ON CLOSE
« Reply #10 on: Oct 8th, 2010, 3:17pm » |
|
on Oct 8th, 2010, 12:37pm, Michael Hutton wrote:| I am not sure I can see how to incorporate this code into a library which would take care of it's own clean up of objects it creates |
|
Sorry, I'm being a bit slow today (it doesn't help having a nasty cough for the last 7 weeks that won't go away). You'll have to explain what you mean in more detail.
As an experiment I've transferred PROC2 into a library, to simulate the situation you describe. There's nothing 'shared' between the library and the main prog as far as I can see (I've chosen a different error code and called PROCclose something different) and the main prog doesn't have to know that any 'local' CLOSE handling happens in the library. But it all seems to work as it did before.
Quote:| As soon as you exit the PROC2 all the ON CLOSE LOCALs are 'forgotten'. |
|
In what sense "forgotten"? If I move the WAIT code out of PROC2 and instead put it in FN1 after the PROC2 statement, a CLOSE still seems to be trapped at each 'level'.
Richard.
Don't put an apostrophe in ITS unless you mean IT IS: http://www.youtube.com/watch?v=Vc2aSz9Ficw
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: Cascaded ON CLOSE
« Reply #11 on: Oct 8th, 2010, 4:58pm » |
|
on Oct 8th, 2010, 12:37pm, Michael Hutton wrote:| I think I understood the code but surely this is still a ON CLOSE LOCAL solution. |
|
The title of this thread is Cascaded ON CLOSE so of course it's an ON CLOSE LOCAL solution, because that's what you need in that case! In the same way, the solution to the Cascaded ON ERROR problem is an ON ERROR LOCAL solution.
If you're asking about a situation where a library creates a global object, which then needs to be cleared up when the program is eventually closed, that's got nothing to do with cascaded ON CLOSE or ON ERROR handling, and is off-topic for this thread.
The solution to that issue is for the library to provide its own cleanup procedure that the user must call from the main program in his global cleanup code, typically activated from both his ON ERROR and ON CLOSE handlers. Many libraries have just that:
COMLIB has PROC_comexit
GDIPLIB has PROC_gdipexit
MDILIB has PROC_exitmdi
SOCKLIB has PROC_exitsockets
etc.
Richard.
|
|
Logged
|
|
|
|
|
