Canceling W$PROGRESSDIALOG

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

Using the "W$PROGRESSDIALOG" routine does not present a Cancel button. If your UI contains a Cancel button associated with a Progress Dialog, all Push button controls have an Enable or Disable property, you can modify the button to Enable or Disable it.

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

Sorry Shjerpe,

I do not understand this.
"W$PROGRESSDIALOG provides access to the windows progress dialog box" (Manual) and the second parameter of the op-code "WPROGRESSDIALOG-CREATE" is a cancel-message.
Now, when using this routine, there is always a Cancel butten in the dialog box. How can I disable this Button?

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

My apologies. You are correct, using W$PROGRESSDIALOG does present a Cancel button. I believe in order to disable that button, we would need to go through the Windows API. I'll check with acoworker and see if they have any ideas.

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

That would be great.
Have a nice weekend.

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

One other suggestion, if the program never polls for the cancel then clicking on it will have no effect. An alternative is for you to use a frame control, fill color proprty and fill percent allow you to make your own progress indication (and no cancel button).

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

Hi Shjerpe,

the reason I prefer to use "w$progressdialog" instead of a custom routine is, that in a ThinClient environment during a elaborate processing routine which takes a long time, the runtime responds with "no feedback" when the user clicks with the mouse in the application window or makes any keyboard input. The process continues to run on the server, but the user thinks that the program hangs. If the timeout is reached, the server process is also terminated and this should not happen.

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

You may be able to avoid the screen going into the not responding state by adding one of these in your Runtime configuration file:
FILE_IO_PROCESSES_MESSAGES ON
FILE_IO_PEEKS_MESSAGES ON

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

Hi Doug,
I’ve tested these variants:

Menu-program
Call thread Program-1
…
Version 1
Program-1
Dialog Display/accept
Call subprogram-1
Version 2
Program-1
Dialog Display/accept
Call thread Sub-program-1 handle in thread-1-handle
Wait for thread-1-handle

Sub-program-1
All i-o routines ….
Perform until eof
Read my-file next …
Call program-with-my-progress-dialog
Do something

Both variants work in a normal environment, but in a thinclient environment the runtime always responds with "no feedback" after a mouse-click or a keyboard-input until processing is complete.
Both entries in the configuration file have no effect.

The Runtimeversion is 10.1

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

There may or may not be a way to disable the Cancel button from the runtime's point of view. We would need to do some research to determine what is possible. And how to expose that to a COBOL program. You should raise an official enhancement request, if this is something you really need.

But you really need to ask yourself why you would want to do this. Have you never been running a Windows application and seen a progress bar, and decided it was taking too long, and you wanted to cancel it? Or you realized that you did the wrong thing, and wanted to cancel? These are common scenarios, and forcing your user to wait through the process is not very friendly (in my opinion).

A better idea (though more work, undoubtedly) is to handle the cancel gracefully. This may require you to implement transactions (and a long-running process is not really best for using transactions around the entire thing, but ...) or some other way. But it would make your application that much better for your users.

I'm sure you have considered this. But I suggest reconsidering.

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

Hi rzack,

maybe you know this joke:
Father, I need a new exterior mirror.
Why do you need a mirror?
Because the glass is broken.
Why is the glass broken?
Because the car is on it ;-)

You're right, I do not have to disable the Cancel button.
In fact, it's a workaround. We have an application that allows the user to run multiple programs within the application simultaneously using threads in Extend. The User can therefore run a processing routine in one window and simultaneously work in another window.
In our case it is now so that an elaborate processing is executed, in which several vision files are changed. Transactions can not be used because this happens in a multi-user environment and the files can not be locked.
Unfortunately the runtime in the Thinclient environment goes into the not responding state. For the user, it is no longer recognizable that the processing continues. The advantage of "w$progress" is that the runtime on the server corresponds further with the dialog window and shows the user the status of the processing.

The real problem is to prevent the "not responding state".
But as long as I have no possibility for it I use the workaround.

Shjerpes solution suggestion, wprocessdialog-query-cancel simply not to query is certainly a possibility to make the workaround more beautiful.

Good Morning,

is there a way to disable the cancel button or to prevent canceling the w$progressdialog?

 

dkl

Randy,
Another example would be our file conversion programs. These can NOT be cancelled b/c they are run after the new programs are already in place (cancelling would cause a 39 error when accessing the file without doing the conversion). In order to provide status and minimize slowdown (creating our own COBOL status window slows down processing while the screen is updated), we use W$PROGRESSDIALOG. We have a cancel message that says "This process cannot be cancelled". But isn't that a bit ridiculous, from an end-user perspective? Why show a cancel button if the process can't be cancelled?

-Chris