| View previous topic :: View next topic |
| Author |
Message |
DanRRight
Joined: 10 Mar 2008
Posts: 2780
Location: South Pole, Antarctica
|
 Posted: Thu Feb 17, 2022 3:58 pm Post subject: |
 |
|
| Thanks for the idea. Looks like this is the way to go, all callbacks related to mouse movement seems now always have to be recursive ! |
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7781
Location: Salford, UK
|
| Posted: Thu Feb 17, 2022 4:49 pm Post subject: |
|
|
That is why I hesitated. Making the function recursive provides a work-around for a fault in the Fortran code but it really should not be necessary.
Perhaps you could use RECURSIVE in this particular context and when debugging but in general you don't want to be entering callbacks recursively. |
|
| Back to top |
|
|
jalih
Joined: 30 Jul 2012
Posts: 196
|
| Posted: Sun Feb 20, 2022 6:56 pm Post subject: |
|
|
Hi Dan,
Any chance you could post code for the mouse_pos callback? If your callback doesn't call itself, it should not be recursive. It really should not matter how many times it get's called. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2508
Location: Sydney
|
| Posted: Mon Feb 21, 2022 3:57 am Post subject: Re: |
|
|
| DanRRight wrote: | | 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 ... :( |
This does not imply recursion, but multiple interupt initiations. (which are multiple threads? or at least act like multiple threads.)
For this reason, it is best to compile this routine as recursive, so that all local variables are on the stack and not static allocations.
I have experienced having multiple mouse click responses being analysed, before the previous has completed it's computed response.
So the response to the interupt has to be careful that further diagnosis gets the state related to this interupt and not later interupts.
Mouse movement tracking can generate interupts faster than they can be processed.
This is my interpretation of these many interupts, but may not be correct.
John |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2508
Location: Sydney
|
| Posted: Mon Feb 21, 2022 12:28 pm Post subject: Re: |
|
|
| DanRRight wrote: | | 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 ... :( |
This does not imply recursion, but multiple interupt initiations. (which are multiple threads? or at least act like multiple threads.)
For this reason, it is best to compile this routine as recursive, so that all local variables are on the stack and not static allocations.
I have experienced having multiple mouse click responses being analysed, before the previous has completed it's computed response.
So the response to the interupt has to be careful that further diagnosis gets the state related to this interupt and not later interupts.
Mouse movement tracking can generate interupts faster than they can be processed.
This is my interpretation of these many interupts, but may not be correct.
My solution was to find ways of processing the response more quickly, especially for mouse move interrupt, where I tested if the movement was less than a few pixels, then to ignore and return from the interupt. |
|
| Back to top |
|
|
DanRRight
Joined: 10 Mar 2008
Posts: 2780
Location: South Pole, Antarctica
|
| Posted: Tue Feb 22, 2022 4:57 pm Post subject: |
|
|
Jalih, John,
The damn thing is large and over 20 years old lifespan became spaghetti-like, so it is not possible to make a demo. May be indeed it is somehow calling itself via some other related calls. But just one additional word "integer recursive function" instead of "integer function" solved the problem.
I became not very careful programmer with Clearwin part of the code because even if i am totally wrong and violate all possible Fortran rules, until now this never hurted my main Fortran code, so i do not really care much till Clearwin refuses to work. Essentially the mess in my code not yet reached critical point. Only one of my property sheets reached it, but i hope to send it some day to Paul to find the bug (i still have a workaround for it)  |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
