Page History
...
Code Block | ||||
---|---|---|---|---|
| ||||
// ChangeEvent { // If this change event is caused by one or more calls (by the component) on the IFoundset obj // (like loadRecordsAsync requestSelectionUpdate and so on), and the caller then assigned a value to // the returned RequestInfoPromise's "requestInfo" field, then that value will be present in this array. // // This is useful for some components that want to know if some change (reported in this ChangeEvent) // happened due to an action that the component requested or due to changes in the outside world. (eg: // IFoundset.loadRecordsAsync(...) returns RequestInfoPromise and ChangeEvent.requestInfos array can // contain that RequestInfoPromise.requestInfo on the event that was triggered by that loadRecordsAsync) // // @since 2021.09 $foundsetTypeConstants.NOTIFY_REQUEST_INFOS: any[], // If a a full value update was received from server, this key is set; if newValue is non-null: // - prior to Servoy version 2021.06: newValue is a new reference, but it will automatically get // the old value's listeners registered to itself // - starting with Servoy 2021.06: the old value's reference will be reused (so the reference of // the foundset property doesn't change, just it's contents are updated) and oldValue given // below is actually a shallow-copy of the old value's properties/keys; this can help // in some component implementations $foundsetTypeConstants.NOTIFY_FULL_VALUE_CHANGED: { oldValue : ..., newValue : ... }, // the following keys appear if each of these got updated from server; the names of those // constants suggest what it was that changed; oldValue and newValue are the values for what changed // (e.g. new server size and old server size) so not the whole foundset property new/old value $foundsetTypeConstants.NOTIFY_SERVER_SIZE_CHANGED: { oldValue : ..., newValue : ... }, $foundsetTypeConstants.NOTIFY_HAS_MORE_ROWS_CHANGED: { oldValue : ..., newValue : ... }, $foundsetTypeConstants.NOTIFY_MULTI_SELECT_CHANGED: { oldValue : ..., newValue : ... }, $foundsetTypeConstants.NOTIFY_COLUMN_FORMATS_CHANGED: { oldValue : ..., newValue : ... }, $foundsetTypeConstants.NOTIFY_SORT_COLUMNS_CHANGED: { oldValue : ..., newValue : ... }, $foundsetTypeConstants.NOTIFY_SELECTED_ROW_INDEXES_CHANGED: { oldValue : ..., newValue : ... }, $foundsetTypeConstants.NOTIFY_VIEW_PORT_START_INDEX_CHANGED: { oldValue : ..., newValue : ... }, $foundsetTypeConstants.NOTIFY_VIEW_PORT_SIZE_CHANGED: { oldValue : ..., newValue : ... }, $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROWS_COMPLETELY_CHANGED: { oldValue : ..., newValue : ... }, // (ADDED in Servoy 2022.03) // This key is in the change event if the foundset spec property is configured "foundsetDefinitionListener": true, // see "Defining initial load options for a foundset property" on this page. for more info $foundsetTypeConstants.NOTIFY_FOUNDSET_DEFINITION_CHANGE: boolean, // if we received add/remove/change operations on a set of rows from the viewport, this key // will be set; as seen below, it contains "updates" which is an array that holds a sequence of // granular update operations to the viewport; the array will hold one or more granular add, remove // or update operations; // // BEFORE Servoy 8.4: all the "startIndex" and "endIndex" values below are relative to the viewport's // state after all previous updates in the array were already processed (so they are NOT relative to // the initial or final state of the viewport data!). Updates can come in a random order so there is // NO guarantee related to each change/insert/delete indexes pointing to the correct new data in the // final current viewport state // // STARTING WITH Servoy 8.4: all the "startIndex" and "endIndex" values below are relative to the // viewport's state after all previous updates in the array were already processed. But due to some // pre-processing that happens server-side (it merges and sorts these ops), the indexes of update // operations THAT POINT TO DATA (so ROWS_INSERTED and ROWS_CHANGED operations) are relative also to // the viewport's final/current state, so after ALL updates in the array were already processed // (so these indexes are correct both related to the intermediate state of the viewport data // and to the final state of viewport data). // This means that it is now easier to apply UI changes to the component as these granular updates // GUARANTEE that if you apply them in sequence (one by one) to the component's UI (delete, insert and // change included) you can safely use the indexes in there to get new data from the present state // of the viewport. // // indexes are 0 based $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES_RECEIVED: { // DEPRECATED in Servoy 8.4: granular updates are much easier to apply now; see comment above // Added in 8.3.2; sometimes knowing the old // viewport size helps calculate incomming granular updates easier $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES_OLD_VIEWPORTSIZE: ..., // starting with 8.3.2 you can use instead of 'updates' below the new constant; // $foundsetTypeConstants.NOTIFY_VIEW_PORT_ROW_UPDATES // before 8.3.2 just use 'updates'; updates : [ { type : $foundsetTypeConstants.ROWS_CHANGED, startIndex : ..., endIndex : ... }, { // NOTE: insert signifies an insert into the client viewport, not necessarily // an insert in the foundset itself; for example calling "loadExtraRecordsAsync" // can result in an insert notification + bigger viewport size notification, // with removedFromVPEnd = 0 type : $foundsetTypeConstants.ROWS_INSERTED, startIndex : ..., endIndex : ..., // DEPRECATED starting with Servoy 8.4; it would always be 0 here // as server-side code will add a separate delete operation instead - if necessary // BEFORE 8.4: when an INSERT happened but viewport size remained the same, it was // possible for some of the rows that were previously at the end of the viewport // to slide out of it; "removedFromVPEnd" gives the number of such rows that were // removed from the end of the viewport due to this insert operation; removedFromVPEnd : ... }, { // NOTE: delete signifies a delete from the client viewport, not necessarily // a delete in the foundset itself; for example calling "loadLessRecordsAsync" can // result in a delete notification + smaller viewport size notification, // with appendedToVPEnd = 0 type : $foundsetTypeConstants.ROWS_DELETED, startIndex : ..., endIndex : ..., // DEPRECATED starting with Servoy 8.4; it would always be 0 here // as server-side code will add a separate insert operation instead - if necessary // BEFORE 8.4: when a DELETE happened inside the viewport but there were more rows // available in the foundset after current viewport, it was possible for some of those // rows to slide into the viewport; "appendedToVPEnd " gives the number of such rows // that were appended to the end of the viewport due to this delete operation appendedToVPEnd : ... } ] } } |
...
A foundset based component can specify (starting with Servoy 2022.03) if it wants to know if when the foundsets foundset's definition was changed, by adding a foundsetDefinitionListener property to the foundset property with the value true. If that is true, then foundset the foundset's ChangeListener will also get a foundsetDefinitionChanged event passed in then when the definition (sql query) of the underlying foundset is changed. This can be handy if you are in a grouped mode and the root foundset only has 200 records loaded but through grouping you really show 1000 records and because of a filter that is applied to the root the first 200 are not changed but the change is somewhere visible after that. Then the a grouping table should reflect that by refreshing the groups. Don't use this property if you don't need it because it is not without cost to calculatie this - to calculate the query change and fire the event.
.spec file
...