Hi Ryu 

thanks ever so much. 

We will modify our code as per your example - is it neccesary to build in development as well or is that only where your example is

-Farrukh

> Dear Farrukh
> 
> What you want to do is probably possible ( I will write a possible method later.).
> However TPad has already several mouse operations (zoom, right-click menu, select active pad and so on); so I am not sure it is the best idea to add own mouse operation (which 
> could override other pre-implemented operations.)
> I will write three solutions below.
> I wrote an example of the first method.
> 
> == Method 1 : Menu ==
> For this solutions, I modified an example in the ROME package.
> The update is done only in the 'develop' branch.
> You can read the example by 'git checkout develop' command after you clone the ROME package.
> The example is in $ROMESYS/examples/argus/menu and the third tab (T3) is one for that.
> In ROME, you can easily add menu items in the menu bar. In the example, menu items to open and save a specific tab are prepared.
> 
> == Method 2 : dedicated buttons ==
> If you prefer buttons instead of menu, you can put dedicated buttons to trigger "OpenPad" function in the example instead of adding menus. The buttons can be implemented 
> either of the following two methods,
>  1) TGTextButton, which can work as the same way as your Save button
>  2) Writing own class derived from TBox or TMarker. A box or maker can be put on each canvas.
> 
> I hope the first method is obvious for you. You can make another button similar to your Save button and call "OpenPad" function.
> 
> The second method is a little more complicated; you make your own class and override "ExecuteEvent" method.
> In the overriding function, you can call any functions when the box or marker is single-clicked, double-clicked, mouse-over and so on.
> A disadvantage is that the box or marker is always visible, and will be drawn in the output PDF files too.
> 
> == Method 3: click on Pad ==
> You can probably do what you write with making own class derived from TPad; then you override "ExecuteEvent" function for calling a function to make a separated canvas and 
> draw a clone of itself.
> You may also need own TCanvas and TRootEmbeddedCanvas for using the customized classes instead of regular TPad and TCanvas.
> 
> If you are satisfied with the first method, please try the example.
> The second method with TGTextButton must not be very difficult.
> 
> If you prefer the second (using TBox or TMarker) and third method, I will investigate if it is actually possible.
> For the two methods, I think you need to write your own classes.
> 
> Best regards,
> 
> Ryu
> 
> > Dear Colleagues,
> > 
> > We are succesfully running a ROME executable both online and offline with an 
> > ARGUS display with a canvas that has multiple pads on it. We have also 
> > implemented a "Save" button which one can click on and save the _entire_ canvas 
> > (containing all the pads) and saves it to pdf.
> > 
> > I was wondering how one would go about making the following modification :
> > 
> > When a user moves a mouse over to a particular pad and clicks on it - then only 
> > the histogram on that pad is displayed on a separate canvas (so the user can 
> > examine it closely) and also save just this one histogram - with a save button 
> > similar to the one we've already written.
> > 
> > many thanks for any insight
> > 
> > Farrukh 

Dear Colleagues 

we have implemented in one of our tabs a button to call a function which saves a 
canvas to a pdf file with a time date stamp.

1) This works fine when there is only one histogram on the canvas and this code 
is MIDTBCTab.cpp (attached)

2) When the canvas is divided up into a 5x11 pads with 55 histograms and 
we want to save the _whole_ canvas with the whole picture (_not_ any individual 
pads) the code crashes  and no file is generated - the tab code is MIDTRCTab.cpp
and this is also attached 

I am wondering what is going on - is there anything obviously wrong ?

many thanks 

Farrukh

Hi Ryu

thanks very much - I will certainly look at this example. In the meantime we are having some issues with out save buttons - I will post a thread separately
-Farrukh

