How to restore a text screen after wrecking a portion of it?

How to restore a text screen after wrecking a portion of it?

It is common in my applications (Quickwin) to interact with user via a "text screen" (actually a child window) in which all writing is done with coordinate control via OUTTEXT. Suppose at some key moment the screen is nearly full of text bits, scattered around. then, a text window is opened somewhere and new text is written (or a graphics window is opened and a chart is created), for temporary use. Then that window is closed. I can blank out the area using the original background color, but how can I restore the text that was originally there?

In our old DOS FORTRAN programs we accomplished this easily, exploiting hardware, by saving the current screen as a display page page 1 (say), then temporarily writing to display page 2, and then popping page 1 back on when done. ( We developed simple routines in Assembler to read and write directly to display memory pages, move contents from one display page to another, etc.).

How is this best accomplished now? I know I can save the entire screen to a big string array say CHARACTER(80) :: SCREENTEXT(25) if say there are 25 rows of 80 columns), force all permanent screen writing to go through this array, and rewriting the entire array whenever it needs to be restored. This is very cumbersome (and slow in Quickwin) and I'm hoping there is a better way.

10 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

Call the C routines as you would from a C/C++ program. The functions are still there, they are just harder to find with all the documentation pusing you to .NET or newer. You may need to make an interface should one not be available.

www.quickthreadprogramming.com

???

What was meant in the comment is that when a window is covered (overdrawn) and then uncovered, the opsys (Windows) automatically sends a message to the window's proc function to trigger a redraw of the entire window or possibly a region of the window. If your code explicitly includes proc function(s) for your program's windows and dialogs, then this activity will be a normal course of events in the multi-window Windows universe, happens all the time, no problem at all.

Since Quickwin masks all this activity, your code will somehow have to intercept and then act upon the WM_REDRAW messages, hence the reference to C routines (in the API). From a programming standpoint, you are attempting to achieve standard ordinary 1990-level GUI performance, but you are using 1980-level procedural code which piggy-backs on an abstraction layer which hides the real functionality, and you have now run up against one of the many limits of this approach. One solution would be to have your program subclass the desktop so that no other processes or applications could create GUI content to override your content, but the best solution would be to jettison the Quickwin and start writing complete native Win-API programs, which can be done as well and effectively in Fortran (especially IVF) as any other language. Good luck.

I am a bit confused about what you are doing. QuickWin manages its windows and should repaint any window that gets covered and then exposed.

QuickWin does support some functions you may find of use: SAVEIMAGE and LOADIMAGE.

Steve

Here are two more ideas. First, give your program's window the topmost attribute which will keep it from being overwritten. You wil need to know your window's handle, and USE IFWIN, but the code is simple:


SUBROUTINE Set_Topmost (hwnd)

    IMPLICIT NONE

    INTEGER(HANDLE), INTENT(IN)     :: hwnd

    INTEGER                         :: rval

    rval = SetWindowPos (hwnd,HWND_TOPMOST,0,0,0,0,IOR(SWP_NOSIZE,SWP_NOMOVE))

END SUBROUTINE Set_Topmost

A potential problem with this method is that system-modal error messages will now be beneath your program's window and may be completely hidden yet still have the Focus, so the computer will appear to be hung with no visual clue as to which process is waiting for input.

Here is another, even simpler solution: get a dual-monitor video board and set up the 2nd monitor to extend the desktop, then run your program on monitor #2, so other stuff will show up on #1 and not interfere.

I thank all for their responses, but I can see that I didn't explain the issue well enough.

By "wrecking a portion of the screen" I was not refering to it being covered up by stray "operating system windows." What I meant was, that it is my own Quickwin's program intent to do some temporary writing on a portion of the screen. This is done using the standard Quickwin routine SETTEXTWINDOW (R1, C1, R2, C2), for example to set a temporary window in the area row 10 to row 20 and column 20 to column 40, within the child window of rows 1 - 25 and columns 1 - 80. When this temporary area is no longer needed, I reset the text window using SETTEXTWINDOW (1, 25, 1, 80) but now I need to restore the text that was lost by overwriting by the temporary window.

Steve's suggestion of using SAVEIMAGE and LOADIMAGE may work--I will investigate that and report back here. Otherwise, I will establish my own software screen buffer as a character array.

Have you considered using a child window opened on a separate unit for this? You can then remove the window by closing the unit.

Steve

Yes, I have. But the temp window is very closely tied to the rest of the screen, for example, with arrows, and colon-ending prompts right up to the edge. A child window would get in the way, with its border and especially title bar, which no one wants to see. The textwindow feature offered by Quickwin gives the perfect appearance I'm looking for. If the background cannot be easily restored, I can live with it. It does give me another option to think about though (is there any way I can programmitically remove the status bar and title bar and minimize the border?)

btw I AM familiar with child windows; I have them popping up all over the place in my various programs. But it's not the effect I'm looking for in this one.

Even better than SAVEIMAGE and LOADIMAGE, I think, are GETIMAGE and PUTIMAGE. These are very similar, but the first two use a disk file to "buffer" the image while the second two use a memory buffer. So the speed of the second two is presumably much faster (I haven't tested), as long as you have enough memory (and who doesn't these days).

My initial testing so far indicates that this is an ideal solution to my problem. Very easy to use and very powerful. Thanks for the hint, Steve.

登陆并发表评论。