|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Thu Oct 01, 2015 4:47 pm Post subject: "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"? |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Fri Oct 02, 2015 10:02 am Post subject: |
|
|
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Fri Oct 02, 2015 10:09 am Post subject: |
|
|
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 |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Oct 02, 2015 1:03 pm Post subject: |
|
|
Perfect! Thanks, Eddie! |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sat Oct 03, 2015 4:40 pm Post subject: |
|
|
To my astonishment there's also:
SUBROUTINE TEMPORARY_YIELD@()
Eddie |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sat Oct 03, 2015 4:54 pm Post subject: |
|
|
Amazing what is lurking in the depths of the HELP files! |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Thu Oct 08, 2015 3:08 am Post subject: |
|
|
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Thu Oct 08, 2015 1:24 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Fri Oct 09, 2015 3:25 am Post subject: |
|
|
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) |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sun Oct 11, 2015 12:42 am Post subject: |
|
|
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 |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2556 Location: Sydney
|
Posted: Sun Oct 11, 2015 1:38 am Post subject: |
|
|
Eddie,
No clearwin function, I just draw the text. Code: | subroutine message_report (string)
! use mswin
include <clearwin.ins>
include <JDC_menu.ins>
!
character string*(*), message*50
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 |
|
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sun Oct 11, 2015 9:06 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Mon Oct 12, 2015 1:57 pm Post subject: |
|
|
Deleted!
Last edited by IanLambley on Mon Oct 12, 2015 2:03 pm; edited 1 time in total |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Mon Oct 12, 2015 1:57 pm Post subject: |
|
|
Eddie,
I put up a status window with several lines in it and output several messages during an analysis:
Code: |
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 |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Mon Oct 12, 2015 8:10 pm Post subject: |
|
|
Ian,
A neat example, but one that doesn't use %ob[status], even if it does employ the yield_scurvy_knave@ routine.
Eddie |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|