Le 19/06/11 10:23, Tom Cloyd a écrit : Hi Tom,
> Now open it. What I keep getting is a single record, with the autovalue > NOT created, and the default value in the second field. Hitting Enter, > one would think, would cause the key to instantiate, and the record > marker to move to the next record. What actually happens is nothing. No > autovalue realization, and no new record. It cannot be updated. Yes, that is how it usually works, however, I can reproduce the behaviour you describe in that particular circumstance on MacOSX with LibO 3.4. It can however be updated by editing the default value, or deleting it with the backspace key, and say retyping it, or filling with another value. This then produces the desired behaviour of creating an automatic new tuple entry. Additionally, it does some really strange things with the ID key, like not autoincrementing it on the display, so what the user appears to see is a series of '0' with each new tuple. However, if you now close that edited table and then re-open it, the keys appear to have automagically corrected themselves, so that they appear in serial order. Thus, there are in fact what looks like 2 bugs : (1) the non-automatic creation of a new tuple using tab key or enter, after having defined an automatic default text value in the table definition ; (2) the misleading display of autoincremented key values. I have already read somewhere, either here or on a bug report, that the default value setting of a text field caused problems with either defining other fields at table creation time, or else making the table uneditable (as in the present case). Alex -- Unsubscribe instructions: E-mail to users+h...@global.libreoffice.org In case of problems unsubscribing, write to postmas...@documentfoundation.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
