Form events and foundsets

Classic Servoy
1

It seems that a foundset gets hooked up to a form’s events when the foundset is created in the context of the form. Makes sense.

This is a good and bad thing. I like to abstract methods that do significant operations out of the form context, however. Many of these methods take a record as a parameter. When I call one these methods and pass it a record from the foundset of the form, the form’s events follow that record, and this is causing me some grief.

Here’s an example. I have a form “Timesheets.” A timesheet record can be locked, so I have an onRecordEditStart method that checks if the current timesheet is locked and returns false if it is. User then cannot edit the record. Brilliant.

If I have a button on that form that calls the “globals.timesheet_unlock(foundset.getRecord(foundset.getSelectedIndex())”, my unlock method fails, because when it tries to set a value on the record it gets passed, the onRecordEditStart method of the form is called, and it returns false. FAIL.

I’ve been working around this by having my onRecordEditStart method support a flag on the form to allow edit overrides, then toggling that flag before and after I make these sorts of calls – but that’s kind of a pain.

Currently, I’m of the opinion that onRecordEditStart shouldn’t really fire unless triggered by user action in form…but that might be wrong minded.

Any good ideas to get around this issue?

greg.

2

the only thing i can quickly think of is to create a duplicate foundset of the foundset you show in the form.
And do you pure data stuff on that one.

It is not that easy to “know” not to call onRecordEdit start if you do it through scripting. And there are also many situations i can think of that users do want it to be called.

3

Would duplicating the foundset be an expensive operation?

Would it be practical to implement some sort of property on a foundset that would allow you suspend form events on the foundset? For example…

foundset.setFormEventsActive(false);
// do stuff here
foundset.setFormEventsActive(true);

g.

PS - there are cases it might be nice to suspend table events on a temporary basis as well.

4

suspending things like that (table events) is weird.
Because that is really validation

But you can do that your self. Just set a global…

duplicating a foundset isnt cheap but it is also not major expensive either. Its not that you copy all the row data. Just the pointers to that data.

What you also could do

Is quickly remove the foundset from the form… So set an empty foundset in the form. Do you stuff on the real foundset. set that foundset back in the form.

5

True, RE: the table events. I was really just thinking of it for mass data operations where the performance might benefit.

Table events aren’t always just validation, especially if you are added “after” events and there are cases (like an import) where it might be advantages not to have them run – but you are also correct I can just handle that myself.

I extended the function I use to grab the current record from a foundset to support getting a “clean” copy that’s not linked to the form’s foundset. Seems to work:

	// return current record from foundset
	$fs.rec = function(fs, flNewFoundset) {
		if(!flNewFoundset) return fs.getRecord(fs.getSelectedIndex());
		
		var pkCol = databaseManager.getTable(fs.getServerName(),fs.getTableName()).getRowIdentifierColumnNames()[0];
		var ds = databaseManager.createEmptyDataSet(1,1);
		ds.setValue(1,1,fs[pkCol]);
		var fs_new = fs.duplicateFoundSet();
		fs_new.loadRecords(ds);
		return fs_new.getRecord(fs_new.getSelectedIndex());
	};

Now when I need to get a copy of the current record to pass that will not trigger form events, I simple call the above as:

$fs.rec(foundset, true);

greg.