Database query, front end update, suggestions?

[SPlatten]

@jsulm, not sure why I added that, will remove it and try.

[SPlatten]

@jsulm , I've removed the QThread::msleep, the dialog still doesn't update until all the calls to sendBinary have completed.

[jsulm]

@SPlatten As I already said: you also need to remove the loop! Remove it and use a QTimer instead...

[SPlatten]

@jsulm , since the OS is windows, using a timer is going to slow things right down, one of the requirements is for a fast transfer, is there a better / alternative to using a timer that would achieve the same?

[jsulm]

@SPlatten said in Database query, front end update, suggestions?:

using a timer is going to slow things right down

Why? The slow part is the query, not timer. And with QThread::msleep() you basically did exactly same (but also blocking the event loop) - why do you think timer will be slot?
If you want to do it better, then wait for currently running query before sending next one.

[J.Hilk]

@SPlatten said in Database query, front end update, suggestions?:

since the OS is windows, using a timer is going to slow things right down, one of the requirements is for a fast transfer, is there a better / alternative to using a timer that would achieve the same?

I fail to see the connection to the OS and the timer usage ?

You originally, before you removed it, send your thread to sleep, that would be the same time as a timer would use!?

[SPlatten]

@J-Hilk, Unless it's improved with later versions timing has never been one of Windows strong points. Timer accuracy use to be around 50ms, despite being able to set the timers to 1ms, if you hook up a scope you would see its no-where close, other operating systems are capable of not only ms but microsecond timer accuracy.

[J.Hilk]

Ok, if I do see this correctly, the slow part is the TCP creation connection and sending.

Why don't you make that socket a class member and keep it alive and connected until everything is done.

Than you can also, easily, listen to the bytesWritten Signal, and use that to proceed in your "loop" instead of timers or infinite loops

[SPlatten]

@J-Hilk , thats exactly what it does already, I don't reconnect for every packet. Its rather complex in that there is a mixture of UDP and TCP, the UDP data is broadcast by the application to multiple clients notifying them that a new data set is available. Each client can issue a request for the dataset to be sent, then this is sent individually to each client using TCP.

[J.Hilk]

@SPlatten so everyone on lngTotalBlocks is a different receiver and requires different TCP connection ? thats unfortunate.

Unless it's improved with later versions timing has never been one of Windows strong points. Timer accuracy use to be around 50ms, despite being able to set the timers to 1ms, if you hook up a scope you would see its no-where close, other operating systems are capable of not only ms but microsecond timer accuracy

are you talking about the actual data packet transmitted via your tcp connection? that you observe via the scope?

That of course is rather os depending.

But the accuracy of QTimer and QThread:sleep should be the same as both require the OS to pass the execution back to your program

[SPlatten]

@J-Hilk , why do you say a different receiver what makes you say that?

[J.Hilk]

@SPlatten

Ok, that was probably my bad, due to formatting issues, I missed the nullptr check before the call to new QTcpSocket.

Makes more sense that way :D and would indicate that everything goes to one receiver.

the problem you now have, my guess at least, is your call to this blocking function
mpTCPsocket->waitForBytesWritten(SckServer::mscuint16DataWriteTO);

use the bytesWritten Signal instead.
after that, use your onUpdate function, that is called once all bytes are written, signalled by the bytesWritten signal, to proceed, instead of the for( long lngBlockNo=0; lngBlockNo<lngTotalBlocks; lngBlockNo++ ) loop

[SPlatten]

@J-Hilk , thank you, I will look into it.