G'day all,

I've got an app where I'm doing some time critical serial processing. I have 2 callbacks in the serial code that call back to methods in the form to update a status bar and caption label.

I used to update the label/status bar and call Application.ProcessMessages so they would paint, but I discovered the indeterminacy in the other GUI events queued would cause my serial latency to randomly blow out badly. I've worked around this by doing..

StatusBar1.Repaint;
Label1.Repaint;
rather than Application.ProcessMessages;

On Win32 and GTK2/Linux this works perfectly, but on Carbon it won't repaint anything until the application can service its message queue.

Is this expected behaviour or an inherent in the toolkit?

I don't really want to have to go to a multi-threaded model if I can avoid it, but this one has me stumped.

Regards,
Brad

Mac OS X allows to draw only on Paint event (generated by OS), you can't draw in any other event (i.e. buttonclick, timer etc..). You must update controls using Application.ProcessMessages.

Thanks,
Dmitry

1. like dmitry says - Carbon/Cocoa & Qt on all platforms does not allow
paintings outside of paint event.
2. Calling repaint is very expensive (CPU), try with YourControl.Invalidate;
or YourControl.Update;

zeljko

1. like dmitry says - Carbon/Cocoa & Qt on all platforms does not allow paintings outside of paint event. 2. Calling repaint is very expensive (CPU), try with YourControl.Invalidate; or YourControl.Update;

Invalidate and Update will take effect only if messages queue is processed (by ProcessMessages or PostMessages if blocked by an event).

but he is calling Application.ProcessMessages; after Repaint; , so why not Invalidate or Update ?

_______________________________________________ Lazarus mailing list http://www.lazarus.freepascal.org/mailman/listinfo/lazarus

but he is calling Application.ProcessMessages; after Repaint; , so why not Invalidate or Update ?

yes, Invalidate or Update call prior to ProcessMessages would be enough. But as far as I understand, Brad does NOT call it.

I was trying not to call Application.ProcessMessages as that is *very* expensive (I'm seeing delays of up to 100msec on a G4 400) but it looks like I have no choice.

Thanks for the feedback guys :)

Regards,
Brad

Brad Campbell wrote

I was trying not to call Application.ProcessMessages as that is *very* expensive (I'm seeing delays of up to 100msec on a G4 400) but it looks like I have no choice.

You can use a high resolution timer like EpikTimer ( http://wiki.lazarus.freepascal.org/EpikTimer ) to check if the delay caused by calling Application.ProcessMessages will disturb your communication. Like this:

Fetch current time;
Application.ProcessMessages
if TimeDelay > x ms then do something;