> Dear Farrukh
> 
> What you want to do is probably possible ( I will write a possible method later.).
> However TPad has already several mouse operations (zoom, right-click menu, select active pad and so on); so I am not sure it is the best idea to add own mouse operation (which 
> could override other pre-implemented operations.)
> I will write three solutions below.
> I wrote an example of the first method.
> 
> == Method 1 : Menu ==
> For this solutions, I modified an example in the ROME package.
> The update is done only in the 'develop' branch.
> You can read the example by 'git checkout develop' command after you clone the ROME package.
> The example is in $ROMESYS/examples/argus/menu and the third tab (T3) is one for that.
> In ROME, you can easily add menu items in the menu bar. In the example, menu items to open and save a specific tab are prepared.
> 
> == Method 2 : dedicated buttons ==
> If you prefer buttons instead of menu, you can put dedicated buttons to trigger "OpenPad" function in the example instead of adding menus. The buttons can be implemented 
> either of the following two methods,
>  1) TButton, which can work as the same way as your Save button
>  2) Writing own class derived from TBox or TMarker. A box or maker can be put on each canvas.
> 
> I hope the first method is obvious for you. You can make another button similar to your Save button and call "OpenPad" function.
> 
> The second method is a little more complicated; you make your own class and override "ExecuteEvent" method.
> In the overriding function, you can call any functions when the box or marker is single-clicked, double-clicked, mouse-over and so on.
> A disadvantage is that the box or marker is always visible, and will be drawn in the output PDF files too.
> 
> == Method 3: click on Pad ==
> You can probably do what you write with making own class derived from TPad; then you override "ExecuteEvent" function for calling a function to make a separated canvas and 
> draw a clone of itself.
> You may also need own TCanvas and TRootEmbeddedCanvas for using the customized classes instead of regular TPad and TCanvas.
> 
> If you are satisfied with the first method, please try the example.
> The second method with TButton must not be very difficult.
> 
> If you prefer the second (using TBox or TMarker) and third method, I will investigate if it is actually possible.
> For the two methods, I think you need to write your own classes.
> 
> Best regards,
> 
> Ryu
> 
> > Dear Colleagues,
> > 
> > We are succesfully running a ROME executable both online and offline with an 
> > ARGUS display with a canvas that has multiple pads on it. We have also 
> > implemented a "Save" button which one can click on and save the _entire_ canvas 
> > (containing all the pads) and saves it to pdf.
> > 
> > I was wondering how one would go about making the following modification :
> > 
> > When a user moves a mouse over to a particular pad and clicks on it - then only 
> > the histogram on that pad is displayed on a separate canvas (so the user can 
> > examine it closely) and also save just this one histogram - with a save button 
> > similar to the one we've already written.
> > 
> > many thanks for any insight
> > 
> > Farrukh 

Dear Farrukh

What you want to do is probably possible ( I will write a possible method later.).
However TPad has already several mouse operations (zoom, right-click menu, select active pad and so on); so I am not sure it is the best idea to add own mouse operation (which 
could override other pre-implemented operations.)
I will write three solutions below.
I wrote an example of the first method.

== Method 1 : Menu ==
For this solutions, I modified an example in the ROME package.
The update is done only in the 'develop' branch.
You can read the example by 'git checkout develop' command after you clone the ROME package.
The example is in $ROMESYS/examples/argus/menu and the third tab (T3) is one for that.
In ROME, you can easily add menu items in the menu bar. In the example, menu items to open and save a specific tab are prepared.

== Method 2 : dedicated buttons ==
If you prefer buttons instead of menu, you can put dedicated buttons to trigger "OpenPad" function in the example instead of adding menus. The buttons can be implemented 
either of the following two methods,
 1) TGTextButton, which can work as the same way as your Save button
 2) Writing own class derived from TBox or TMarker. A box or maker can be put on each canvas.

I hope the first method is obvious for you. You can make another button similar to your Save button and call "OpenPad" function.

The second method is a little more complicated; you make your own class and override "ExecuteEvent" method.
In the overriding function, you can call any functions when the box or marker is single-clicked, double-clicked, mouse-over and so on.
A disadvantage is that the box or marker is always visible, and will be drawn in the output PDF files too.

== Method 3: click on Pad ==
You can probably do what you write with making own class derived from TPad; then you override "ExecuteEvent" function for calling a function to make a separated canvas and 
draw a clone of itself.
You may also need own TCanvas and TRootEmbeddedCanvas for using the customized classes instead of regular TPad and TCanvas.

If you are satisfied with the first method, please try the example.
The second method with TGTextButton must not be very difficult.

If you prefer the second (using TBox or TMarker) and third method, I will investigate if it is actually possible.
For the two methods, I think you need to write your own classes.

