Re: gPad

From: Rene Brun (Rene.Brun@cern.ch)
Date: Thu Mar 02 2000 - 18:18:32 MET


Hi Rutger,
This is a solution NOW !
Simply use the following few lines for your PadTest.C:
{
   if (!gROOT->GetListOfCanvases()->First()) {
      TCanvas *c1 = new TCanvas("c1");
   }
   gPad->Clear();
}  

We must find a solution using gPad.

Rene Brun

Rutger van der Eijk wrote:
> 
> Hi,
> 
> I am still a bit worried about these changes to previously defined globals
> like gPad and gDirectory. The trick (i.e. gPad as a #define to some
> global function) applied now seems not to work. Even if I access the
> global function directly I have problems. As mentioned before the macro:
> 
> {
>   // create pad
>   if (!Pad()) {
>     if (!gROOT->GetMakeDefCanvas()) return;
>     (gROOT->GetMakeDefCanvas())();
>   }
>   Pad()->Clear();
> }
> 
> crashes on v2.23/12 with:
> 
> root [0] .x PadTest.C
> Error: illegal pointer to class object Pad() 0x0 218
> FILE:/afs/cern.ch/user/r/rutger/mycmt/ot/RootTest/v5/macros/PadTest.C
> LINE:7
> *** Interpreter error recovered ***
> 
> So, or I'm doing something wrong or the mechanism doesn't work.
> 
> This is my primary problem at the moment, and I need a solution NOW!
> 
> On the long term. I partly agree with what was mentioned by Fons and
> Alexander. I think using a static member function is the best place to put
> these global entry points. In there you can decide to do something
> different in case of threads or other things. 2 comments:
> 
> 1) I would suggest the name of these statics to be something like:
> 
>   TVirtualPad::current()
> 
> because that is what they actually are, a pointer to the currently
> selected pad/directory. TVirtualPad::Pad() doesn't say anything. The only
> reason to call it Pad() is because the historical gPad.
> 
> 2) The short cut gPad. As it seems now gPad in CINT is only known after
> something is drawn. Fons suggest to use Pad() directly in that case. I
> think this is confusing. Or you/we use gPad or Pad() (or
> TVirtualPad::Pad() later). Writing a macro I shouldn't depend on the fact
> if another macro has already drawn something or not. So somehow gPad
> should always be known to CINT. If this is not possible I suggest to
> dissuade people from using gPad, and also change all the standard ROOT
> examples/macros to use the static member function directly.
> 
> cheers,
> 
> Rutger
> 
> > Hi, just a comment.
> >
> > Probably  it would be good to extent "root naming rules"
> > for these static functions, e.g.
> >
> > TDirectory::Dir() will be TDirectory::gDir()
> > TFile::File() -> TFile::gFile()
> >
> > TMath::SomeConstant() -> TMath::kSomeConstant()
> >
> >
> > Best regards.                Valery
> >
> >
> > Hi Alexander,
> >
> >   you are right and of course I thought about putting the globals
> > (gPad, fFile, gDirectory) as static member of their respective classes.
> > First I thought about typing economics, typing Pad() at the command line
> > instead of TVirtualPad::Pad() makes a difference. However, thanks to a
> > later deviced CINT "trick" I can still allow users to type gPad and
> > so now there is no econimics reason anymore I will make them static
> > methods.
> >
> > Cheers, Fons.



This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:20 MET