very strange,
but seems that: TTMSMQTTClient.Subscribe is blocking the ui update complete.
(disabled the subscription after a date change, and loading goes fast)
Does it somehow keep repainting the planner?
no thats not the case. already tested that with counters.
trying now with the subscription all at once, instead one for one (8 subscriptions)
same result as subscribing one for one.
when i (temporarily) change in the file TMS.MQTT.Client.pas
// Queue the packet
HandleOutgoingPacket(packet);
by
// Queue the packet
HandleOutgoingPacket(packet, True); // warning, temporarily adjustment!!
then the response is much better. very weird.
I'explain the flow.
(the client has a central method which fetches data from the server, this can be invoked from the client itself (change of date in view) or from a server (signal that the data for that date is changed).
When chaning date in view, we unsubscibe for signals for that date,
fetch the data, call an event (synchronized) to update the planner with this data.
Then subscibe for signals for changes on that date.
Maybe the synchronize sits in the way with the mqttclient somehow? But already tested with change the syncrhonize with a direct call to the event, then the delay is also there.
Can it be that the Synchronize calls in the TMS.MQTT.Client.Threading unit (writerthread) sit in the way?
Maybe an idea to make the SendDirect (bool) parameter available to all "writing" methods ?