Best regards,

Ryu

> Dear Colleagues,
> 
> We are succesfully running a ROME executable both online and offline with an 
> ARGUS display with a canvas that has multiple pads on it. We have also 
> implemented a "Save" button which one can click on and save the _entire_ canvas 
> (containing all the pads) and saves it to pdf.
> 
> I was wondering how one would go about making the following modification :
> 
> When a user moves a mouse over to a particular pad and clicks on it - then only 
> the histogram on that pad is displayed on a separate canvas (so the user can 
> examine it closely) and also save just this one histogram - with a save button 
> similar to the one we've already written.
> 
> many thanks for any insight
> 
> Farrukh 

Dear Colleagues,

We are succesfully running a ROME executable both online and offline with an 
ARGUS display with a canvas that has multiple pads on it. We have also 
implemented a "Save" button which one can click on and save the _entire_ canvas 
(containing all the pads) and saves it to pdf.

I was wondering how one would go about making the following modification :

When a user moves a mouse over to a particular pad and clicks on it - then only 
the histogram on that pad is displayed on a separate canvas (so the user can 
examine it closely) and also save just this one histogram - with a save button 
similar to the one we've already written.

many thanks for any insight

Farrukh 

   Int_t sec = GetSP()->GetSleepTime();

   if (sec > 0) {
      struct timespec req, rem;
      req.tv_sec = 0;
      req.tv_nsec = 100000000; // sleep time in loop

      struct timeval endTime, currentTime;
      gettimeofday(&currentTime, 0);
      endTime.tv_sec = currentTime.tv_sec + sec;
      endTime.tv_usec = currentTime.tv_usec;

      int ret;

      while(1) {
         memset(&rem, 0, sizeof(rem));
         ret = nanosleep(&req, &rem);

         gettimeofday(&currentTime, 0);
         if (currentTime.tv_sec > endTime.tv_sec ||
             (currentTime.tv_sec == endTime.tv_sec && currentTime.tv_usec > endTime.tv_usec)) {
            break;
         }

         gSystem->ProcessEvents();
      }
   }

     <Task>
  ... other definition of tasks ...
        <SteeringParameters>
          <SteeringParameterField>
            <SPFieldName>SleepTime</SPFieldName>
            <SPFieldType>Int_t</SPFieldType>
            <SPFieldInitialization>10</SPFieldInitialization>
            <SPFieldComment>Sleep time in sec</SPFieldComment>
          </SteeringParameterField>
        </SteeringParameters>
     </Task>

> I have succesfully written a ROME application ...

For the record, at TRIUMF we have moved away from ROME towards the ROOTANA ROOT-based analyzer 
package which has some simple C++ classes for reading midas raw data, some simple classes and examples for 
working with midas data in ROOT, and some fairly advanced graphical example applications.

https://bitbucket.org/tmidas/rootana

K.O.

  graph->Draw("APL");

Dear Farrukh

The 'histoGUI' example was prepared as an example for displaying histograms.
And the data are generated randomly in FillHisto task instead of reading from an input file.
So the example is using 'none' DAQ as written in romeConfig.xml in the example; the DAQ class is 
implemented in include/ROMENoDAQSystem.h, and it actually does nothing.

With 'none' DAQ, the program simply call Event method continuously without any control of the frequency.

When you run the example, the frequency is not so fast because the CPU is used for updating the display.
If you change <UpdateFrequency>, for example, to 10000, you will find the frequency of events through 
the task is increased because you update the display with a less frequency (thus lower CPU power is 
needed).

If you are going to use ROME for non-event based application, there are two ways to call some functions 
defined in tabs.
1) With GUI parts, like buttons, menus, sliders and so on
2) With calling a function periodically.

1) is suitable if you want to actively control the GUI; a user needs to, for example, click a button for 
operate the tab.

2) is suitable if you want to update the display without any operations.
You can see examples/argus/timer/ and examples/argus/thread as examples.

Best regards,

Ryu

