UI-DEN-2087

RESOLVED

RESOLVED

Resolving as per our conv. today regarding placeholders

Resolving as per our conv. today regarding placeholders

RESOLVED

RESOLVED

RESOLVED

RESOLVED

Hey, yes this can be resolved. When I first looked over the change, I misread it and thought you were doing a static_cast<QVariant::Type>(vData) instead of static_cast<QVariant::Type>(QMetaType::Fl...

Hey, yes this can be resolved. When I first looked over the change, I misread it and thought you were doing a static_cast<QVariant::Type>(vData) instead of static_cast<QVariant::Type>(QMetaType::Float), which gave me pause. Since that's not the case, this change looks good to me

OK, I made the changes. I found the point of confusion. The code in this branch is 2-3 weeks older than latest code. after doing the changes and merge I found out what is the point of the confusion...

OK, I made the changes.
I found the point of confusion.
The code in this branch is 2-3 weeks older than latest code. after doing the changes and merge I found out what is the point of the confusion.
I modified the code anyway.

Please resolve the comment as well. Also a good reference for later: http://www.cplusplus.com/doc/tutorial/typecasting/

Please resolve the comment as well.
Also a good reference for later:
http://www.cplusplus.com/doc/tutorial/typecasting/

RESOLVED

RESOLVED

I don't know why I should use dynamic_cast and have an if around the cast. What is the point? What do I gain by doing so? I'm sure checking everything in compile time is much more safer than in run...

I don't know why I should use dynamic_cast and have an if around the cast. What is the point?
What do I gain by doing so?
I'm sure checking everything in compile time is much more safer than in run-time waiting for the code to be executed and then handle the exception.
What is the advantage of the dynamic_cast over the static_cast. they do the same thing if can successfully doing it in different situation.

Don't we not know the true type of vData even at runtime? So, what is the advantage of static_cast being used if it only checks the type at compile time? With dynamic_cast doesn't it return null if...

Don't we not know the true type of vData even at runtime? So, what is the advantage of static_cast being used if it only checks the type at compile time?
With dynamic_cast doesn't it return null if it doesn't contain the type casted, so you just add an if statement checking whether it is null or not to know for a fact that you're cast was successful

Wait so in that case mData would be written over with the call: Types::setValue(s32, mData) Then mData is returned, with a length of one. Would the caller know whether the value was correctly conve...

Wait so in that case mData would be written over with the call: Types::setValue(s32, mData)
Then mData is returned, with a length of one.
Would the caller know whether the value was correctly converted to 0, or converted to 0 in error in this case?

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

RESOLVED.

if case of error of casting 4 it doesn't return 0 it returns nothing. To answer the question yes the length of the returned QByteArray is the error identification. In some functions an uninitialize...

if case of error of casting 4 it doesn't return 0 it returns nothing.
To answer the question yes the length of the returned QByteArray is the error identification.
In some functions an uninitialized returned object is the way of unsuccessful action like returning null or an empty object.

Done

Done

Done

Done

Done

Done

Done

Done

Done

Done

Done

Done

Done

Done

Done

Done