Dear Rooters,
I already wrote you once concerning my event display. In that occasion it was a gcc problem on my computer that I managed to solve. I have another question though… I wrote this simple event display which is made of just one class (ArgoFrame) and that makes use of threads to separate the actuall reading of the data from the graphic. The problem is that the program is quite unstable and sometimes the reading goes in conflict with the graphic session and the program crashes. I had to disable some interactive buttons when loading old data because the program couldn’t handle bothactions. Could you help me to figure out a way of solving those problems? Do I need to split the program in more than one class? And if so, do you have an example program I could refer to. In attachment I’ve sent you the program. I’ve tried to send you also a data file for example in order to see it while running but even compress is too big and I couldn’t manage to add it in attachment.
Thank you very much in advance
Irina James ROOT_FORUM.tar.gz (131 KB)
It will be good if you can put your data file in a public place. Please provide some more details about the steps to follow when your application runs.
Hello Ilka, sorry for not answering immediately. You will find a file of data on the following site “http://www.pv.infn.it/~james/” . To run the program you would just need to change the path in file argomain.ini and in line 1332 of ArgoFrame.cc and compile. It should work. The program will read the data and display a series of histograms that update every minute (in online mode). The problem is that the program is very unstable and I was wondering if is due to a bad structure of the program and I need to divide it in more than one class or is something else…
Hello Ilka,
in argomain.ini the first path is the directory where the data file is kept and the second is tha path where a file called Rerence.txt is. So I think the things to change are:
I got the data file and run your code without problems. Please see the attached gif file showing your application after the message “End Of File” was printed. What should I do next to reproduce the problem you faced on?
The problem occurs when one tries to interact with the display. If you try to push the buttons with the arrows drawn on top to change pages while the program is running or select a different scaler and then push the button draw, the program will just crash. This program is meant to read online data and the same problems occur even when the flux of data is not so high as when you read a closed data file. If I interact with the GUI while the program is reading it will just make a mess…
Thank you for your explanation. It seems the reason of the crash when you select different scaler is in your code. You create a list box (flist) with 4 entries and without setting multiple selection ON by flist->SetMultipleSelections(kTRUE) you try to get the list of selected entries (fActiveHistos). At that point the program crashes on line 1108.
I see no problems when clicking on “>>” and “<<” buttons while data is reading.
Thanks for your quick reply. Where do I have to add the flist->SetMultipleSelections(kTRUE) command? Iput it at line 1107 but it crashes anyway.
Sometimes the program won’t crash pushing the button >> or << but sometimes it will … anyway do you think the structure of the program as a whole is ok as it is? I’m not an expert and I would like to make it more stable…
You can set it after the list box is created, but I am not sure you need that. What is the purpose of fActiveHistos? I am asking because your list box has 4 entries and I did not investigate in details your code.
Hello Ilka,
sorry but I found two problems in the code. The first one is that for the version I have sent you, the variable “statebutt” is always zero so the first if statement in before the creation of fActiveBox, should be " if(statebutt==0)" . The second one is setting “if(hID!=0)delete hID” before its creation. Without that the program seems not to crash when changing scaler.
It still has problems when you push the buttons >> or << and in the core the error is related to the line 1236 (in DoDraw()) "gSystem->ProcessEvents(); and other times at line 1353 (in Loop() ) gSystem->Sleep(100); are these two command in conflict between them?
In the Loop() I create and run the Thread that then calls ReadData() and then DoDraw().
Thank you again and sorry for this confusion…
Irina
I suppose that fActiveBox in your previous message is fActiveHistos. Because in the slot methods Forward() and Backward() you call DoDraw() method, I will suggest you to disable both navigation buttons in the beginning of DoDraw method:
forw->SetState(kButtonDisabled);
back->SetState(kButtonDisabled);
and to make them available for user interactions in the end of DoDraw: forw->SetState(kButtonUp);
back->SetState(kButtonUp);
After this change your code runs fine on my machine. Your GUI is not complex and you do not need to split it in more classes.
Hi, just want to share some thoughts.
Looking through your code I am a little concerned that something is wrong in the design. Two points of note:
You dont seem to Lock and Unlock the global Mutex symmetrically. That is I see 2 lines of code where you Lock the Mutex but only one Unlock. Normally Lock and Unlock should always be in pairs unless your code does something very very fancy (Which always makes it more difficult to follow and debug). Moreover the Lock/Unlock pair is in different routines. At the very least this is confusing and will make the code difficult to maintain if it is not plain wrong behaviour.
In your main routine (program entry point) you have a call to ArgoFrame::Loop() which looks like you custom built event loop. And then just after that you have a call to TApplication::Run() which it the standard ROOT event loop. So why are you entering an event loop twice?
A point about maintainability. I would avoid where possible having the code of a single class executed by more thread. In this case I think it is better to pull the code doing the reading of your data into its own class which is excecuted by its own thread.
