Hi Andrew, > Where oEv.Source.Model.Parent is a dataform that feeds a grid control. > This is an HSQL embedded database. I know that I am sitting on an > unsaved inserted row when this is called. However, the test .RowInserted > returns false.
IsNew is the property to ask the form for [1]. RowInserted just means that the current row previously had been inserted into the row set. I doubt that there are much implementations which allow to detect this, OOo itself doesn't (that is, if you insert a row and later on move to it, RowInserted will still return false. The respective meta data method [2] should consequently return false, too.) > And here I have a real problem. If the call to first happens, with the > inserted > row not saved it generates a "Function Sequence Error" and at this point the > forms' UI is completely messed up. There appears to be two record pointers > on the form and any further interaction causes continued function > sequence errors > to be reported. this is bad, and worth a bug report. If a "first" (or any other movement) call is rejected, this shouldn't leave the row set / form unusable. > Second question - I KNOW that the data in the inserted row is valid for > the record, > so why did the call to .First not simply post the data to the engine > before the move? Because somebody else would come and require that "first" would silently discard the changes - finally, he didn't call "insertRow", did he? That is, no option - silently commit or silently discard - would be correct, so an exception, and the requirement to call insertRow or cancelRowUpdates, is the only feasible choice. > Third queston - the macro is called from a click on a button. The > button has it's property set to take focus. Should this not have > caused a post of the inserted record even before the macro was > called. Or, is this not the case because the button is also owned by > the dataform control that ownes the grid itself? The only thing which happens if you leave a control, and focus another one, is that the first control's content is committed to the row's column. The whole row is not committed at all, except the user does so explicitly (by pressing the "Save record" button), or you're traveling "around" by pressing "Tab" in the last control. (Actually, there's a few more user-triggered UI actions which commit the record as a whole, since they trigger actions which expect this, but this doesn't matter here.) Ciao Frank [1]http://api.openoffice.org/docs/common/ref/com/sun/star/sdb/RowSet.html#IsNew [2]http://api.openoffice.org/docs/common/ref/com/sun/star/sdbc/XDatabaseMetaData.html#insertsAreDetected --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
