I’ve written a macro to animate some particle collisions. It works perfectly fine on afs (linux) at CERN
using 5.28.00b. Objects animate as I expect.
I’ve now installed ROOT on my Window 7 laptop (tried both 5.28f & 5.30) (also with MS Visual C++ v10). I
can open up a browser and see plots in a Tree, so the basics at least work… When I try and run
exactly the same macro that ran on afs at CERN, I get no display/animation during execution.
However, once I exit the macro, the image is instantly drawn.
I have the various canvas->Update() every time I want the canvas to update, so I’m stumped
about this different behavior between linux and windows versions…
Any help would be greatly appreciated…
I am attaching the macro. I’m not attaching the ROOT file, but if needed, I can also make a few events available to run them on the two platforms…
run5.C (17.2 KB)
Some files are missing:
root  .L run5.C
Error: cannot open file "B2DPi.C" run5.C:14:
*** Interpreter error recovered ***
Thank you for checking,
I am attaching a more complete list of files so that you can try and replicate what I see.
The only thing you need to “set” is in B2DPi.h, you need to put the proper location of the
ROOT file in the constructor of B2DPi.h. When it asks you for the number of animations, you can
enter 10 and return… The animation should display an XZ projection (center), and then in the top left corner
an XY projection, and then in the top right should be a set of histograms that are filled, one event
at a time… After the animation, it will prompt you to continue or not. You can do several events,
and see what you get on linux and on windows.
The animation should show two colliding bunches, and then a B decay emerge from the interaction point.
I tested with the attached files, and it works on my linux afs, but not windows…
B2DPi.h (76.1 KB)
B2DPi.C (3.18 KB)
B2DPi.root (227 KB)
run5.C (17 KB)
It is ok om Mac. I will try on windows (takes more time).
May be you can try to add Modified() together with Update() ?
OOps, please use this version of run5.C
run5.C (17 KB)
Glad to hear it works on MAC. I tried adding the Modified(), but doesn’t seem to work… it’s also a bit
inconsistent. Sometimes I get the XZ animation, and sometimes not. I generally do not get the XY display
until I reply with a “n” as to whether to continue.
I’m just wondering if there is a problem in the way I’m using the TCanvas’s to draw these displays?
I sometimes get a bit confused with the memory management part. Ideally, I would prefer to make just
a single canvas for each, and then just update it with each new event, rather than recreate a new TCanvas
inside drawPictureXZ_Anim() and drawPictureXY()…
I tried in windows and it works well for me…
Are you here at CERN? Maybe there is some setting that I need? Can I come by your
office, and show you what I am seeing? Are you also running under Windows 7?
Yes I am at CERN 32 R-C13
I am running XP
I noticed when the terminal (cygwin window) overlaps the graphics windows the update sometimes does not work.
May I come by, and I can show you what I see, and you can show me what you are getting?
Thanks!!! OK, I’ll be there in 5 minutes…
I suggest you contact Bertrand.Bellenot@cern.ch when he will be back on September 14th.
Try to have a look at $ROOTSYS/tutorials/spectrum/peaks2.C
The way it is working might be what you need.
Thanks! I assume you mean the usage of “TCanvas::WaitPrimitive()” ? I implemented this, and now it
works better… but, the smaller XY Canvas (top left corner), which should be on top, tends to always go behind the XZ Canvas. It seems to do it OK on the first event, then, afterward it’s always behind & hidden.
I tried several variants of ccxy->RaiseWindow() to bring it to the front, but it doesn’t do the trick…
Is there some way to force a canvas to be on top, and not hidden? If this can be solved, I think everything
works OK after that…
Thanks again for your help with this!!
That more related to the window manager… I am not sure there is a solution to that (popping up a canvas with a ROOT command. Bertrand would know).
May be the simplest would be that you layout the canvases in a such way they do not overlap ?
Thanks, I implemented this waitPrimitive(). The first event was still not behaving properly,
so I included a dummy routine to just create a blank canvas and Update(). With this little
work-around, it seems to function fine…
Thanks again for your help!