Cita:
|
Empezado por kanvictor
Mi estimado lepe... se supone que como estoy hablando del timer, si hay un timer  , lo que mostre de codigo es lo que esta adentro del timer.... ... no entiendo por que preguntas esooo....?? |
No dijiste que ese código está dentro del evento OnTimer.
Creía que estabas midiendo el tiempo con esa expresión, y desde luego, realizar conversiones de texto a número y sumarle fracciones de tiempo no es la forma de medir el tiempo. La forma correcta sería con GetTickCount, si quieres toda la precisión.
Dices que el resultado de esa expresión es la que se usa para enviarla por sockets. Creía que esa expresión era la que realmente medía el tiempo !!
Yo he realizado pruebas de ese estilo con timers, y no he tenido retardo, en realidad los retardos se producían
en mi código, y creo que tambien es tu caso (intuyo).
Dentro del timer, ejecutas ese código (ya consume algo de tiempo, mínimo, porque son 3 o 4 conversiones), despues lo envias por sockets, (tambien se consume un tiempo más considerable), el programa Cliente Recibe el tiempo que ha de activar su timer y lo pone en marcha, Justo en este punto es cuando debes empezar a contar el tiempo.
Si usas un reloj de pulsera, tambien hay retardos en pulsar el botón o parar el crono, por tanto no es fiable.
No es lógico medir el tiempo desde antes de lanzarlo por sockets.
Quizás lo esté entendiendo de otra forma
.
En cuanto a que el sistema esté al 80 % y se pase por alto, o se retrase..., solo puedes darle prioridad a tu proceso en windows, para que windows lo trate con más "atención" que al resto. Pero en este caso, no se trata de retardos del timer, sino retardos de Windows en procesar el mensaje desde el cronómetro interno del sistema (hardware) hasta que llega a tu aplicación.
Lo ideal, como estas viendo es unir la prioridad de proceso con GetTickCount.
Espero que ahora me haya expresado mejor.
saludos