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.