\"Not Responding\" - how to prevent

I have a ClearWin window that remains on-screen while the program goes off and does lots of things. Normally, I wouldn't mess with it, but yesterday I tried to move the window out of the way.

The text '(Not Responding)' was added to the caption (first) and then the screen ultimately turned whiter. The window refused to be moved. This lasted until the task was done and normal processing resumed. I should mention that as the task is running, it is reporting its progress to the window so the user doesn't think the program is stuck.

In running some additional trials, it would appear that clicking the mouse anywhere in the window or typing while the window has focus has the same effect.

There's too much other code involved to post here.

I was wondering what the root cause might be and what steps others have taken to prevent this from occurring with their code. Or, should I just live with it and post a dialog box and say 'Please wait until this process is completed'?

I think the answer lies in the remainder of the program going off and doing something on its own.

From time to time, your numerically-intensive routine needs to use this:

SUBROUTINE YIELD_PROGRAM_CONTROL@(OPTION) INTEGER OPTION

so that the message loop is examined.

Regards

Eddie

PS. Partway through typing the answer, my cat scratched at the study door. If I'd refused to be interrupted, he would have experienced a 'Not responding' state. As it was, I stopped typing and went and fed him. Thus, I was in a YIELD_PROGRAM_CONTROL@ (Y_TEMPORARILY) state! Typing the reply took longer than I intended, but it was still fast enough.

There are other solutions. One is to make the windows completely independent processes, the other is to make sure that windows only 'go off and do' relatively short-duration tasks.

Eddie

Perfect! Thanks, Eddie!

To my astonishment there's also:

SUBROUTINE TEMPORARY_YIELD@()

Eddie

Amazing what is lurking in the depths of the HELP files!

Using SUBROUTINE TEMPORARY_YIELD@() can date your program.

My graphics program, which I have been adapting since late 70's has this in many of the drawing loops. ( Those who remember the phosphorous green screens will understand) Back then, it was necessary to provide an interrupt test about every second of processing. Now with the code running about 10,000 times faster, some of these call tests have been removed or ignored. (one of those update projects that get ignored)

You need to judge what you want to interrupt and how frequently it should be done. I find that with new code it is easier to know what is causing the problem and wait for the process to complete. If you write your own code, it is a bit more tolerable than when it happens with Excel and you don't have a clue when it may finish !

John

John,

Nevertheless, it is the answer to the problem originally complained about.

I don't use it because my programs' reactions to any command execute too quickly to want to interrupt, and indeed, if I was running something that took a long time I'd put it on a dedicated computer - and that's just in the shed at the end of my garden where I have a choice of 9 or 10!

For something that takes a long time then a progress bar is useful, or periodic reports as to where the calculation has got to. I find the eggtimer, or the rotating wait cursor to be least useful, as they don't tell you if it is worth going off and doing something else.

Eddie

For my %gr window, I draw a border which includes a text area in the bottom left, where I try to keep updating the run status description of what is being done. The aim is to provide sufficient messages to indicate that progress is being made. It can be the type of calculation, if there are stages to the processing or a % complete for a longer calculation. Knowing that some progress is being made is better that the worrying (Not Responding) indicator at the top. The problem with interrupting at a temporary yield is that it is difficult to continue the calculation. (more complex coding)

Hi John,

That's an interesting suggestion. You can get things on a status line, but I've looked for the Clearwin+ code and can't find it (I don't use it) - the only link I can find is putting %he help info the status line at the bottom of the screen.

Eddie

Eddie,

No clearwin function, I just draw the text. subroutine message_report (string) ! use mswin include <clearwin.ins> include <JDC_menu.ins> ! character string*(), message50 integer*4 xs,ys, nc ! call journal_report (string) ! ! clear message area call draw_border (1) ! ! write new message message = string xs = 12 ys = w_depth-10 call select_font@ ('Arial') call draw_characters@ (trim (message), xs, ys, rgb@ (255,0,0)) ! call perform_graphics_update@() ! end subroutine message_report

Hi John,

Yes I realised what you were doing, and thought it was a great idea, just that Clearwin has a status line facility that I couldn't find. However, a bit more searching found it: put the outputs in an %ob[status] box!

Eddie

Deleted!

Eddie, I put up a status window with several lines in it and output several messages during an analysis:

      CHARACTER*70 LINE
      common/status_text/line(12)
c
c create a function for the 'Halt' button to exit the calculation
      integer*4 halt
      external  halt
.
.
      ipct = 0
c Write out percentage complete to window caption  repeat next two lines as required in calc loop
      write(anal_stat,7612)ipct
      call window_update@(anal_stat)

c put up the status window
            icontrol = -1
 7612       format('Analysis Status',i4,'%')
            ia=WINIO@('%ca@%es%^tt[Halt]&',anal_stat,halt)
            ia=WINIO@('Case:%`4rd %`rs&',jcase,curr_name(:64))
            ia=WINIO@('%ffMode :%ta%`rs&',an_mode)
            do i=1,12
              line(i) = ' '
              ia=WINIO@('%ff%`rs&',line(i))
            enddo
c      ia=winio@('%ww[no_maxminbox,no_sysmenu,topmost,no_border]&')
            ia=winio@('%ww[no_border]&')
            ia=winio@('%lw',icontrol)
          endif
c
c start calculation

c periodically in calc to allow 'Halt button to be pressed.
          call yield_program_control(Y_TEMPORARILY)
c
c output to status window at each calc stage
          call log_comment('Message text as required')



c end calculation - destroy status window
          icontrol = 0
          call window_update@(icontrol)
          end


      subroutine log_comment(text)
      CHARACTER*70 LINE
      common/status_text/line(12)
      character*(*) text
      character*11 etad
      character*8 emit
      integer*4 winio@
      do i=2,12
        line(i-1) = line(i)
      enddo
c
c get date and time for display with comment
      call calndr(etad,emit)
      write(line(12),100)emit,text(:min(len(text),57))
  100 format(1x,a,2x,a)
      do i=1,12
        call window_update@(line(i))
      enddo
      end

This is just a stripped out version not tested and some obvious include <windows.ins> or use statements missing Regards Ian

Ian,

A neat example, but one that doesn't use %ob[status], even if it does employ the yield_scurvy_knave@ routine.

Eddie