How to choose radix in QML text?

[andre]

Well, if you want to build your whole app in QML, then you're going to need Javascript for the business logic. If you build your business logic in C++ on the other hand, and expose that as an object to the QML using properties and signals & slots, you are not going to to need much javascript. You only need to bind some properties in the QML then.

[mzimmers]

I'm definitely writing the app in C++; the QML is for display only. But, I'm not sure I know what you meant by this:
[quote]Easiest way is of course to make sure the ouput you get from soc.shaperOutI is in the right notation to begin with.[/quote]
If you could elaborate, that would be great.

[andre]

Well, I am assuming soc is some QObject you exposed, and shaperOutI is a property of that object. If that is the case, why not create a shaperOutIHex property instead, make that property a QString, and simply make the hex value in C++ using QString?

[ZapB]

I agree with Andre. Just add an extra property that exposes a hex formatted string version of the value in addition to the actual numerical value. Then use that in your QML scene if that is what you want to decide. It's just easier this way since you have all the handy QString/QByteArray functions to convert between various formats.

ps. You could do it with javascript in QML but why reinvent the wheel?

[mzimmers]

OK, I can do that (I think). There's a slight rub in that the value of shaperOutI gets changed in a few places, a couple of which are function calls. Right now, I only see two ways to keep the string updated:

1. do the QString processing immediately after each assignment of the int
2. redefine shaperOutI as a class, and override the assignment operator to incorporate the string processing.

The former seems pretty crude, and the latter strikes me as overkill. What's your opinion(s) on this?

[andre]

Is my assumption that soc is a QObject derived class and that shaperOutI is a property of this object correct? If not, please tell us what these are exactly then.

If so, then you can simply extend your class. You would need to add another property. You can use signals and slots within your class to update the string representation if the integer representation changes.

[mzimmers]

Hi, Andre -

Yes, your assumption is correct.

So, do I correctly understand your suggestion that I should put a connect statement in the constructor of my Soc? In my Widget constructor, I have this line:

@ connect (soc, SIGNAL(shaperOutIChanged()), this, SLOT(updateShaperOutI()));
@

So, I could modify it something like:

@ connect (soc, SIGNAL(shaperOutIChanged()), this, SLOT(updateShaperOutIString()));
@

Where updateShaperOutIString() would create the hex representation for me?

If this is on the right track, would I replace "soc" with "this" in this line?

[ZapB]

I would simply make a private inline function like:

@
void setShaperOutI( int newValue )
{
if ( m_shaperOutI == newValue )
return;

// Update variable and notify world
m_shaperOutI = newValue;
emitShaperOutIChanged();

// Update string representation
m_shaperOutIHex = ...
emit shaperOutIHexChanged();

}
@

Then anywhere in your code where you modify the m_shaperOutI variable replace it with a call to this function. That is you only modify the variable in such a way that the hex string version gets updated too automatically.

[andre]

Yes, you're on the right track, but the implementation can stay quite simple. You already have the value for the property, just use that to implement the string version. No need to actually keep track of both an integer and a string version, just generate the string on request.

Assuming the class name of your soc object is Soc, you could do this:

soc.h:
@
class Soc:public QObject {
//stuff here is in addition to what is already in your class header

Q_PROPERTY(QString shaperOutIString READ shaperOutIString NOTIFY shaperOutIStringChanged);

public:
QString shaperOutIString();

signals:
void shaperOutIStringChanged();
};
@

soc.cpp:
@
Soc::Soc()
{
//in addition to what's already there:

//note: we are connecting a signal to another signal!
connect (this, SIGNAL(shaperOutIChanged()), this, SIGNAL(shaperOutIStringChanged()));

}

QString Soc::shaperOutIString()
{
//implement the shaperOutIString property in terms of the already existing integer version...
return QString::number(m_shaperOutI, 16); // <-- assuming the integerversion is stored as a member variable m_shaperOutI in the class
}
@

[ZapB]

Ah yes that would be better than what I suggested. Forget my idea.

[mzimmers]

Thanks for the suggestions, guys.

Zap: I like yours as well, though I think you have a typo on line 8.

Andre: I think you have a typo on line 1 of soc.cpp: should be Soc::Soc(), right?

Does your solution eliminate the need for an actual QString member within the object? If so, is this line in the .qml file correct?

@ text: "shaperOutI = " + soc.shaperOutIString;
@

If this is right, I have something wrong somewhere else, since the value isn't updating in the GUI.

Also, may I ask why you used number instead of setnum?

Thanks.

[andre]

[quote author="mzimmers" date="1302188775"]Andre: I think you have a typo on line 1 of soc.cpp: should be Soc::Soc(), right?
[/quote]
Right. Fixed.

[quote]
Does your solution eliminate the need for an actual QString member within the object?[/quote]
Yes.

[quote] If so, is this line in the .qml file correct?

@ text: "shaperOutI = " + soc.shaperOutIString;
@

If this is right, I have something wrong somewhere else, since the value isn't updating in the GUI.[/quote]
Any console output anywhere? Mistake in connecting the signals perhaps?

[quote]
Also, may I ask why you used number instead of setnum?
[/quote]
To make it a oneliner :-)
Seriously: it is a convenient static constructor, that creates a QString instance and sets it to the right value in one go. That is more efficient (in theory, compiler may optimize?) than first creating an instance, and then changing its value.

[mzimmers]

[quote]Any console output anywhere? Mistake in connecting the signals perhaps? [/quote]

No unexpected console output. In the GUI, the "shaperOutI = " displays OK, but it's blank after that.

I implemented the signal just as your example indicated.

I was able to step through the shaperOutIstring() call once, and the returned string was null. FWIW...

EDIT: it's working now. I made a change, undid the change, and...success. I love it when that happens.

I have a few minor tweaks to do, but I think this is solved.

Thanks again.