gROOT->ProcessLine in child window

Hi All,
I have discovered that ProcessLine actually does entire scripts and this is exciting. Even better would be if I could run scripts inside an existing canvas or MFC child window. I suspect that QT4 would make this easy but I am using MFC and I don’t know how far away QT4 may be. Any suggestions?
Cheers,
Steve

Could you explain better what you are trying to achieve?

Rene

Rene,
Our version of the MFCRoot applilcation posts compiled histogram code in a child window. We can now flip from one canvas to another in that window. We would like be able to flip to “external” cint scripts (wriitten by customers, perhaps) in the same window. Process line now brings up a seperate window that can obscue important elements of our windows GUI.
Regards,
Steve

Hi Steve,

What do you mean by “post compiled histogram” ?

Sure, if the script creates a new canvas, it will be created outside MFC application (there is no way to change this)

Maybe it would be much simpler to describe exactly what you want to do, and maybe post your MFC application here or privately (bertrand.bellenot@cern.ch), so I will be able to help more (maybe), depending on what you expect…

And AFAIK, Qt will not help.

Cheers,
Bertrand.

Hi Rooters,
We are still testing our application in-house but as soon as we publish demos I will post them. I thought that there was no way to prevent the interperated script from building a new canvas but it was worth asking. Thanks again,
Cheers,
Steve

[quote=“salam”]Hi Rooters,
We are still testing our application in-house but as soon as we publish demos I will post them. I thought that there was no way to prevent the interperated script from building a new canvas but it was worth asking. Thanks again,
Cheers,
Steve[/quote]Do you want your script to create the “embedded” into your GUI TCanvas with the regular “decorated” “new TCanvas” ?

May be what you should do is to create the “Embedded” TCanvas
in advance with some “dedicated name”. Then from your script you should not create another TCanvas rather you should make the “embeded TCanvas” with the known name to be the “current” one. Afterwards all drawing (i.e. all TObject::Draw()) will go to that TCanvas.
Let’s assume you created the embedded TCanvas and called it “em”. Then from your script you can use it to render your objects with the two lines of the code

TCanvas *c = (TCanvas *)gROOT->GetListOfCanvases()->FindObject("em") c->cd();I think this technique should work with either technology MFC ,Qt3, Qt4, X11 whatever. Another solution would be to complement the ROOT with your own simple function that will create either the normal TCanvas or the embedded one depends of the your run-time environment.

[quote=“salam”]We can now flip from one canvas to another in that window. We would like be able to flip to “external” cint scripts (wriitten by customers, perhaps) in the same window. Process line now brings up a seperate window that can obscue important elements of our windows GUI.
[/quote]If you know the name of your canvas you can do that with the technique I described with the previous post. The only problem, you should “forbid” your customer to create his/her own TCanvas at all. I.e. your MFC application should domyMFCCanvas->cd() gROOT->ProcessLine("execute the customer script");You can see how it works with the examples from Qt distribution. However, as soon as the possibility to draw into the “embedded” TCanvas from the “external” script is concern these examples have no Qt specific. The approach should work for either technology. Let me repeat that the only constrain is, the script should not create any TCanvas alone. If that does not fit your needs then you may have looked for the more elaborated solutions but … first try that.
To implement what I have been explaining you need to write no line of the code. You should just remove :bulb: “new TCanvas” from your scripts.

Hi Rooters,
It works well! Thank you all.
Cheers,
Steve

Hi Rooters,
I am now being asked to run a script with GUI buttons from inside our MFCRoot application. It all works, but the Frame can obscure important parts of the application.
a) How can we (a) keep the frame from moving?
or better yet
b) force the new frame and canvas to occupy an already created window? Perhaps the previous posts in this thread will make it clear what we need.
Cheers,
Steve Alam

[quote=“salam”]. . . It all works, but the Frame can obscure important parts of the application. [/quote]Can you upload some screenshot. It is not clear yet how it can obscure anything. Are you saying the “TCanvas” frame becomes larger of its own parent widget?

Hi All,
Attached is a screen shot in which the script run from within MFC, unlike scripts that use pre-established canvases, does not overlay the data canvas as we wish.
Regards,
Steve Alam


The new frame has nothing to do with ROOT has it?.
If my guess above is correct then you have some bug in your MFC code which is not ROOT related. You can place any other widget instead of TCanvas and get the same effect. Can you reproduce that?

Hi All,
The script that produces the frame is indeed run via processline from within MFC - without creating a TGMainFrame it seems that I cannot access GUI components. I can use an existing canvas (see the earlier parts of this thread) to use only the upper left hand portion of the display. I don’t know how to do this when creating a GUI frame.
Regards,
Steve

Dear Valeri and All,
I am goint to spend a week or so on an island where I will consider no unit of time less than a day. Please don’t rush to respond to the MFC/GUI question.
Cheers,
Steve

[quote=“salam”]The script that produces the frame is indeed run via processline from within MFC - without creating a TGMainFrame it seems that I cannot access GUI components. I can use an existing canvas (see the earlier parts of this thread) to use only the upper left hand portion of the display. I don’t know how to do this when creating a GUI frame.[/quote]I think one has to understand yet what you are speaking about. I have no clue what do you mean speaking “GUI frame” / “frame is run via processline” . I am wondering if the GUI frame in question is the visual representation of some C++ class instance. Which one? What did you expect to see within that frame? Why the frame floats alone? Did you do this deliberately? and so on.

Hi All,
My holiday was very nice and very needed. The problem is not ROOT or MFC but me! When I create the TGMainFrame with TGMainFrame(gClient->GetRoot(), 100, 100) I want it to replace the canvas in the upper left hand portion of the MFC application. There are two reasons for this: 1) we don’t want to clutter up the GUI with extra windows and 2) we hope in time to incorporate all of the “outside” MFC functions into the window and do away with MFC. Right now the MFC application “passes” mouse clicks on to Root - I had hoped that running scripts with widgets might simplify this issue.
Steve