I am working on a compiled GUI application. I have noticed that for all my popup windows that have a TGTextEntry or a TGNumberEnrty crash if they are closed (by the x-button or any close button I implemeted) while any TGTextEntry box is selected (the cursor blinking in it), even without changing anything. If instead I click anywhere outside a TGTextEntry so they lose the focus, and then close, everything works fine.
The crash output is the following:
Error in <RootX11ErrorHandler>: BadWindow (invalid Window parameter) (TGTextEntry XID: 75498517, XREQ: 61)
TGTextEntry: 75498517
TGHorizontalFrame: 75498515
*** Break *** segmentation violation
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
Attaching to program: /proc/31242/exe, process 31242
[Thread debugging using libthread_db enabled]
[New Thread 182957927840 (LWP 31242)]
0x00000033db98f5e4 in waitpid () from /lib64/tls/libc.so.6
#1 0x00000033db939a7f in do_system () from /lib64/tls/libc.so.6
#2 0x0000002a958fc6a1 in TUnixSystem::StackTrace ()
from /home/atlas/root/lib/libCore.so
#3 0x0000002a958f91ba in TUnixSystem::DispatchSignals ()
from /home/atlas/root/lib/libCore.so
#4 <signal handler called>
#5 0x0000000000000031 in ?? ()
#6 0x0000000000ac4f80 in ?? ()
#7 0x0000002a98c233ce in TGFrame::Print () from /home/atlas/root/lib/libGui.so
#8 0x0000002a9946b02e in RootX11ErrorHandler ()
from /home/atlas/root/lib/libGX11.so
#9 0x00000033dc03ff88 in _XError () from /usr/X11R6/lib64/libX11.so.6
#10 0x00000033dc04194f in _XEventsQueued () from /usr/X11R6/lib64/libX11.so.6
#11 0x00000033dc031861 in XPending () from /usr/X11R6/lib64/libX11.so.6
#12 0x0000002a98be92b8 in TGClient::ProcessOneEvent ()
from /home/atlas/root/lib/libGui.so
#13 0x0000002a98be939d in TGClient::HandleInput ()
from /home/atlas/root/lib/libGui.so
#14 0x0000002a98be93bd in TGInputHandler::Notify ()
from /home/atlas/root/lib/libGui.so
#15 0x0000002a958f9739 in TUnixSystem::DispatchOneEvent ()
from /home/atlas/root/lib/libCore.so
#16 0x0000002a95875b95 in TSystem::InnerLoop ()
from /home/atlas/root/lib/libCore.so
#17 0x0000002a9587594a in TSystem::Run () from /home/atlas/root/lib/libCore.so
#18 0x0000002a9581be0f in TApplication::Run ()
from /home/atlas/root/lib/libCore.so
#19 0x00000000004160a1 in main (argc=Variable "argc" is not available.
) at ../MainControlMenu.h:167
I guess it is because I am not handling a signal emitted when the box is selected. But I don’t need anything like that, I have a “Set” button that stores the changes instead. And as I said, this happens without any modification of the entry.
I include one of my window classes. Unfortunately it won’t work by itself but maybe someone will easily catch what I missed, most likely in the constructor/destructor.
You declare your class being (inheriting from) a TGTransientFrame, but then you use a TGMainFrame class member as main frame…
Where do you delete (cleanup) the GUI components?
When is your class deleted?
Anyway, can you try the following: In your class constructor, add this line: fMainFrame1819->SetCleanup(kDeepCleanup);Right after the fMainFrame1819 construction
Remove also all the lines where you add the check buttons to the button group (it is not needed and create problems a destruction time).
These are the lines beginning like this: fStatGroup->AddFrame(fCheckXXX, ...
Hope this helps
Hi, thanks for your reply. Setting kDeepCleanup worked with both of my troublesome windows! This raises a couple of questions though; is a quick-n-dirty workaround to remedy my already dirty code, or is it a requirement for windows that contain TextEntries?
To address your confusing points (and try to fish more advice!): I intended to extend the TGTransientFrame class since the Class AdcWindow describes an object of that type. I was lazy though and used the GuiBuilder and then I forgot to make the proper changes. That is fixed now, thanks, but it wasn’t the source of the problem. Nor was the adding of the check buttons to the buttongroup, but that was fixed as well.
Now, about destroying the objects of this class. Since I was intending to extend the TGTransientFrame class I thought I wouldnt have to overload the destructor since all the components are owned by the main frame object.
Now this leads to the following questions: Doesn’t the frame that owns the components destroy (delete) all the objects created and associated with it when you delete the frame?
Should I delete just the main frame (if I dont extend the class) or the individual components as well? And what is your advice about the declaration of the components: Should they be declared globally in the class definition, or just locally in the constructor (and not access them directly when let’s say a text entry is modified, but connect them to a function that stores the content somewhere else in the object)?
A lot of questions, I know. If anyone has time for advice, it would be useful for future projects.
It is a general rule, and has nothing to do with text entries. The symptoms appear with text entries because of their active focus
To inherits from TGTransientFrame, just do it, use proper constructor, suppress your fMainFrame1819 class member, remove all the “fMainFrame1819->” and replace the “fMainFrame1819” arguments by “this” in all the various methods. Then you can also remove the RQ_OBJECT(“AdcWindow”)
And using the guibuilder is OK, but it is not very good to keep several SetLayoutBroken(kTRUE), it would be better to use proper layout managers
That’s right, but you have to tell the main frame to delete these objects (user may want to delete them himself). This is actually the role of SetCleanup(kDeepCleanup);
See my previous answer: this is true if you use the SetCleanup(kDeepCleanup) method
See the two previous answers, I think they should clarify this point too. But don’t mix the different methods, to avoid double deletion!
It is purely users choice, but I would advice to keep class definition, for code clarity. And you can still use signal/slots, it is independent of the definition
But don’t mix the different methods, to avoid double deletion!