A few design questions...
-
What about the part where you expose the object to the QML context? Also can you show how you get the pointer to the DemodShaperFilter object from the Soc object please? You mentioned something about not being able to use const or a pointer or something there?
-
The Soc class has a public function to return the address of the DSF object:
@ DemodShaperFilter* demodShaperFilter() { return &filter; }
@I'm not sure I remember "exposing" the DSF to QML. In my .qml file, there's a Connections block:
@ Connections {
target: soc
onShaperOutIChanged: {
if (myRect.color == "#808080")
myRect.color = "#c0c0c0"
else
myRect.color = "#808080"
}
}
@But I didn't see any code in my Soc class that tied the object to QML.
-
Somewhere we had something like:
@
view->rootContext->setContextProperty( m_soc, "soc" );
@which should now become something like:
@
view->rootContext->setContextProperty( m_soc->demodSHaperFilter, "dsf" );
@then in your QML scene replace all references of "soc" to "dsf".
-
Oh! That's in the widget constructor:
@Widget::Widget(QWidget *parent) :
QWidget(parent),
ui(new Ui::Widget),
m_timer(new QTimer(this)),
soc(new Soc(this))
{
ui->setupUi(this);connect (m_timer, SIGNAL(timeout()), soc, SLOT(runOneCycle()));
connect (soc->demodShaperFilter(), SIGNAL(shaperOutIChanged()), this, SLOT(updateShaperOutI()));
QDeclarativeView* view = ui->declarativeView;
view->rootContext()->setContextProperty("soc", soc);
view->setSource(QUrl("qrc:/DemodShaperFilter.qml"));m_timer->start(200); // 200 ms delay between cycles (for now)
}
@And, by "QML scene," you're referring to the .qml file?
-
-
OK, we're getting somewhere. I no longer get the error message at startup, and the QML window now comes up with the correct initial value of the variable. But...it's not updating. I have this line in my cycle loop for the object:
@ emit shaperOutIChanged();
@Which I believe should correspond with this line in my DSF constructor:
@ connect (this, SIGNAL(shaperOutIChanged()), this, SIGNAL(shaperOutIStringChanged()));
@So, I'm not sure what's missing.
Also, I'm confused about something: why is it we're still using some Soc functions for our QML processing?
@ ui->setupUi(this);connect (m_timer, SIGNAL(timeout()), soc, SLOT(runOneCycle()));
connect (soc->demodShaperFilter(), SIGNAL(shaperOutIChanged()), this, SLOT(updateShaperOutI()));
QDeclarativeView* view = ui->declarativeView;
view->rootContext()->setContextProperty("dsf", soc->demodShaperFilter());
view->setSource(QUrl("qrc:/DemodShaperFilter.qml"));m_timer->start(200); // 200 ms delay between cycles (for now)
@Thanks.
-
Where do you emit the shaperOutIChanged() signal? Can you post that snippet of code please? Have you run it in a debugger to make sure that emit is actually called? Do you get any runtime warnings on the console output?
Can you also post the qml file where you use this property please - although it sounds as if the QML is correct since you get an intiial value. Just sounds like the signal is not being emitted correctly which would trigger the QML engine to update the displayed value.
The only reason we are referring to the soc object is that it is the only way we can get at the pointer to the DemodShaperFilter object. Are you using it anywhere else in relation to displaying stuff in the GUI?
-
The shaperOutIChanged() signal is (currently) in the test loop for the DSF class. It loops 1024 times, processes the object and then executes this line (within the loop):
@ emit shaperOutIChanged();
@This routine is the one automatically generated within Qt, right?
Contents of the .qml file:
@import QtQuick 1.0
Rectangle {
id: myRect
width: 300
height: 100
color: "#808080"Text {
text: "shaperOutI = " + dsf.shaperOutIString;
font.pointSize: 20
anchors.centerIn: parent
}Connections {
target: dsf
onShaperOutIChanged: {
if (myRect.color == "#808080")
myRect.color = "#c0c0c0"
else
myRect.color = "#808080"
}
}
}@
The string is the conversion of the display value. As a reminder, we did this for formatting convenience. I copied all of that code directly from the Soc class to the DSF.
And no, I don't believe the DSF object is being used anywhere else for display purposes. The Soc invokes the DSF test loop, and that's about it.
Thanks...
-
-
Sorry for the delay, I must have missed the notification email. I'm not sure without seeing the source code. Are you able to zip it up and mail it to me so that I can take a look (I can sign an NDA if needed). Alternatively boil it right down to a very simple example that still shows the problem and send me that zip file.
-
OK. sorted it. I'll send the corrected file to you by email but explain it here.
Firstly in your loop in void DemodShaper::testCycle() you were emitting the signal as you said. However, you were nto actualy updating the member variable shaperOutI anywhere in that loop. So although you were emitting the signal and the QML backend was then in turn calling the property getter function, shaperOutIString(), that function was using the member variable shaperOutI which never changed from its default value of zero.
I have changed the last part of your loop to this:
@
/*
* print out the outputs of the filter for this loop iteration.
*/
cout.setf(ios::dec, ios::basefield);
cout << "Demod Shaper clock cycle " << i << ". ";
cout.setf(ios::hex, ios::basefield);
cout.fill('0');
cout << " iOut: " << setw(8) << getDemShpIOut() <<
". qOut: " << setw(8) << getDemShpQOut() << "." << endl;setShaperOutI( getDemShpIOut() );@
Note that I now rely on the setShaperOutI() function to emit the notifier signal - it also checks to make sure that the value really has changed.
As an alternative to this we could simple get rid of the member variable shaperOutI and change the getter function for that property to getDemShpIOut() however if that function does expensive calculations it is probably worth keeping it how it is with the shaperOutI member variable acting as a cached value.
With that sorted the application works fine. You can of course add a similar pair of properties for the quadrature variable and it shex representation.
The other problem I spotted (albeit a harmless one) was in the function setShaperOutI(long i). In here the call to shaperOutIString() is completely redundant as you do not do anything with the return value. This function then becomes:
@
void DemodShaper::setShaperOutI(long i)
{
if (shaperOutI != i) // only emit signal if value has changed
{
shaperOutI = i;
emit shaperOutIChanged();
}
}
@The other thing I would change would be to alter the function:
@
long Soc::getShaperOutI()
{
return filter.getDemShpIOut();
}
@to
@
long Soc::getShaperOutI()
{
return filter.getShaperOutI();
}
@so that it uses the cached value rather than calculating it all over again when updating the QLabel. In fact thinking about it you could remove this function completely and call getShaperOutI() directly on the DemodShaperFilter object since you can get a pointer to it via the Soc class. ie:
@
void Widget::updateShaperOutI()
{
long shaperOutI = soc->demodShaper()->getShaperOutI();
QString s = QString( "shaperOutI = %1" ).arg( shaperOutI, FIELD_WIDTH, HEX_RADIX );
ui->label->setText( s );
}
@Now you can add in similar properties for the quadrature values and pimp up the QML scene some more to impress your boss ;-)
Good luck!
-
Hey, Zap. That worked like a champ...thanks so much. A few comments:
The reason I was using shaperOutIString() was to gain some control over the format of the output. I did remove it, though, and...my formatting is magically how I want it. I guess I made another fix to this somewhere else.
I'd like to move the timer out of the widget and into the test loop (or at least copy it). But...I don't think I'll put it in the constructor of the filter, will I? seems like it should be in the testCycle loop.
Also...it seems as though there's an unnecessary level of indirection here, using the SoC to get to the filter. Since I'm going to be replicating this with other kinds of filters, should I be devising a scheme to allow the widget to directly access any objects with members on display?
Thanks again.
-
[quote author="mzimmers" date="1305900771"]Hey, Zap. That worked like a champ...thanks so much.
[/quote]
No problem. ;-)[quote author="mzimmers" date="1305900771"]
A few comments:The reason I was using shaperOutIString() was to gain some control over the format of the output. I did remove it, though, and...my formatting is magically how I want it. I guess I made another fix to this somewhere else.
[/quote]The reason is that the QML engine automatically calls the shaperOutIString() function for you when it is notified that it's value has changed. Set a break point in that function and run it then look at the call stack. You'll see that the calls originate from within the QDeclarative.dll module.
[quote author="mzimmers" date="1305900771"]
I'd like to move the timer out of the widget and into the test loop (or at least copy it). But...I don't think I'll put it in the constructor of the filter, will I? seems like it should be in the testCycle loop.
[/quote]That's entirely up to you. Putting it in the Soc class would seem a reasonable place to me but I do not have as much info as you about what you are trying to do.
[quote author="mzimmers" date="1305900771"]
Also...it seems as though there's an unnecessary level of indirection here, using the SoC to get to the filter. Since I'm going to be replicating this with other kinds of filters, should I be devising a scheme to allow the widget to directly access any objects with members on display?
[/quote]Well all we're doing is exposing a pointer to the filter object by means of an accessor function on the Soc class. Picture it as a hierarchical system. The Soc class (system on chip?) contains a number of subsystem objects, one of them is DemodShaperFilter in this case, which in turn could provide access to an even lower level of components.
If you GUI only starts off with a pointer to the Soc object then the two obvious ways of getting at the properties of the sub or sub-sub systems are:
- provide getter functions that provide pointers to the lower-level (children) objects - this is what we have done here OR
- provide a set of simple forwarding functions that provide access to the properties directly from the top-level Soc object.
Option 2 leads to a lot of boring code to write like:
@
long Soc::myCoolPropertyOfGrandChild()
{
return m_childObject->myCoolPropertyOfChild();
}
...
long ChildObject::myCoolPropertyOfChild()
{
return m_childOfChild->myCoolProperty();
}
@This quickly leads to lots of code and a huge API to the Soc class with likely naming collisions.
Sometimes it is useful to hide internal implementation details this way but in your case I think it would be of no real benefit.
[quote author="mzimmers" date="1305900771"]
Thanks again.
[/quote]You're welcome.
-
Good points made, Zap.
Regarding the timer: as you know, my testCycle routine loops about 1000 times. I just wanted to put a small delay in there, so that you can watch the GUI update the figure. Right now, it happens so fast that you only see the final value.
bq. The reason is that the QML engine automatically calls the shaperOutIString() function for you when it is notified that it’s value has changed. Set a break point in that function and run it then look at the call stack. You’ll see that the calls originate from within the QDeclarative.dll module.
How does it know to do this? Automatic black magic within QML via the routine naming convention?
