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!

Put

call TEMPORARY_YIELD@()

in the running code so that it executes regularly but not too frequently.

Regards

Ian

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

Quoted from IanLambley 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.

You need to include <windows.ins> or <clearwin.ins> will do.

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

Quoted from LitusSaxonicum 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!

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