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).

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

Sorry, I can't resist...
The (16-bit) Integer Minimum Value should be -32768 not -32767. Prove it yourself:
a% = -32767
PRINT a% ' will show -32767
a% = a% -1
PRINT a% ' will show -32768
a% = a% -1
PRINT a% ' will show (positive) 32767 as it should

On another note, I once REMOVED around 23K lines of code from a program without affecting any functionality - and it wasn't "dead" code, either. I merely changed thousands and thousands of very "similar" code blocks that used hard-coded values into just couple of dozen subroutines that used variables passed on the Calls instead. Even so, the resulting program still had over 40K lines of code left.

(Too) many moons ago, in a land far, far away (Burrough's B-263 mainframe with 12K of memory, 1 tape drive, and 1 hard disk) we had a function called RSD - Read Sorted Disk. When the need arose to sort a file, whenever the length of the (combined) sort fields PLUS 6 (2-bytes each for the cylinder#(cc), head#(hh), and record#(rr) address of a record on disk) was less than half the length of the records being sorted (which was true a majority of the time), instead of swapping entire records on disk (memory sorting in 12K wasn't on the menu), we read the file and wrote "key" records containing just the sort field(s) plus the original record's address (cchhrr)). Then we sorted that "key" file on the sort field(s). After sorting, the RSD function would read the "key" records in sequence and use the cchhrr to retrieve/return the "full" records in sorted order.
Perhaps a similar implementation but utilizing memory for each small "phase" of the polyphase sort/merge would speed up the process? If real string swapping is occurring (and I suspect it is), then sorting "shorter" elements in memory would speed up the process of every phase. Admittedly, there IS an extra pass+ to read the original file and build/write the "key" file, and there IS an extra pass+ to read the sorted "key" file and retrieve/write the sorted "original" file. That's why the RSD process was only used if the length of the sort fields (plus 6) was less than half the original record length.

To paraphrase Shakespeare, The fault, Dear Brutus, lies not in our stars, but in our Anti-virus software.
After much ado, I installed the v1.2 QB64 and InForm Beta 7 on a different Windows 7 machine - one that is running different AV software, and InForm installed just fine - the C++ compiles to .EXE's ran without a problem, and the UIEditor came up and looks great. Unfortunately, it means that, once upgraded to InForm Beta 7, my InForm based QB64 programs cannot be maintained on that InForm intolerent machine, but will have to be compiled on machines with kinder, gentler, InForm-friendly AV software.
Curious as to why some AV software doesn't like InForm compilations.

Ron

Yes. Non-Inform programs compile OK.
Programs that DO include InForm forms, created with a prior version of InForm, obviously,  get flagged with an "Illegal string-number conversion" error in the SUB __UI_LoadForm Subroutine in the included form. For example, a program including "MyForm.frm" gets flagged on statement:
 __UI_NewID = __UI_NewContro(__UI_Type_Form, "MyForm", 722, 590, 0, 0, 0).

Ron