> have a 'main' unit (Main.pas) with a form. On the form is > ProgressBar1 (a TProgressBar component) I have a 'uses' unit > (Unit1.pas) that does processing and the goal is to show the > progress of this processing by updating the ProgressBar on > the main form. > > (1) Type PProgressBar = ^TProgressBar ; //Declare pointer type > (2) Var ProgressBar1Ptr : PProgressBar ; //Declare pointer variable > (3) ProgressBar1Ptr := PProgressBar(ProgressBar1) ; > //Assign value to pointer > (4) TProgressBar(ProgressBarPtr).Position := CalculatedBarPosition ; > > Line 1 and 2 are visible to both Main and Unit1. > Line 3 is executed in Main to set the value to the pointer. > Line 4 is executed in Unit1 is update the position of the > progress bar.
Hi Gerry, Personally, I see nothing "wrong" as such in doing things this way, but perhaps you might find the following thoughts useful: It appears on the surface that you are trying to avoid a dependency in the used unit which would require that unit to have intimate knowledge of the calling form. In order to do so, you are using an object to represent the type of data (IE: progress) that you wish to present back to the calling form. Using a TProgressBar however limits you to only presenting progress data as a TProgressBar, but what if you were to change your mind and decide you wanted to use some other widget instead to display the progress of an operation? What if you decided there were several unrelated operations that you wanted to have contribute to the overall progress of a larger task? I agree that the use of a pointer in this case makes sense, but have you considered the use of a method pointer (AKA an event) in this case? Using events, would allow you to make your progress information more generic in terms of the type of handler required that might receive your progress information, yet still allow you to include additional state information related to a given process if that is your wish. Your main form would then be responsible for creating an handler that could pass the progress information to a TProgressBar if that is your wish, or to some other widget if you ever decide to modify your interface. The disadvantage to implementing events is that it would require a little more code, and could potentially allow you to introduce a delay in each iteration, which could prove costly if your processing task is particularly lengthy - a problem that could be alleviated somewhat by ensuring that events are only triggered when notification is absolutely required (say every 1, 5, 10, or whatever percent of the time). The advantage would be that your process or interface could change independently, due to presenting a more generic (IE: loosely coupled) interface. HTH, S. Sean Robins Dynamic Hearing Pty Ltd http://www.dynamichearing.com.au _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
