Skip to main content

[archive] Thread appllication?

  • May 23, 2007
  • 9 replies
  • 0 views

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.

9 replies

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
I do not know if threads will help, but one thing that I try to do is, when updating a thin client screen, only update every so often. Update every 10 or 20 records instead of every record.

Another option is to use a frame and fill it incrementally achieving the look of a progress bar. We have an application where we get the total number of records from a work file, because we are getting information from several files. We then use that record count and some calculations to update the screen - at most - 100 times. This gives the all important feedback, but does not cause any timeout issues.

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
Did you use file_io_process_messages

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
@vmc
We did not.

When we built the work file, we used a difference in the dates that the customer specified to get the first total number and the counter that we were incrementing while building the work file for the second number. So if we had a difference of 22 days, we would only update 22 times for the first half of the 'progress bar'. The second number was used for the progress of the second half of the 'progress' bar and represented the transfer time. This worked very well as it incremented as quickly as it took to transfer the data to the client machine to build the list box that we were displaying the final data in.

If the person needs to see the total number of records, you can display the final number at the end - after reading through the entire file. Using a status bar seemed to work best for us in this instance as our customers may be connecting over a dial-up connection, and this screen could display a pretty large number of records.

We used the reasoning that if you throw too many updates over the network connection, timeouts could occur? Were we correct?

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.


Yeah it will help I think.
What we've found which also helps is on the screen which displays your record count have a push button.
Thin client sees the push button, knows it might be pushed and stopped areas of our application from getting "Remote hosts has stopped responding"

I can provide a small sample if you wish.

Shaun

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
Similar to what vmc suggests, we had this problem and used the FILE_IO_PEEKS_MESSAGES environment variable to resolve the problem.

Rob

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
Shaun:
Yes, a sample program would be great, Thank you,
Mike

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
Ok Mike,

This particular example is a from a stock movements report program so it could and probably will be reading thousands of records.
It allows the program to be aborted by the user and stops the thin client from thinking the program has stopped responding.

Screen attached, and we do have other examples which display a record count or a record key as it processes, but same type of screen.
The message is normally displayed in the status bar if we do this.

On the exception command clicked we have
*
Screen1-Pb-1-Ex-Cmd-Clicked.
SET WS-ABORT-YES TO TRUE
SET EXIT-PUSHED TO TRUE
.

In our print routine we have
IF WS-ISM-FND
PERFORM THREAD Acu-Screen1-Routine
HANDLE WS-ABORT-HANDLE
PERFORM MAIN-LOOP THRU MAIN-LOOP-EXIT
UNTIL WS-ISM-NOT-FND
IF WS-ABORT-NO
PERFORM PRINT-TEMP-FILE
END-IF
END-IF

Just after the read of the next record, we check the WS-ABORT-FLAG and exit if need be.

Seems to do the trick for us anyway and allows the users to do drag the screen around if they really feel the need to.
Also, they can switch over to other applications whilst the program is processing, come back again without the grey screen and impending feeling that the program has gone into a loop.

Shaun

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
thanks, this will help a lot,
Mike

[Migrated content. Thread originally posted on 22 May 2007]

I have programs which read large amounts of data. I do a display of record counts so the user can see the program is progressing. However if the user clicks outside outside of the window, (checking email, etc). my program window seems to lose focus and the display of the record counts do not show on the screen. The background turns white. The user assumes the program has stopped and terminates it using task manager. Even if the user does not click the mouse during the procedure, the same thing happens after a length of time. Can the use of "threads" prevent this behaviour and if so can someone please provide me with a small sample of code since I do not understand and have never used the thread command.
I haven't read the entire thread, but the same thing happeded to me while displaying status bars etc. just before processing I have the following:

set environment "FILE-IO-PROCESSES-MESSAGES" to 1.

and after processing is finished I set it back to:

set environment "FILE-IO-PROCESSES-MESSAGES" to 0.

This solved it for me, you may have different results, the one side effect of doing it this way, is you have no way of allowing the user to abort the processing function midway...