Ok, OK. Feature request sent… —————————— Currently an object field's dirty flag only gets set if the object field itself is referenced...
OB SET([MyTable]MyObjectField;"property";"newValue") SAVE RECORD[MyTable] //The field's dirty flag is set and the new value is saved. MyTable]MyObjectField.property:="newValue" SAVE RECORD[MyTable] //The field's dirty flag is NOT set becaaue a propery has been modified, not the field itself, and so the new value is NOT saved. This has been designated as standard behaviour. 4D Tech Support has been telling developers to add a line of code that sets the dirty flag... MyTable]MyObjectField.property:="newValue" MyTable]MyObjectField:=MyTable]MyObjectField //the field is referenced SAVE RECORD[MyTable] //The field's dirty flag is set and the new value is saved. Based on an extensive thread ( [Warning] Settings properties values on object field by object notation) on the NUG, many developers including myself believe this should not be considered as standard behviour. Request that the dirty flag of an object field be set whenever it is modified using dot notation. It is also requested that until this behaviour is changed, a warning be added to the LRM that clearly explains the current behaviour of an object field. Developers expect that modifying a field using :=, regardless of the type, will result in the updated data being saved to the datafile. Any other field typds that have "properties" that contain data should provide the same expectation. If not this "non-standard" behaviour must be clearly documented. __________________ John > On Nov 1, 2017, at 3:32 PM, Brian Young via 4D_Tech <[email protected]> > wrote: > > I think I understand the logic and emotion from all sides of this thread. I > want to try and clarify (repeat?) a couple discussion points so this can end > up being a constructive thread, and not just a user group chat that doesn’t > get the attention it deserves. > > > There are a lot of strong reactions to this being marked as "standard > behavior”. My understanding is simply: standard behavior means the issue > has been reviewed and the engineers find the behavior matches the > specification. > > So, it is the specification that you would like to see changed. > > I understand why. Several strong arguments have been made on this thread. > > These arguments should be posted on the feature request forum which is the > official place to request this kind of change. This is especially important > because in this case we are talking about a feature that is currently in > preview. The feature is not yet recommended for production use and "final > implementation could be slightly different”. It is the ideal time to request > changes in behavior and I do not see a request for this posted yet. Please > post it so that engineering has a clear understanding of your concerns. > > Feature Request Forum (login required first): > http://forums.4d.com/Forum/EN/1075213/0/ > > (let me know if you need help with logging in to the forum due to the recent > SSO login changes.) > > > my very best > > -Brian > > > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** John Baughman Kailua, Hawaii (808) 262-0328 [email protected] ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
