I am writing a C++ program that is using the ROOT libraries, which works fine. From the compiled C++ code, I would like to open a plot window (TCanvas) in the same way as it is done from the interpreter. What libraries should I link, and which code should I invoke for that?
Depends on which platform, but if not on Windows, this command:`root-config --cflags --glibs`
Will give you the right compilation flags and set of libraries.
You can also take a look at $ROOTSYS/test/Makefile for example
And for the canvas, the same commands can be used in a compiled program than in the command line⌠I would say something like this:
Then it could also be declared as member of one of you classes. But this is not specific to ROOT, just create your TCanvas like any other C++ object (class). Just take a look at examples in $ROOTSYS/tutorials and $ROOTSYS/test
Actually, I was able to solve part of the problem myself: I found out about the âTApplicationâ class, which allows me to open a TCanvas. However, once this is done, I get stuck with the open TCanvas window and cannot continue running the software. For example:
While running this, everything gets stuck just after the âtheApp.Run();â command, and I am never able to finish the program. What should I do for that?
As reported several times at this forum, you should simply use the standard root.exe and invoke your script (interpreted or compiled via ACLIC)
root > .x myscript.C (run via the CINT interpreter)
root > .x myscript.C+ (run using native code compiled by ACLIC)
The standard root.exe includes the event loop manager TRInt derived from TApplication. You can leave with the normal command â.qâ or by selecting âQuit ROOTâ from the canvas âFileâ menu.
In your case where you use simply a TApplication, you can leave the application via the canvas âFileâ menu.
Thanks, but I know that already. In this case, I am developping a standalone application that I am compiling outside of the ROOT interpreter for other purposes. I would like to use the ROOT plotting tools inside.
It does not matter if you develop a âstandaloneâ application or not. It also depends what you mean by âplotting toolsâ. If you simply need to produce histograms or pdf, ps files in batch, you do not need classes like TApplication, TRint.
BUT, if you want to interact with your canvases, you need a TApplication (or better TRint).
So far, I have not seen any single case where writing a main program was justified :
I am an astronomer, and in astronomy the data are generally stored in so-called FITS files. There exists an API called CFITSIO that makes it possible to access FITS files from C++ programs (but not from ROOT).
My goal here is to provide to the people of my institute a software that would do interactively some tasks specific to astronomy. To do that, I have to access FITS files, and therefore I need to use CFITSIO. But since I am familiar with ROOT for computational tasks and to display the results (so, yes, I need to interact with the canvases). For this reason, I need to make a standalone application. I hope you understand the reason a bit better.
Could you please explain me (or point me to the appropriate documentation) how the TApplication and/or TRint classes should be used?
We have plenty of CFITSIO ROOT-based applications.
(most of them from BNL lsst.org/lsst LSST group).
It is used the way Rene has described
Let me know if you have any CFITSIO ROOT specific questions.
You can create your own application using the ROOT libraries, eg creating, filling histograms, trees, saving them in a ROOT file.
You need to include a TApplication (or TRint) object if you want to interact with the canvas,
have menus, edit graphics objects.
[quote=âLuke_Kâ]Since I am also interested in this kind of things:
So does it mean that I canât create a standalone project which includes ROOT libraries, if I want interactivity?
But I can create an application which includes ROOT libraries and the interactivity is not due to ROOT objects.
So I should be fine if I do fitting, histogram creation and writing a ROOT file
without using CINT, right?[/quote]It doesnât matter how you create the main subroutine. Either way, ROOT libraries use the CINT facilities internally. This means creating your own so-called stand-alone application you are asking for the extra troubles and gain nothing.
You always can start ROOT in the batch mode from the shell script. This way no interactive session (ROOT / Cint command prompt) is created (is it your concern?)root.exe -b -q -l 'MyScript.C++("my parameters")' This is how we use it to process our data.
Your script can use any interactive tools. There is no constrain.
-b option stands for the âbatchâ. The âbatchâ term means ROOT doesnât not use the real screen to render its object.
The option â-qâ means that the ROOT session is to be terminated automatically as soon as your script ends.
If you need ROOT graphics omit -b and use
Just for info, Pyroot uses extensively the information in the CINT data structures.
So, even if you do not use CINT at the command line, you still use behind the scene.
[quote=âLuke_Kâ]. . .
Since I can write PyROOT applications without using CINT explicitly (i.e. by âpython myprogramâ) I thought the same should be possible with C++:
. . âŚ
So the best option I came across so far is to build the Application with#myApp.py
gROOT.SetBatch(True)
gSystem.CompileMacro("MyROOTApp.cc","k");
from ROOT import MyApp
app = MyApp()
app.SetParameter1()
...
app.run()This I can start without calling the CINT explicitly and it behaves like a stand alone application.[/quote]
Well, the best solution to make your application to behave like stand-alone application is to use the shell script myApp.
It requires ONE (at most) shell command instead of your 5 (at least) âpythonâ statements (+ redundant Python and PyROOT env + the Python language knowledge + knowledge of the Python /C++ binding + etc +etc ).
With your favorite text editor create the âmyAppâ text file:
#!/bin/sh
root.exe -b -q -l 'MyROOTApp.cxx+("'$1'")' Make it âexecutableâ:chmod +x myAppAssuming âMyROOTApp.ccâ:
[quote=âLuke_Kâ]âŚ
I see no difference to my python method, which for me is easier to handle. . . . [/quote]I prefer the cheapest way. I do see the difference: