Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Database query, front end update, suggestions?
Forum Updated to NodeBB v4.3 + New Features

Database query, front end update, suggestions?

Scheduled Pinned Locked Moved Unsolved General and Desktop
15 Posts 3 Posters 352 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S SPlatten
    26 Oct 2021, 06:07

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

    J Offline
    J Offline
    jsulm
    Lifetime Qt Champion
    wrote on 26 Oct 2021, 06:08 last edited by
    #5

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

    https://forum.qt.io/topic/113070/qt-code-of-conduct

    S 1 Reply Last reply 26 Oct 2021, 06:11
    0
    • J jsulm
      26 Oct 2021, 06:08

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

      S Offline
      S Offline
      SPlatten
      wrote on 26 Oct 2021, 06:11 last edited by
      #6

      @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?

      Kind Regards,
      Sy

      J J 2 Replies Last reply 26 Oct 2021, 06:15
      0
      • S SPlatten
        26 Oct 2021, 06:11

        @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?

        J Offline
        J Offline
        jsulm
        Lifetime Qt Champion
        wrote on 26 Oct 2021, 06:15 last edited by
        #7

        @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.

        https://forum.qt.io/topic/113070/qt-code-of-conduct

        1 Reply Last reply
        0
        • S SPlatten
          26 Oct 2021, 06:11

          @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?

          J Offline
          J Offline
          J.Hilk
          Moderators
          wrote on 26 Oct 2021, 06:17 last edited by
          #8

          @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!?


          Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


          Q: What's that?
          A: It's blue light.
          Q: What does it do?
          A: It turns blue.

          S 1 Reply Last reply 26 Oct 2021, 06:20
          0
          • J J.Hilk
            26 Oct 2021, 06:17

            @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!?

            S Offline
            S Offline
            SPlatten
            wrote on 26 Oct 2021, 06:20 last edited by
            #9

            @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.

            Kind Regards,
            Sy

            1 Reply Last reply
            0
            • J Offline
              J Offline
              J.Hilk
              Moderators
              wrote on 26 Oct 2021, 06:21 last edited by
              #10

              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


              Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


              Q: What's that?
              A: It's blue light.
              Q: What does it do?
              A: It turns blue.

              S 1 Reply Last reply 26 Oct 2021, 06:25
              1
              • J J.Hilk
                26 Oct 2021, 06:21

                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

                S Offline
                S Offline
                SPlatten
                wrote on 26 Oct 2021, 06:25 last edited by
                #11

                @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.

                Kind Regards,
                Sy

                J 1 Reply Last reply 26 Oct 2021, 06:34
                0
                • S SPlatten
                  26 Oct 2021, 06:25

                  @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 Offline
                  J Offline
                  J.Hilk
                  Moderators
                  wrote on 26 Oct 2021, 06:34 last edited by
                  #12

                  @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


                  Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                  Q: What's that?
                  A: It's blue light.
                  Q: What does it do?
                  A: It turns blue.

                  S 1 Reply Last reply 26 Oct 2021, 06:38
                  0
                  • J J.Hilk
                    26 Oct 2021, 06:34

                    @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

                    S Offline
                    S Offline
                    SPlatten
                    wrote on 26 Oct 2021, 06:38 last edited by
                    #13

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

                    Kind Regards,
                    Sy

                    J 1 Reply Last reply 26 Oct 2021, 06:44
                    0
                    • S SPlatten
                      26 Oct 2021, 06:38

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

                      J Offline
                      J Offline
                      J.Hilk
                      Moderators
                      wrote on 26 Oct 2021, 06:44 last edited by J.Hilk
                      #14

                      @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


                      Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                      Q: What's that?
                      A: It's blue light.
                      Q: What does it do?
                      A: It turns blue.

                      S 1 Reply Last reply 26 Oct 2021, 06:52
                      1
                      • J J.Hilk
                        26 Oct 2021, 06:44

                        @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

                        S Offline
                        S Offline
                        SPlatten
                        wrote on 26 Oct 2021, 06:52 last edited by
                        #15

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

                        Kind Regards,
                        Sy

                        1 Reply Last reply
                        0

                        14/15

                        26 Oct 2021, 06:44

                        • Login

                        • Login or register to search.
                        14 out of 15
                        • First post
                          14/15
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • Users
                        • Groups
                        • Search
                        • Get Qt Extensions
                        • Unsolved