EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2012  2013  2014  <20152016  2017  2018  2019  Index 2012  2013  2014  <20152016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: QEForm
From: Zenon Szalata <[email protected]>
To: Andrew Rhyder <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 21 Apr 2015 15:26:19 -0700
Hi Andrew,
I see one more new behavior, which might be due to the new version of epicsQt. I launched a GUI, which has number of Qt and epicsQt widgets. In this GUI, I have a QPushButton, which is used to launch another GUI, call it a daughter GUI. It is a standalone QDialog based application. In this GUI I have a "Close" QPushButton which is used to close the application. This is done by calling close() function from a slot connected to a clicked() signal of the Close button. All seem to work as expected, except when I close the the daughter GUI, I get the following message:

QXcbConnection: XCB error: 3 (BadWindow), sequence: 727, resource id: 11639784, major code: 15 (QueryTree), minor code: 0

I think XCB was required for Qt 5.x and it might be that it has nothing to do with epicsQt. Have you seen this error?
Thanks,
Zen

On 04/21/15 04:56, Andrew Rhyder wrote:
Hi Zen
I have added the following function to QEForm:
	QWidget* getChild( QString name );

This is basically a call to findChild, but will not fail if the ui has not been loaded (it will return NULL)


And the following signal has been added:
	void formLoaded( bool fileLoaded );

This signal will be emitted when loading the ui file has completed (or failed).

I don't think you will be getting the "No such slot" error, but I'm not sure I was reproducing the error in the same way you were. Let me know.

You can try out the current trunk version:
	svn checkout svn://svn.code.sf.net/p/epicsqt/code/trunk epicsqt-code

Regarding the requestAction signals, they are part of the way QE widgets can interact with applications. Normally an application is built against a .ui source file, or loads a .ui file that is closely associated with the application, and that is fine. The epicsqt framework, however, has mechanisms to allow any application, but specifically QEGui, to load any .ui file, and then interact with and respond to any QE widgets within the .ui file. So a QEPushButton in the .ui file can ask the application to open an associated display in a dock, or the application can ask a named QEImage widget that may be in a .ui file to change its zoom level.
If you're interested, all the mechanisms used by the QEGui application to interact with QE widgets at a distance are available for any application to use - responding to requests from QE widget, hosting menu actions on behalf of QE widgets, User levels, logging of messages from QE widgets, saving and restoring current QE widget configurations, custom menus.
Guess I should document it better. The class documentation is part way there... Currently the best documentation is to use the QEGui application as an example.

Regards
Andrew


-----Original Message-----
From: Zenon Szalata [mailto:[email protected]]
Sent: Monday, 20 April 2015 12:06 PM
To: Andrew Rhyder
Subject: Re: QEForm

Hi Andrew,
So far, I needed the ui pointer to obtain address of some of its child widgets.  I suppose it would be more convenient for me if you provided a public function to get an address of a child widget (returning QWidget*); the child widget could Qt or QE.
The reason for the signal is so that I know when the ui pointer has a valid address.
I have another question, which could be related to this.
When I create a ui file with Designer which uses QEForm to load another ui file, I get these messages in the terminal window from which the Designer was launched:

QObject::connect: No such slot QEForm::requestAction( const QEActionRequests& )
QObject::connect:  (receiver name: 'qeform_16')

After this ui was built into an application, I would get the same messages when the application was being launched.  I eliminated these messages by adding to my mainwindow.h #include "QEActionRequests.h"
and a dummy definition of the slot:
void requestAction( const QEActionRequests&){}

Now, I have no idea what is this slot for?  I did not look very hard to understand this, but I did not find an explanation for this.  I see that requestAction slot is not used explicitly in QEForm, but is referred to in QEWidget.  Anyway, I would like to understand what is it for and what should I really do with it?
Thanks Andrew,
Zen

On 04/19/15 04:43, Andrew Rhyder wrote:
Hi Zen

Happy to make the changes you require. A couple of questions though:
Do you use the ui pointer for anything else, or would you like QEForm to simply return the named widget  (using 'findChild' internally).
I will add a signal to QEForm 'fileLoaded' in the internal function QEForm::readUIFile(). Is there anything needed to be passed in the signal?

Regards
Andrew

-----Original Message-----
From: Zenon Szalata [mailto:[email protected]]
Sent: Friday, 17 April 2015 5:32 AM
To: Andrew Rhyder; Dunning, Michael; [email protected]
Subject: QEForm

Hi Andrew,
I finally got a chance to return to my issue with QEForm.
Description of problem:
A typical usage of QEForm widget is to display a ui file created with designer.
Often I need to have access to a widget, which is a child of the ui object, from the parent of the QEForm object.

This is what I have done to test how this could be accomplished.
1. I modified QEForm.h file where I added a public function
       QWidget* getUiHandle(){ return(ui);}

2. In my test program I can then get address of the widget in question using
       MyWidget*
mywidget=qeform->findChild<MyWidget*>("mywidgetobjectname");

This works, but there is no convenient way to tell when the ui pointer in QEForm object gets a valid address.

I am asking if you could make the following modification to QEForm:

1. add a public function to QEForm.h, something like what I did for testing.

2. add a signal which would be emitted when QEForm is ready for action.

Thank you Andrew,
Zen


References:
QEForm Zenon Szalata

Navigate by Date:
Prev: QEForm Zenon Szalata
Next: Discussion of caQtDM at upcoming EPICS meeting? Keith Thorne
Index: 2012  2013  2014  <20152016  2017  2018  2019 
Navigate by Thread:
Prev: QEForm Zenon Szalata
Next: Discussion of caQtDM at upcoming EPICS meeting? Keith Thorne
Index: 2012  2013  2014  <20152016  2017  2018  2019 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·