@Axel-Spoerl said in Problem with lcdNumber:
QLCDNumber::display() is unfortunately an ambiguous slot, taking either an int or a double. That can have surprising effects, especially when dealing with PMF based connections.
I don't see how that's relevant, given that slot is not being connected to (it's being invoked directly). Of course, it might well be relevant, I'm just not sure why. Would love to hear more if its something I'm missing :) Either way qOverload() is pretty cool - never knew about that one.
@iq0-0, what is your QLCDNumber::mode set to? Only QLCDNumber::Dec supports floating points, the other are integer only.
Assuming you are using QLCDNumber::Dec, I would set a break-point on this line:
cdNumber->display(recPo); //give value 0 !!!!
And then step into and through that function call. It's possible, for example, that:
recPo is being modified by some other code in between your qDebug and QLCDNumber::display() calls (we don't see the declaration, nor the full life-cycle of that member variable; do you have multi-threaded or async I/O happening? is that variable a double?); or
QLCDNumber::display() might be setting the value correctly, and later calls overwriting it to 0 before you see the results;
etc.
As I said, I'd use the debugger to step into it, and if that doesn't reveal anything, then what @JonB suggested above. Or try @JonB's suggestion first. Either is good, IMO :)
Cheers.