Article # 145, added by Geoworks, historical record
| first | previous | index | next | last |

How to use VisUpdateModes




Here is a brief description of how and when to use the various
VisUpdateModes.

    VUM_NOW:
	Use this sparingly!  If you have a *single* object
	to update, you may use it, but it generally causes a huge 
	number of geometry invalidations and recalculations to
	occur in your application.  

        The easiest way to screw things up is to use VUM_NOW 
        indiscriminately.  When in doubt, you should use 
        VUM_DELAYED_VIA_APP_QUEUE; intuitively you might think 
        it would be slower, but in pratice you're often doing
        multiple updates, so it's usually as fast or faster than
        VUM_NOW.

    VUM_DELAYED_VIA_APP_QUEUE:
	This is the mode you should use if you are invalidating more
	than one object.  For example, if you are changing monikers
	for each item in an item group, you should pass this mode
	along with MSG_GEN_REPLACE_VIS_MONIKER.

	This causes all the geometry invalidations/recalculations
	to occur at once, which is much faster and less prone to
	race conditions.

    VUM_DELAYED_VIA_UI_QUEUE:
	This one should not be used unless you are doing something in
	the system's UI thread, in which case it is used in the same
	context as VUM_DELAYED_VIA_APP_QUEUE.  In fact, VUM_NOW is
	rarely used in the UI: using it during updates can result
	in infinite recursion.

    VUM_MANUAL:
	This one is typically used for synchronization between
	threads.  For example, if you have objects that are being
	updated on your UI thread, but you must wait for your process
	thread to finish doing something before displaying the results,
	you should use this mode, and then do the invalidation 
	yourself.

	Use VUM_MANUAL with caution!  It's easy to forget to do the
	invalidation, in which case your app will be in an
	indeterminate state.