jwcolby
jwcolby at colbyconsulting.com
Wed Dec 26 11:45:38 CST 2007
Yes, I want to use backgroundworker. The in some cases the process will really be: 1) The CSVExport process will export a table of tens of millions of records to a directory on an Address Validation Server (AVS), the AVS Input directory. 2) The Address Validation Server has a set of directories that it watches. As files appear in the watched directories the AVS starts to perform the address validation process on those files. 3) The AVS places address validation processed files into a set of matching output directories (one input / output pair), the AVS Output directory. 4) The CSVImport process will watch the AVS Output directory for that CSV process. As files appear in that directory it will import those files back in to SQL Server. So the entire process is an Out / AVS / In cycle. This cycle can be performed on many different tables. Each table needing AVS processing has a Spec record for the CSV OUT and a spec record for the CSV IN. I currently have five different tables of addresses needing validation, and the validation can occur on a timetable, perhaps once every three weeks etc, but the point is that it will eventually be totally automatic. A supervisor spawns a table AVS process that starts exporting data to the AVS, the AVS processes the data, and the results are imported back in again. Thus I really need (or should use) worked threads to handle the CSV export and import processes, for potentially N tables at a time, potentially "simultaneously". John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Shamil Salakhetdinov Sent: Wednesday, December 26, 2007 12:08 PM To: dba-vb at databaseadvisors.com Subject: Re: [dba-VB] VB.Net "proxy" progress indicator Hello John, If you're sure your main code export/import will never be used in multi-threading scenarios then you can just use so called Delegates... But I'd propose you to try to implement multi-threading and use BackGroundWorker class - they both could help you to solve your task effectively and have your tasks completed quicker because of multi-threading - have a look at this article/book excerpt: http://www.albahari.com/threading/part3.html#_BackgroundWorker -- Shamil -----Original Message----- From: dba-vb-bounces at databaseadvisors.com [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby Sent: Wednesday, December 26, 2007 7:05 PM To: dba-vb at databaseadvisors.com Subject: [dba-VB] VB.Net "proxy" progress indicator I am trying to figure out how to do something that is probably simple if I knew what I was doing. I have a bunch of processes that do similar things. They need to visually report the same data. For example I import CSV or flat files from a directory of files. Thus I need to report: 1) The directory being processed 2) The current file name 3) File N of M being processed 4) A "progress bar" showing that something is happening in the current file 5) The NAME of the process currently running I also EXPORT CSV files from a table out to a directory. I need to report: 1) The directory being exported to 2) The current file name 3) File N of M being exported 4) A "progress bar" showing that something is happening in the current file 5) The NAME of the process currently running As you can see, though the direction is different, and the class that performs the process is different, they both need to report the same kind of things. So what I want to do is create a progress form that has controls and labels for the controls to display this information. I would like to make the form not required for the process itself to run, i.e. I can display the progress if I so desire or not show the progress. All progress is also being logged to tables and text files thus the display is a "nice to have" feature. My concept of how to do that is with events, i.e. the class that performs the process raises a series of events, and if there is a listener, then the listener displays the information. For example The process raises a "Process Name" event and passes out the name of the process it is running. It then determines how many files will be required and raises a "Total Files" event passing out the N (number of files) value. It has a counter by which it tracks which file it is currently processing and raises an M (current file number) event every time it starts a file. It raises a "Current File name" event as it generates the file name it is about to process. And so forth. Then a "proxy" progress indicator form can be opened. This is where my knowledge breaks down. Somehow I have to pass in a "something" that can have its events processed. The problem is that the "something" changes. One time it is a CSVExport class, the next it is a CSVImport class, the next time it is a FlatFileExport class, the next it is a FlatFileImport class. Now given my weak knowledge of VB.Net, my first thought is to create a "clsProxySource" as a base class. This class has properties for holding these pieces of data (process name, M, N, FileName etc) and methods which raise events and pass out these variables. I then inherit this clsProxySource" in each of my process classes so that each of those process classes has the properties and the ability to raise this event. Next in the proxy display form I dimension a variable mclsProxySource of type clsProxySource. I define the event sinks for the events that the clsProxySource sources. In the New() I pass in the process class instance that needs to display a status. In the new it is coerced back into a clsProxySource and stored in the mclsProxySource. Now the process class can raise events and the form (if it exists) sinks those events and displays the values in the controls on the form. So... Is that how it is done, and if not how do I go about doing this? If it is how it is done, the one piece I know for sure that I am missing id the syntax for coercing the process class back into the clsProxySource. If anyone could help me with this stuff I would be most appreciative. Thanks, John W. Colby Colby Consulting www.ColbyConsulting.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com _______________________________________________ dba-VB mailing list dba-VB at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-vb http://www.databaseadvisors.com