Difference between revisions of "Events and updates"
(→Helper Functions) |
(→Coding Update Functions) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 36: | Line 36: | ||
*'''[[raveduplicatevariable]]''' | *'''[[raveduplicatevariable]]''' | ||
*'''[[raveappendrows]]''' - appends one or more rows to a dataset, and then calls raveupdatedataset. | *'''[[raveappendrows]]''' - appends one or more rows to a dataset, and then calls raveupdatedataset. | ||
| + | |||
| + | |||
| + | ==Coding Update Functions== | ||
| + | This is important. Update functions (anything whose filename starts with "raveupdate") should NEVER call guidata(handles.fig,handles). Instead they must pass the updated handles as an output of the function back to whatever called the update function (presumably either [[raveupdateanalysis]] or raveupdatedataset or raveupdateexploremethod, but could be something else). | ||
| + | |||
| + | This is different from just about every other function in Rave, which passes data using guidata(). This system was implemented because guidata is very slow, and update functions usually get called very frequently, many times in a row (since every workspace object may run one or more update functions in response to every user action). | ||
| + | |||
| + | The only exceptions to this rule are the functions [[raveupdateanalysis]], raveupdatedataset and raveupdateexploremethod themselves. These functions will call guidata after they finish running IF they are not called with any outputs. I.e. if you type "handles = [[raveupdateanalysis]](...)" then [[raveupdateanalysis]] will not update the guidata (since you asked for it as an output presumably you are going to do that yourself later, or immediately pass the new handles to another call of [[raveupdateanalysis]].) | ||
| + | |||
| + | These exceptions work just fine AS LONG AS you never call guidata(handles.fig,handles) within any other update function. Putting guidata(handles.fig,handles) in an update function can cause bugs that are very hard to track down. So don't do it! | ||
Latest revision as of 13:42, 16 October 2014
Contents
Introduction
This page lists the "events" that are defined in Rave that cause some object(s) on the workspace or data sets to need to be updated. If you are using Rave, you generally don't need to worry about these... they will be happening in the background whenever you interact with your data. If you are coding Rave plugins, you need to understand when to alert other objects that an event has occurred.
In the lists below, events are named according to their Rave keywords, which correspond to the information being updated (for analysis updates) or the way in which the data set has changed (for data set updates).
Analysis Events
- isselected - A change to which rows are currently selected.
- visiblerows - A change to which rows are currently visible.
- rowcolors - A change to the row colors.
- xdials - A change to a variable's current value. This event can take an optional parameter defining which variable's value has changed.
- isfiltered - A change to the filter values.
- constraints - A change to an existing constraint.
Data Set Events
- targets - A change to the targets.
- addrows - Rows have been added to the data set.
- replaceall - The data set has been replaced completely, or otherwise changed so drastically that it should be treated as entirely new.
- datachanged - Data values have changed, but the number of rows (and their "identity") has not changed.
- removerows - Rows have been removed from the data set.
- preferences - A change to the preferences. NOTE: This event should only be used by objects that need to update in response to changes in the preference values themselves, NOT to changes in the data that result from a change in preferences. Use datachanged in that case. (Generally changing preferences will trigger both a preferences and a data changed event.)
Coding Events in a Workspace Object
Helper Functions
These functions can be used to simplify event coding. Whenever possible, you should use these functions instead of coding your own solution:
- raveupdateanalysis
- raveupdatedataset
- raveupdateexploremethods
- raveduplicatedataset - makes a copy of a data set. Note that [[[data set links]]] do NOT get copied, so if you want them to copy you must code that after you call this function. The duplicated data set also will not be linked back to the original data set's source file and will have its data source type recorded as "raveoriginated".
- raveduplicatevariable
- raveappendrows - appends one or more rows to a dataset, and then calls raveupdatedataset.
Coding Update Functions
This is important. Update functions (anything whose filename starts with "raveupdate") should NEVER call guidata(handles.fig,handles). Instead they must pass the updated handles as an output of the function back to whatever called the update function (presumably either raveupdateanalysis or raveupdatedataset or raveupdateexploremethod, but could be something else).
This is different from just about every other function in Rave, which passes data using guidata(). This system was implemented because guidata is very slow, and update functions usually get called very frequently, many times in a row (since every workspace object may run one or more update functions in response to every user action).
The only exceptions to this rule are the functions raveupdateanalysis, raveupdatedataset and raveupdateexploremethod themselves. These functions will call guidata after they finish running IF they are not called with any outputs. I.e. if you type "handles = raveupdateanalysis(...)" then raveupdateanalysis will not update the guidata (since you asked for it as an output presumably you are going to do that yourself later, or immediately pass the new handles to another call of raveupdateanalysis.)
These exceptions work just fine AS LONG AS you never call guidata(handles.fig,handles) within any other update function. Putting guidata(handles.fig,handles) in an update function can cause bugs that are very hard to track down. So don't do it!
