Author Topic: Please Wait negates ability to have a Cancel Button  (Read 7221 times)

0 Members and 1 Guest are viewing this topic.

Offline RonB

  • Newbie
  • Posts: 14
    • View Profile
Please Wait negates ability to have a Cancel Button
« on: February 12, 2019, 02:18:03 pm »
I have an Inform Application that runs for quite a while, and would like to have a Cancel Button enabled for the user to stop the process at any time. I have no problem creating and displaying the Cancel Button, but unfortunately it cannot be clicked, because the entire window is darkened and overlaid with a "please wait" message.
Is there some way to either prevent the "please wait" or enable a button in the window whenever it is appropriate?

Thanks

Ron

Offline Pete

  • Forum Resident
  • Posts: 2361
  • Cuz I sez so, varmint!
    • View Profile
Re: Please Wait negates ability to have a Cancel Button
« Reply #1 on: February 12, 2019, 02:35:41 pm »
Please wait...
Want to learn how to write code on cave walls? https://www.tapatalk.com/groups/qbasic/qbasic-f1/

FellippeHeitor

  • Guest
Re: Please Wait negates ability to have a Cancel Button
« Reply #2 on: February 12, 2019, 02:55:57 pm »
Hello.

You probably have a do/loop block that's hogging InForm's own update routines. If that's the case, add a call to __UI_DoEvents in your loop and all should work as expected.

Offline RonB

  • Newbie
  • Posts: 14
    • View Profile
Re: Please Wait negates ability to have a Cancel Button
« Reply #3 on: February 12, 2019, 04:58:27 pm »
That does work, but means, in at least one "real world" invocation, over 10,000 calls to the __UI_DoEvents routine (if the app runs to completion), just to support the ability to cancel the program after, say, 5000 iterations of the loop.
And lest you wonder: there are, of course (thanks to Inform), several visual clues as to the application's progress: there is a count-DOWN counter showing how many iterations remain, there is a nice green progress bar, there is a count-UP counter as to how many "hits" have resulted, and there is a display that is constantly updated showing what the application is currently evaluating.
To be honest, though, the extra calls don't slow the process down THAT much. :-)

Ron

FellippeHeitor

  • Guest
Re: Please Wait negates ability to have a Cancel Button
« Reply #4 on: February 12, 2019, 05:28:46 pm »
Good to hear it's solved. Curious for your interface now!

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Re: Please Wait negates ability to have a Cancel Button
« Reply #5 on: February 13, 2019, 05:06:04 am »
Ron, glad to hear that you're using the marvellous resource that is InForm.

Offline RonB

  • Newbie
  • Posts: 14
    • View Profile
Re: Please Wait negates ability to have a Cancel Button
« Reply #6 on: February 13, 2019, 08:46:14 pm »
The utility, which I will upload some day (sooner if anyone shows interest), uses several of the Inform tool widgets: Buttons, Labels, Textboxes, Checkboxes, Radiobuttons, Frames, and Progressbars, and hides/displays them (including the main form, itself, at times) depending on what processing is taking place.
The utility's purpose is to compare selected file types (e.g. *.bas, *.cpp, *.txt) between two different Windows folders - including matching sub-folders, if requested, and with options to exclude specific files (using wildcards) or subfolders. Files being compared  that exist in both main, or matching sub-folders, will be compared taking specified options into consideration - e.g. file contents or attributes only; case sensitivity option, column limits option, whitespace options, line terminator options, etc. ). For each matching filename pair, the first difference will be logged, along with the line number and offset at which the mismatch was found. If requested the names of compared files and/or added/deleted files will also be logged.
I use the utility to compare original and work-in-progress version folders to verify that all changed/added/deleted elements have been accounted for. For my purposes, a difference in file dates is not significant (e.g. I could have made, then reversed, a change in the w-i-p  folder).
For a recent run, I compared two versions, each of which contained over 30,000 files, of which only about 7,000 in each met the file filters (included file-types,  excluded folders). The utility ran for about 6 minutes and identified 38 changes, plus a fair number of additions/deletions.
I wanted the "Cancel" button available in the event that  I noticed that the utility was "taking a long time" in a particular subfolder or on a particular file-type that I should have excluded in the filters. since they were not relevant. Without the excluded subfolders the utility would run twice as long (and I run it several times a week).