jwcolby
jwcolby at colbyconsulting.com
Fri Jan 23 00:00:48 CST 2009
I am building a system to process rather large files. I export tables in SQL Server out to files, process the files via an address validation program, then process the files back into SQL Server. One of the steps has to process every file in a directory. The code itself sits out in a function, which is called from a form. The form allows me to select a from dir and to dir, then do the processing. The functions can be called by hand from the debug window (I do this during debug, or from the click of a button on the form once things are working. One way to feed the status back is to hard code the name of the form and control on the form that the status value is to go into, in this case the name of the file currently processing, and a line count mod 1000 kind of thing to show me every 1000th record processed. Another way to do the status is to set up a message channel. By passing in the name of the form, the function that iterates the directory can then broadcast a message with the "to" being the name of the form passed in, the subject being "FileName", and the message being the name of the file being processed. The form sinks the message event and if the To matches me.name it processes the message. If the Subj = "FileName", it takes the Message value and places it into txtFileName.Value, IOW it displays the message (the name of the file being processed) in a text box. Likewise I have another function that actually processes each file. It opens the file, reads line by line, massaging the data and writing the results out to another file. It is helpful to be able to see the line number being processed every once in awhile to know that something is happening. Again, that function simply calls the msg channel (class) every 1000th record and passes the record counter out. It passes out the form name as the To, "RecordCnt" as the subject, and the count itself as the message. Again, the form sinks the message event and if the To matches me.name it processes the message. If the Subj = "RecordCnt", it takes the Message value and places it into txtRecordCnt.Value, IOW it displays the message (the current line count of the file being processed) in a text box. Now obviously this can be done other ways, but the advantage of WithEvents is that the form does not have to be open, or for that matter even exist, and the code will still run. Messages are broadcast, and if the form happens to be open (trigggered the code to run) it can sink the messages and display the status. This is an example of how I actually use my message class to broadcast status messages from code and display them in a form. I can run the code by hand and because there is no hard coded form / control reference, the code runs just fine. I can then tie the code to a specific form (or many different forms) and simply by passing in the form name the message can tell the form that the message is intended for it, and the form can process the message. I am sitting here watching my code process about 85 different files, displaying the file name and an incrementing line count, and it all took just a few minutes to set up the status display. A single line of code in each of two functions, and an event sink in the form, about 12 lines of code. Classes and withevents. As I mentioned the message class is available for your enjoyment on my web site, along with a very simple demo to show you how to use it. -- John W. Colby www.ColbyConsulting.com