GUI: How to emit signal when deleting draw object?

ROOT
1

Hello,

I’d like for my GUI to execute a method when a draw object is deleted from the embedded canvas interactively by the user. I tried to connect my method to the “Modified” signal (see below), which works fine whenever the canvas is being modified (e.g. after the draw object has been moved). Unfortunately, deleting a draw object interactively by right-click does not lead to a “Modified” signal to be emitted, so it’s no good for me.

Any suggestions on how to solve this?

Cheers
Greg

fEmbCnv       = new TRootEmbeddedCanvas("embCanvas", fMain, 512, 512);
TCanvas *fCnv = new TCanvas("Canvas", 10, 10, fEmbCnv->GetCanvasWindowId() );
fEmbCnv->AdoptCanvas(fCnv);
fCnv->Connect( "Modified()", "MyClass", this, "DoSmthImportant()" );
2

It is not that easy to do. Right now, if you modify a drawn object interactively on screen using the mouse, a signal “Modified()” is emitted from the method ExecuteEvent() of the drawn object (see for instance TLine.cxx).
Which means that if you change the TLine drawn in the current canvas using a command typed at the root prompt you will not get the signal (ExecuteEvent() is not called in that case). The obvious place to emit a signal when an object is deleted would be in the object destructor. But this may have very bad side effects. In particular the signal will be emitted in all cases, even when the object is deleted from C++ code. We cannot do that. So unless you have a better idea we will not change this behavior.

3

No, doesn’t sound like a good idea.

One more thought: It apparently makes a difference whether you delete the object from c++ code or by mouse-click. In the first case the object will remain visually on the screen for as long as I don’t touch the canvas in any way. In the second case the object disappears immediately, so I reason that the mouse event also causes an “Update”…?? If so, would it be possible to sneak a “Modified” in there as well?

4

In my case the object disappeared immediately in both cases
I tried with a TH1F.

5

Just tried from command line and, too, the ellipse disappears right away:

root [0] TCanvas c
root [1] TEllipse e(0.5, 0.5, 0.1, 0.1)
root [2] e.Draw()
root [3] e.Delete()

In my standalone executable GUI and on top of a TImage, however, not so.

Anyways, can’t really be bothered and will create some sort of “Delete object” button to invite the user to refrain from mouse-click delete.

6

For me TEllipse behaves like TLine. I can delete it from the command line or using the pop up menu…

7

Sorry if I wasn’t clear enough in my last post: Yes, if running an interactive root session it doesn’t matter at all whether you use command line or popup menu (and also not whether you talk TLine or TEllipse). Thanks for confirming that. My point was: When running a g++ compiled standalone executable gui it does make a difference!

If the delete command is called by some method in the code (say, when pressing a gui button), the embedded canvas is NOT automatically updated - I have to add a “canvas->Update()” to the method to see a difference on the screen. But after mouse actions there will always be an automatic canvas update.

So my hopeful reasoning was: If there is some code snippet somewhere in the guts of the ROOT framework handling the mouse activity and calling the “Update()”, I could find this little bit, add a “Modified()” hence generating the signal I was looking for in my original post.

If this is sounds like wishful and misguided thinking, then let’s not waste time going deeper into it and close this thread…

Cheers

8

In fact tin the action method called when you press your DELETE button you should put Modified () and Update().
Nobody will do it for you.

9

We do have funny conversations sometimes, don’t we? :wink:

I know my button will do what I want. In addition to that, the obsessive-compulsive developer in me was trying to get a handle on unwanted user mouse-click deletes. Since they don’t go along with a signal they remain unnoticed unless I constantly check how many draw objects are present on the canvas which might be a bit expensive.

I’ll do some breathing and let it go… :slight_smile:

10

Hi,

One possible solution would be to remove the “Delete” entry from the context menu of all graphical object’s classes… See for example [url=https://root-forum.cern.ch/t/remove-or-block-some-items-of-the-tcanvas-contextmenu/13382/1 thread[/url]

Cheers, Bertrand.

11

Haha, this buddhist stuff works: If you let your problem go, you open the door for a creative solution… :smiley:
What a great idea - I would not have been looking at that! Thanks a lot!

12

Yes, It took a bit of time to understand what you really want ! :slight_smile:
we finally managed … :slight_smile: