How about a sequence like this:
1. Set cursor to busy (wait glass)
2. Update display
3. Reset cursor
George Zou
http://gtoolbox.yeah.net
> My kludge/workaround is to add a variable delay before the message is
> cleared. The delay is based on the image size and some
> empirically-derived constants.
The issue is that the terminals and locals of controls schedule an
update and allow for batching. They are not synchronous. To
synch
Thanks for the reply, but moving the image or blanking it out prior to
displaying it won't work for us because we are looking for possible
subtle changes between subsequent images and doing this would make
that difficult (and it would also tend to introduce a considerable
delay in the update).
I've already tried something like this and it just does not work like
I want it to.
Enforced with a sequence structure I do this:
1) put up a message saying "Updating"
2) dump the updated data to the display
3) clear the message
What I see on the CRT is this:
1) a message saying "Updating"
2) the
Maybe a little bit off topic, but I remember there was a (set) VI(s)
in the internet toolkit which help you to detech if there are any
image (png or other type) updates.
To synchronize the data and graph update, you can move or hide/show
the graph everytime after each data update, so labview is 'f
Thanks for the reply but unfortunately this proposed solution does not
see the delay within the display system. For large images (4kx4k) the
time it takes to update the CRT display can be quite long and it seems
that this time is invisible to LabVIEW. It can leave the user sitting
there wondering "
