Hi Jens, On Wed, 11 Jul 2001 23:04:13 -0100 (GMT+1) Jens Ivar Jordre <jens@fi.uib.no> wrote concerning ": Re: BROP-1-0-1 and something must be wrong here.......": > Hello y all. Uh, take look at http://www.rhic.bnl.gov/brahms/WWW/private/list_hyper/brahms-soft-l/0045.html http://www.rhic.bnl.gov/brahms/WWW/private/list_hyper/brahms-soft-l/0046.html http://www.rhic.bnl.gov/brahms/WWW/private/list_hyper/brahms-soft-l/0047.html http://www.rhic.bnl.gov/brahms/WWW/private/list_hyper/brahms-soft-l/0048.html to see what a greeting like the above can spawn - funny stuff by the way. > First some update info. I have made a lighter BrOnlineMonitorTPC > than the one that was there previously. This new class does not do > clustering nor tracking. I have also updated SuperMon.cxx to include > the four TPCs. In my view SuperMonTPC.cxx is obsolete, but I have > chosen to keep it so far. New tag: BROP-1-0-1. I think Kris has some views on this (I tried to find them in my backcatalog of emails, but - alas - failed). As far as I remember, the idea was to have a seperate application for such computing heavy stuff as the TPC tracking, so that the normal monitor is fairly free to do what ever. > Then the fun stuff. I had some compilation problems earlier today using > BRAT 2.0.4 and ROOT 3.01/05. When going back to ROOT 3.00/06 everthing > seems to work fine. Both ROOT "packages" I used are from the BRAHMS AFS > area. This lead me to "investigate" > /afs/rhic/opt/brahms/root/root_v3.01.05 to some small extent. I believe > there is something odd about it. How about this: > > bergen@pii4<1>:/afs/rhic/opt/brahms/root/root_v3.01.05/bin/root-config > --version > 3.00/06 > bergen@pii4<2>: Ehr ... that is odd. Hmm. Anyway, if you want to use ROOT 3.01/05, just include in your path /afs/rhic/opt/brahms/new/bin:/afs/rhic/opt/brahms/pro/bin unset ROOTSYS and set your LD_LIBRARY_PATH to exactly /afs/rhic/opt/brahms/pro/lib See also rcf:~brahmlib/.login In the future, when BRAT 2.0 becomes the production version, which I think it's almost ready for, you'll not need to unset the ROOTSYS environment, since it will not be set in the first place. > Where does this fit in. > > Well, next thing concerns SuperMonitor. We, i.e. Flemming and I, > want to print the histograms/pictures drawn on the screen. To do > this one would typically use the print button on the > BrMonitorCanvas. > > The first time one hits the print button, the print dialog shows up > without any problems. Then if one wants to print other > histograms/pictures, one typically runs into segmentation violation > when hitting the print button on the new instance of > BrMonitorCanvas. The seg. violation does not necessarily occur when > printing the second BrMonitorCanvas. It can occur on the 5th, 14th, > Nth....... Sounds like you do not properly unmap and destroy the popup window. How is that defined? Does it inherit from TGTransientFrame, of from TGMainFrame? How is it constructed? As new <pop-up class>; or as if (!fPopup) fPopup = new <pop-up class>; else { fPopup->Update(); fPopup->MapWindow(); } The later uses the same object over and over again, which is all right, as long as the user doesn't hit the M-F4 or uses the windowmanager to kill the window, in that case, there must be a slot connected to the CloseWindow signal, and that slot must delete and zero the fPopup member. I have an example of dealing with some of this back home, I'll try to bring it tomorrow. > However, this error has the same feature as an error you, Kris, > corrected earlier. I.e. if you hit the print button several times > after the seg. violation you finally (usually) end up with the print > dialog window. Interresting. It does sound like a map/unmap window problem. By the way, does the monitor GUI's use the Signal/Slot mechanism or the ProcessEvent mechanism? The former is far superiour to the later. For example, one can have a class that listens on a port from the DAQ, and when new data arrives, it'll emit a signal to all the classes that new data has arrived: class Server : public TQObject { private: TSocket* fSocket; TObject* fData; static Server* fgInstance; ... public: ... void NewData(TObject* d) { Long_t* arg = (Long_t*)d; Emit("NewData", arg); } // *SIGNAL* TObject* GetData() const { return fData; } ... }; class Client : public TObject { private: ... public: Client(...) { Server::Instance()->Connect("NewData(TObject*)", "Client", this, "HandleData(TObject*)"); ... } void HandleData(TObject* d) { d->Print(); ... } ... }; This is ofcourse not restricted to GUI classes but can be used everywhere - if I had to redesign BRAT, I'd might think about doing it like this. > Explanations/solutions anyone? Try running the application in the debugger, and see where it fails. Yours, Christian ----------------------------------------------------------- Holm Christensen Phone: (+45) 35 35 96 91 Sankt Hansgade 23, 1. th. Office: (+45) 353 25 305 DK-2200 Copenhagen N Web: www.nbi.dk/~cholm Denmark Email: cholm@nbi.dk
This archive was generated by hypermail 2b30 : Thu Jul 12 2001 - 06:31:26 EDT