forums.silverfrost.com

DanRRight · Last edited by DanRRight on Thu May 02, 2019 11:02 pm; edited 1 time in total

I got this message when implemented slider %sl which calls function SliderFunction. The demo is here, but this demo works fine, itis the main code which crashes

PaulLaidler · Posted: Thu May 02, 2019 8:36 am Post subject:

Dan

You may need to use a recent version of the ClearWin+ library in order to avoid the recursive element.

DanRRight · Posted: Thu May 02, 2019 11:01 pm Post subject:

OOps, i missed your PM. Will try new library, thanks

DanRRight · Posted: Fri May 03, 2019 12:54 pm Post subject:

Still crashing. But sometimes not. Demo above also works fine. I do not know what's to do. Interesting is that using the wheel %dd with %^rd which calls the same function works no problem

PaulLaidler · Posted: Fri May 03, 2019 1:26 pm Post subject:

I would need a sample program that demonstrates the failure before I could comment.

DanRRight · Posted: Thu Sep 05, 2019 7:28 pm Post subject:

Was not possible again to extract the demo and keep the bug. It took me a day and the extraction grew and grew till eventually to become not manageable. Plus the bug in demo disappeared.

This will be the lesson to all and myself: over time i added and added and added features and now even simple plotting program became unmanageable. Needs way way too much time to keep it working. Programming has to be like in Lego: small simplest possible block not dependent on one giant module far away. All initiations have to be just nearby.

So my question is : how to trick the compiler and make it to miss this error? Nothing bad will happen. The place where this happen is related to realtime mouse position control in the callback mouse_pos which is called thousands time when mouse moved

PaulLaidler · Posted: Fri Sep 06, 2019 7:48 am Post subject:

If a routine is being entered recursively against your wishes then you could put a SAVEd logical variable at the start of it. Set this .TRUE. on the first entry and exit immediately on reentry so that the routine is only executed at the first level.

SUBROUTINE sub(....)
LOGICAL,SAVE:: active
!!DATA statement to initialise active to .FALSE.
IF(active) RETURN
active = .TRUE.
!! Body of subroutine
active = .FALSE.
END SUBROUTINE

LitusSaxonicum · Posted: Fri Sep 06, 2019 8:05 am Post subject:

Or if you don't like SAVE, put it in a COMMON block.

Eddie

DanRRight · Posted: Tue Feb 15, 2022 6:35 am Post subject:

Unfortunately this " Run-time error 18 - This routine has been entered recursively" stops in debugger exactly on the line If(active) Return i.e. the error is generated before doing any IFs.

Is there any way to prevent this error to occur? At least temporally for debugging (and may be even permanently : Clearwin GUI has not to crash in this case. Things are that if you use slider, for example, and move slider fast, its callback might be executed many times while you slide. In this case some new call might happen while previous one is still not ended.

PaulLaidler · Posted: Tue Feb 15, 2022 7:56 am Post subject:

Perhaps you should look at the result of clearwin_string@( "CALLBACK_REASON") within your callback function.

This may tell you when to immediately return from the callback function rather than do other things that lead to the recursion.

DanRRight · Posted: Tue Feb 15, 2022 1:01 pm Post subject:

My impression is that the error is generated just by entering same function second time while first is not finished. This happens before any executable statements are attempted to run. Situation looks like a total screw up for any possible workarounds ... Sad

PaulLaidler · Posted: Tue Feb 15, 2022 2:05 pm Post subject:

It is possible to step through the callback on the first call using the debugger? If you know the point at which re-entry occurs, you may be able to avoid it.

DanRRight · Posted: Wed Feb 16, 2022 1:58 am Post subject:

I'm still not getting what this will do. The callback is permanently used when you use slider. The problem which i am describing is mostly takes place during debug because during debug the code runs 10-100 slower and overlap of callbacks can happen

PaulLaidler · Posted: Wed Feb 16, 2022 8:43 am Post subject:

If it runs OK when you are not using debug mode then you can put a PRINT statement into your failing callback function to print the value of clearwin_string@( "CALLBACK_REASON"). There may be "reasons" that need filtering out.

It seems unlikely that it fails in debug mode because it is running slower. Perhaps the compiler does not add checks for recursion in non-debug mode.

I hesitate to ask but what happens if you make the callback recursive?

DanRRight · Posted: Thu Feb 17, 2022 3:14 am Post subject:

Never used it. Will try...