Software Archive
Read-only legacy content
공지
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
17060 토론

Console painting over Quickwin window

mroczek
초급자
566 조회수
For convenience and safety I launch an old Fortran ?legacy? console program from my Quickwin application using the techniques previously discussed in this forum and in the samples (using createprocess etc). It all works very well except that if the user moves the console window about the desktop the Quickwin windows are painted over by the console window so that there appear to be numerous copies of the console window pasted all over the Quickwin windows. Once the console app terminates the Quickwin application releases the console handle for the process, the console window copies all disappear. However I can?t close the process handle prematurely (i.e as soon as the process is launched) as it needs to passed to ?waitforsingleobject? and ?getexitcodeprocess? routines. Any ideas of how to get around this?

Thanks for any assistance

Ed
0 포인트
2 응답
Jugoslav_Dujic
소중한 기여자 II
566 조회수
Well, you can't have'em both...
When you start the .exe using that mechanism, the calling
application gets blocked, which includes also updating its
window. These things tend to happen when an application
invokes a long-lasting process from its main thread... this
happens for example, to Word during a long AutoSave or
VisualStudio upon saving a large Workspace.

The "right" way to launch a long-lasting process is to create
it in a separate thread and to ensure that nothing harmful
may happen in the calling process (i.e. disable menus, mouse
actions which may affect the program state etc.), while keeping
the calling process unblocked.

Luckily, the QuickWin already has two threads: in the
"secondary", PROGRAM (and subroutines called from it) are
executed; in the "primary", mouse and menu clicks are
handled, along with window updating (and lot of other things
hidden beneath the surface). If you put CreateProcess...
in a, say, menu callback, you block the "primary" thread.
Instead, define a global flag called, say, "bExecProcess"
and put something like the following in the endless loop
at the PROGRAM end:

 
DO WHILE (.TRUE.) 
    IF (bExecProcess) THEN 
        !TODO Disable menus and whatever else necessary here 
        hProcess = CreateProcess... 
        iSt = WaitForSingleObject... 
        bExecProcess = .FALSE. 
    END IF 
END DO 


and, in the menu callback subroutine, just set
the value of bExecProcess to .TRUE.

HTH

Jugoslav
0 포인트
mroczek
초급자
566 조회수
Jugoslav, Yes that was the problem. I was calling Createprocess from a menu callback function. Now I only set up some parameters in the callback and call createprocess in the main program.

Your help was much appreciated.

Ed
0 포인트
응답