A few design questions...
-
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?
-
[quote author="mzimmers" date="1305903192"]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.
[/quote]Do you want your filter loop to run 1024 times per Soc simulation cycle but still be able to see the results? If so then you need to allow some time for the event loop to run each time around the loop (or every n-iterations around the loop).
This is done by calling qApp->processEvents() somewhere in your loop. This allows control to return to the event loop breifly so that it can process paintEvents (amongst other things). Try inserting a call to qApp->processEvents after yoru call to setShaperIOut() in your loop.
You'll notice that this will still be too fast to see much. If you want to slow it down then you could refactor your code to use another timer. Be careful of how this would interact with the other timer that kicks off the Soc simulation loop though.
What are you trying to achieve?
A simulation that runs as fast as possible with state updated in a GUI now and then. or
a simulation that is deliberately slow in order to allow humans to see each and every step at a sane rate?
[quote author="mzimmers" date="1305903192"]
How does it know to do this? Automatic black magic within QML via the routine naming convention?[/quote]No it is not black magic. It is because you emit the notifier signal in this function:
@
void DemodShaper::setShaperOutI(long i)
{
if (shaperOutI != i) // only emit signal if value has changed
{
shaperOutI = i;
emit shaperOutIChanged();
}
}
@and in your ctor you have connected that notifier signal to the notifier signal for the hex formatted string property:
@
DemodShaper::DemodShaper(QObject *parent, long rv) :
QObject(parent),
cellArrayI(NBR_CELLS, Cell(rv)),
cellArrayQ(NBR_CELLS, Cell(rv)),
shaperOutI(0)
{
connect (this, SIGNAL(shaperOutIChanged()),
this, SIGNAL(shaperOutIStringChanged()));
}
@The QML engine knows what property bindings you have made in your .qml file and so it knows which property notifier signals to connect to in order to be able to spot when an update is needed.
This all fits together such that when you set the shaperOutI property the QML engine calls the getter function for the hex formatted string property. The chain of events looks like this:
- call setShaperOutI(long i)
- signal shaperOutIChanged() is emitted (if value is different)
- signal shaperOutIStringChanged() is emitted (because of the above signal-signal connection)
- QML engine notices this and knows that in this eventuality it needs to update the properties in the qml file that are in some way bound to it. In order to update them it has to first fetch the new property value and so it calls the function shaperOutIString().
So you see. No magic. Just some clever plumbing ;-)
-
Ah, yes...good explanation of the chain of events. I still have trouble keeping all this clear in my head.
Regarding the delay timer: I'll want to do different things eventually, but right now, I'd be happy if each iteration of the test loop included a brief delay, just so the updated value can be observed for a moment. This isn't how it will run in production, but for now, there's value in having it work this way.
