(Disclaimer: the following is in process and subject to change. The author, nor Microsoft, makes no guarantees nor warrantys on the content of this post)
One of the features we intended to put into VFP 9 was AppState, a _SCREEN property that would allow you to trap when a VFP application got or lost focus in regards to other Windows apps. All you needed to do was setup some code and a BINDEVENT and you could trap it.
Now this was something asked for by quite a lot of customers and seemed like a great idea. However, we were having problems with it as there were double the number of Windows focus messages flying around under certain circumstances. This made testing difficult and since there was no way to further granularize what was actually happening, it would make for a problematic implementation in line-of-business customer applications.
So Calvin took to exploring the whole Windows messaging concept and has come up with something even better: The RegWinProc function.
What does it do? Well...here's the early upshot direct from Calvin's email:
hWnd is the hWnd value from _VFP or _SCREEN or a VFP Form. nWinMessage is the Windows message, a numeric value in a hexadecimal representation in MSDN documentation; ie, 0x0201 is WM_LBUTTONDOWN or left mouse button down. cProcedure is the UDF to call for the specified window and message.
So what is gained? Pretty much the entire Windows messaging world. Here's some mini-use cases:
- You need to trap a shutdown or restart to guarantee that all tables and indexes are closed cleanly in your application. You can trap WM_POWERBROADCAST for the _VFP hWnd and send it to a UDF that performs the closings.
- You want to know a disk has been inserted or ejected from a drive. No problem; that message is trapable. Boy, I remember the days when the application asked users to insert a disk into drive A: and press Enter. You then prayed that they had and proceeded anyway with little ability to check.
- You have a sophisticated Tablet PC application that uses an offline view to an enterprise data source. You can now add the capability to resynch the view when the application senses that the network is available using RegWinProc; Windows detects when network connections are gained and lost and now you can too.
- You can now detect when Plug-and-Play media has been added or removed. Great for applications reading or writing to a USB drive.
- Last (but not finally), you can stop an event dead in it's tracks with the BROADCAST_DENY_QUERY nWinMessage. Trap this baby when there are things you don't want to happen while your application is running; for example, your app and data is on removable media and you do not want that media ejected while the application is running.
My understanding is that there are lots of .Net samples for this type of code and I'm sure we'll come up with some and you guys will come up with a lot...which I'm hoping you upload copiously to web forums and other net watering holes to share your insights. I'm sure this will be fertile ground for article writers as well.
Final word: There's a movie quote rattling around in my head, “With great power comes great responsibility”. Ken would know who said it and when <g>. My point is, with this new function you have a lot of control of what is going on in Windows external to your VFP application. It's quite possible, if used poorly, that you could crash your application or other processes on your computer. This is not something new to RegWinProc - you can do it now with DECLARE - DLL and a misuse of the API.
Final (I mean it this time), final word: This new function was just approved and did not make it to the public beta build. However, if we refresh the beta later on you'll likely see it. I'll post a followup if and when that occurs.