Hi, It's nagging me again, so let me once more try to make the point. I would really like to know what I didn't understand in the former discussion. For the sake of clearness, I'll use my current example... I'm using a macro which loops over events and plots 4 histograms in two canvases. Every once in a while, say after 100 events, I want to refresh all the histograms, so I do c1.Update(); and c2.Update(); This, however doesn't work!!! Why not?? Well, you have to first have to set the Modified() flags of the pads containing the histograms. In my case this means 4 sequences of c1.cd(1); gPad->Modified(); [Note that c1_1 doesn't exist when you've done a c2.cd(2)] The underlying point is that if you fill an entry in the Histogram, it doesn't set the Modified() flag of the pad it is in, and that setting the Modified() flag of the histogram itself doesn't force repainting at a c1.Update();. I still don't see why. Using TCanvas::Update() I'm perfectly in control of when my canvas will be repainted, I don't need (or even want) extra control, if this implies having to set Modified() flags by hand. I think there are three simple ways by which the redundancy can be removed, while retaining user's control over the whole repainting business: 1) Upon a TCanvas::Update(), not only pads which are Modified() are repainted, but also Histograms which are Modified(). This would imply that the programmer/user must have full control over the TH1::Modified(); after once setting this flag the histo will always be repainted, until the flag is unset by the user (NOTE: alway means at every invocation of TCanvas::Update(), the user still controls the axcat moment of repainting). 2) TH1::Fill() automatically sets the Modified() flags of the pads containing the histogram. This means that the user has somewhat less control over the Pads. However, Draw()-ing a histogram also changes all kinds of Pad-settings (which you really like, because this is part of the drawing anyways), so I don't think this really is a problem. The only real drawback might be that the filling will take extra time. The user can, if wanted, prevent this by first filling and then drawing the histo... 3) TCanvas::Update() always repaints histograms. This might seem a somewhat crude approach, but I think that one only wants to really control redrawing for complicated things such as event displays, and these are not made of histograms. One more note: when I brought this up earlier, someone remarked that the current procedure resembles a procedure used in databse management, where you first change all kinds of things and then explicitly finalize them. The advantage of this procedure is that you can always go back to the last finalized version of your database, by not storing teh changes (I think this is called 'roll back'). This last option however, is not quite impemented in ROOT and therefore I don't see the point in keeping an on-screen copy which is somehow half-finalized (the associated Histogram object can already be changed, but Updating the pad doesn't show these changes. The older version is only available as a picture and can't be retrieved (or saved or whatever)). Kind regards, Marce van Leeuwen
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:41 MET