nonCOMApp_Toolkit (a start)

[mr_unreliable]

Back during my scripting days, we had fun controlling other apps.  If they were COM apps, then the COM interface made manipulating them easy.  For apps without the COM interface, one had to result to various tricks (remember AppActivate and Sendkeys?).  I called those tricks my nonCOMAppToolkit.

This came to mind recently.  I use the 7-zip utility to make backups. However, when I switched my legacy system from win98 to winXP, I ran into a problem.  With 7-zip, if a file is in use by another app, then 7-zip will report it and then stop.  I worked around this in win98 by programming in exceptions to 7-zip for "busy" files.  But in winXP, there were too many exceptions.  Instead of walking away and letting the backup routine run itself, I had to stick around and click the "close" button (frequently) to get through the backups. I longed for a routine which would click the "close" button for me.

FULL DISCLOSURE: This is not a rewrite of the nonCOMAppToolkit for BCX, it is only a start.  There isn't very much to it.  It will find the 7Z window and the close button, then click it.

Take One.  I used two enums, one to find the 7Z window, and another to find the button.  7Z uses the same button for "cancel" when it's running, and "close" if it's finished but still displaying exceptions.  Then I had a "wait loop" which would check periodically for the "close" button, if any.  In the wait loop I used the two enums to find the button and check whether its caption was "close".  Kindly hold your screams of disparagement and disrespect.

I know what you're thinking: I didn't really need any enums.  You don't need an enum to get the 7-zip window -- just use GetActiveWindow.  That may work 99pct of the time.  As for the second enum to get the close btn, you could use GetDlgItem.  You can get the ctrl ID programmatically, or manually using windows SPY.  And my poor mono-core PIII had trouble keeping up with all those enums.

Take Two.  This is based on two assumptions.  That the hWnd of the 7Z app won't change while it's running, and the hWnd of the btn control won't either.  Also that 7Z will use the same btn control for "cancel" while running, and "close" when finished.  Reasonable enough.  I used an enum to get he 7Z hWnd, and the ctrl ID to get the button hWnd.  Instead of the "wait loop" I used the timer, which was running to update the clock in the statusbar.  So in the timer handler, I look for the button caption to change to "close" then send a button click msg. 

So now this code will go into my backup app, and I expect that I will be able to start the app and walk away, confident that it will keep going to conclusion.

cheers, mru.
developed on winXP, with BCX v7.5.0, and pellesC v6.5. Works on win10.

My Usual Disclaimer.  I worked on this until it was good enough for my purposes.  It could obviously use some code polishing and beautification.  I may get around to that later, but probably not.

If you try running this, you may need to review the filespecs.  The test starts with a BFF, to ask where you want the zip file to go.  I will be zipping up a folder in windows which is guaranteed to show busy files.  I also built in the default location for the 7-zip program, but in your case you may have installed it elsewhere.  On my own systems, it was installed in different places.  If you do have 7Z installed, there is probably a path to it in the registry.  I checked on that location too.  If that doesn't work, you will have to re-adjust the code. 

Are you wondering why I am using 7-zip instead of the prescribed microsoft backup utility built into windows?  That is another topic. 

P.S.  AppActivate is awkward in this situation, as 7Z is using the titlebar instead of the statusbar to show progress of the zipping (in addition to the progress bar).