 |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
Little-Acorn
Joined: 06 Jul 2008 Posts: 111 Location: San Diego
|
Posted: Sun Jul 27, 2008 4:34 am Post subject: Two processes running at once? |
|
|
Don't know if that's a good way to describe what I'm trying to do here, but it's probably close. I'm using FTN95 with Win32.
I have a window up with several edit boxes displaying variables, and several buttons. One button says RUN, if you click it a process starts running that occasionally changes some of the variables, updating periodically. It works well, you can see the variables changing in the edit box little windows, just as they should.
Another button in the same window says STOP. If you click on that, it's supposed to change a certain status variable from 1 to 0. The process that's running from the RUN button, constantly checks that status variable, and if it sees a 0 there it will stop. In theory, anyway.
Problem is, once you click the RUN button, that process starts running, and the entire window it came from, locks up, except for the little edit boxes showing the variables updating as I described. But the menus and buttons - including the STOP button, suddenly don't work any more,and stay dead until the process stops of its own accord (I have it expiring after 100 steps). So I can't use the STOP button to stop the process that the RUN button started! (Before I put the 100-step limit in, I had to hit Ctl-Alt-Del and use the process manager to abort the process, yikes!)
I get the feeling this system doesn't like to have two processes ruinning at once: The first process started by the RUN button, and the quickie that the STOP button triggers, just resetting a variable and returning. Is this so?
Does anyone know a way I can keep the other buttons in the window active after the RUN button has started its process going? Or some other way to interrupt that process?
Thanks again, all! |
|
Back to top |
|
 |
IanLambley
Joined: 17 Dec 2006 Posts: 506 Location: Sunderland
|
Posted: Sun Jul 27, 2008 8:57 am Post subject: |
|
|
Put
call TEMPORARY_YIELD@()
in the running code so that it executes regularly but not too frequently.
Regards
Ian |
|
Back to top |
|
 |
DanRRight
Joined: 10 Mar 2008 Posts: 2927 Location: South Pole, Antarctica
|
Posted: Sun Jul 27, 2008 11:46 am Post subject: |
|
|
Little-Acorn, Look at last two-three weeks messages, we are duscussing this issue now.
I know two ways to make all Run-Pause-Stop snippets working, spending on that a month of my life ten years ago, but they are not clear and nowhere intuitive. So I hate both of them and am trying now to make progress in finding simple, clear, natural, non-restrictive and intuitive method. Hopefully multithreading will work with contribution from everyone here.
I still did not see published reliable solution for start-pause-continue-stop code with allow_another_callback or temporally_yield or something else. It is miracly possible and it works fine if we open additional window and will keep it open, but it is not what is needed
Last edited by DanRRight on Sun Jul 27, 2008 11:05 pm; edited 1 time in total |
|
Back to top |
|
 |
Little-Acorn
Joined: 06 Jul 2008 Posts: 111 Location: San Diego
|
Posted: Sun Jul 27, 2008 5:06 pm Post subject: Re: |
|
|
IanLambley wrote: | Put
call TEMPORARY_YIELD@()
in the running code so that it executes regularly but not too frequently.
Regards
Ian |
Ian, from the help files these sound like the solution. Thank you!
But I may have forgotten to include a library somewhere. When I call this routine (or others like PERMIT_ANOTHER_CALLBACK@ etc.), I get a compile-time message saying "WARNING the following symbols are missing: TEMPORARY_YIELD# " ... with a pound sign where I had put an at-sign. Happens with several of these related routine names.
Is there a fix for this? Maybe just include the right library? The HELP files mention no such library outside of WINAPP and INCLUDE <windows.ins>, which I already have. |
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8217 Location: Salford, UK
|
Posted: Mon Jul 28, 2008 2:53 pm Post subject: |
|
|
You need to include <windows.ins> or <clearwin.ins> will do. |
|
Back to top |
|
 |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2403 Location: Yateley, Hants, UK
|
Posted: Mon Jul 28, 2008 4:14 pm Post subject: |
|
|
Just a thought - you do have INCLUDE <WINDOWS.INS> in every subroutine and function that does ClearWin stuff, don't you? It's not a once-in-a-program solution ...
(The contents of the INCLUDE files are all declarations, and declaring them in one routine doesn't declare them everywhere, at least not in Fortran-77 style programming. You may be able to do it with a MODULE).
Eddie |
|
Back to top |
|
 |
Little-Acorn
Joined: 06 Jul 2008 Posts: 111 Location: San Diego
|
Posted: Wed Jul 30, 2008 5:55 am Post subject: Re: |
|
|
LitusSaxonicum wrote: | Just a thought - you do have INCLUDE <WINDOWS.INS> in every subroutine and function that does ClearWin stuff, don't you? It's not a once-in-a-program solution ...
(The contents of the INCLUDE files are all declarations, and declaring them in one routine doesn't declare them everywhere, at least not in Fortran-77 style programming. You may be able to do it with a MODULE).
Eddie |
BINGO, Eddie, this was the problem! I put an additional INCLUDE <windows.ins> into the routine that was not responding to the button push, and now it lets me push the button. I will continue to add that statement to routines if/when needed - I don't see a need to just jam it into every one of the routines, of which there are 20+ and increasing daily. Now I'll try to juggle the adding-subsequent-call@ commands and see if I can make this thing make sense.
Thank you so much, all! Your help and advice is very valuable! |
|
Back to top |
|
 |
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2403 Location: Yateley, Hants, UK
|
Posted: Wed Jul 30, 2008 11:02 am Post subject: |
|
|
Windows.ins actually contains 3 more INS files, i.e.
INCLUDE <CLEARWIN.INS>
INCLUDE <WIN32API.INS>
INCLUDE <WIN32PRM.INS>
and the chances are you don't need all of them - and sometimes you don't need any of them. If you have a slow computer you might be able to get away with only (say) the first, although I find including Windows.ins many times doesn't slow compilation unacceptably.
Sooner or later, you are going to need something that is in one of the other INS files ... there are lots more of them in the INCLUDE folder.
The callback system does generate lots of extra subprograms. I find it convenient to use multiple source code files.
Eddie |
|
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
|