> Dear Colleagues,
> 
> I have succesfully written a ROME application for monitoring MIDAS events and 
> understand that the appearance of a new MIDAS event record triggers the calling 
> of the event method in the Fill Histogram task.
> 
> My two questions are however about the example in $ROMESYS/example/histoGUI - 
> 
> 1) In this example there is no MIDAS event nor event record - what then is 
> triggering the calling of the event method 
> 
> 2) Is it possible to regulate the frequency that the event method is called in 
> this example ?
> 
> best wishes
> Farrukh Azfar

Dear Colleagues,
 
I have been using the ROME framework and have succesfully implemented a program 
to run on MIDAS input and plot histograms.

Not satisfied with the default settings of the Canvas, pads and text sizes etc I 
consulted Ryu who kindly showed me how to implement the event and init and update 
methods in the Tabs to bring the display closer to what I needed.

This has worked fine with histograms. However not with TGraphs:

I noticed that if I implemented the plotting of the TGraphs in the tab class then 
after setting points in the TGraph in the Fill tasks the Tab classes plot was 
empty -> is there something peculiar about TGraph ? Any tips would be great !

many thanks
Farrukh Azfar

Dear Colleagues,

I have succesfully written a ROME application for monitoring MIDAS events and 
understand that the appearance of a new MIDAS event record triggers the calling 
of the event method in the Fill Histogram task.

My two questions are however about the example in $ROMESYS/example/histoGUI - 

1) In this example there is no MIDAS event nor event record - what then is 
triggering the calling of the event method 

2) Is it possible to regulate the frequency that the event method is called in 
this example ?

best wishes
Farrukh Azfar

> I was wondering what type of license, if any, applies to the Rome distribution.
> Midas is using GPL and Root is using LGPL.

Midas uses GPL because when I started that project, the LGPL was not yet in
existence. If anybody want Midas under the LGPL, I could consider switching that.
ROME is under the LGPL.

I was wondering what type of license, if any, applies to the Rome distribution.
Midas is using GPL and Root is using LGPL.

Error in <TBuffer::CheckByteCount>: object of class PMTData read too few bytes: 21 instead of 169

<Experiment>
   <ExperimentName>MEG Analysis and monitor.</ExperimentName>
   <ExperimentShortCut>MEG</ExperimentShortCut>
   <ProgramName>Analyzer</ProgramName>
   <ProgramDefinitionVersion>3</ProgramDefinitionVersion>
   <FrameworkDescription>MEGAnalyzer is an analysis framework for MEG. It works as monitor as well.</FrameworkDescription>
   <DictionaryType>0</DictionaryType>   <!-- Add this line -->
</Experiment>

> > > > I just started using Rome v2.7 and Root v5.14.00. I have run into a rather
> > > > interesting issue trying to compile my analyzer. I tracked the problem to the
> > > > fact that both Root and Rome are loading their own version of a header file
> > > > called TArrayL64.h.
> > 
> > I have just run into the TArrayL64.h problem myself. I recommend that we resolve
> > the clashing header files. We could ask Rene Brun to rename his file or we could
> > rename the clashing file in Rome.
> > 
> > K.O.
> 
> As Matthias mensioned, this problem is solved in SVN version of ROME.
> I propose to release ROME version 2.8, which will not have this problem.
> 
> If there are users who want to continue to use 2.7, we could also release patch release of 2.7. (2.7.1), in which only compatibility problems 
> are fixed.

I prepared a new release 2.8. It can be downloaded from http://midas.psi.ch/rome/download.html

The new release works with also ROOT 5.14 or 5.15.

At this release, style of configuration file was changed. Please see following message for details. 
https://ladd00.triumf.ca/elog/Rome/129

> > > I just started using Rome v2.7 and Root v5.14.00. I have run into a rather
> > > interesting issue trying to compile my analyzer. I tracked the problem to the
> > > fact that both Root and Rome are loading their own version of a header file
> > > called TArrayL64.h.
> 
> I have just run into the TArrayL64.h problem myself. I recommend that we resolve
> the clashing header files. We could ask Rene Brun to rename his file or we could
> rename the clashing file in Rome.
> 
> K.O.

As Matthias mensioned, this problem is solved in SVN version of ROME.
I propose to release ROME version 2.8, which will not have this problem.

If there are users who want to continue to use 2.7, we could also release patch release of 2.7. (2.7.1), in which only compatibility problems 
are fixed.

Ryu