Re: Screen flashing

Jack Parker <jparker@hpbs2561.boi.hp.com> writes: -> ->Quoting Walt Hultgren. ->> ->> Just saw your posting on screen flashing. I noticed something like that ->> when I was doing an app in 4.1. We had gone from ".03" to 4.1, skipping 4.0. ->> I thought my problem might be related to the fact that the functions in -> ^^^^^^^^^^^^^^^^ ->> question used the RUN statement. It didn't make that much difference in -> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ->> that particular program, so I just let it go. ->> -> ->Ok, now that Walt has pointed this out.... Is there a fix? ->_____________________________________________________________________________ ->Jack Parker - Contractor | ->Hewlett Packard, BSMC Boise, Idaho, USA| "Excuse me, do you ->jparker@hpbs2651.boi.hp.com | have a jack?" ->(208) 323-5388 (W) (208) 384-1623 (H) | ->_____________________________________________________________________________ -> Alan Popiel <alan@den.mmc.com> comments: There may be a fix, but it may be in the "too hard" category. The flash seems to be caused by UNIX temporarily taking control of the screen when it spawns the task created for the RUN. UNIX wants the screen in case the task writes to stdout or stderr. One fix might be to modify UNIX (i.e., the "too hard" part) to not assign stdout and stderr until they are actually written to, instead of as soon as the task commences. This "defered open" option should get rid of the flash, but it might also conflict with some standard UNIX way of doing things. (Where is Dennis Ritchie, now that we need to ask him a question?) I have tried redirecting the stdout and stderr to /dev/null, but this did not seem to help. The "standard way of doing things" may be that the flash is caused by UNIX "packing up" the parent task's stdout (screen) so that is available for the child task's stdout, etc. (Dennis, where are you???) SO-O-O, the "too hard" part gets even harder, since now we need a "defered pack-up" as well as a "defered open". Something that seems to reduce, but not entirely eliminate, the flash is to RUN the child task in the background; i.e., to put "&" at the end of the command line passed to the RUN command. By the way, I never had this problem when RUNning commands on a DOS station. Apparently, MS-DOS is less protective of the parent task's screen, which is fine unless the child task actually does write to the screen. (Mine didn't.) However, Informix was kind enough to provide the ^R screen repaint; so even if the PC screen gets garbled by the child task, it's easy to clean up. Regards, Alan +------------------------------+---------------------------------------+ | R. Alan Popiel | Internet: alan@den.mmc.com | | Martin Marietta, LSC | ( Please note: My opinions do not ) | | P.O. Box 179, M/S 5422 | ( represent official Martin policy. ) | | Denver, Colorado 80201-0179 | Voice: 303-977-9998 | +------------------------------+---------------------------------------+