to me...
using either
        OB SET(object_field;value) = Object_field.property := value

They SHOULD do the same thing, either BOTH set the flag to save the data, or 
neither do.

In all other 4D field types " := " says 'I changed this value', make sure the 
new data is saved if such a request is made.

> I am going to post here a response I got from Tim Penner in the TAOW 
> a bit earlier today. While it does not change my mind that this issue 
> should be characterized as a bug, it does clarify what the issue 
> really is.
> 
> Am I the only one that was clueless that there is a field dirty field 
> flag that controls whether or not a field gets updated or not during 
> a save record. Guess that does make sense.
> 
> John
> 
> ---------------
> Hi John,
> 
> It's not a dirty flag for the record, but a dirty flag for the field. 
> The object field has a dirty flag that only gets set if you reference 
> the object field itself (not a property of it).
> 
> Here are some examples to help illustrate the difference:
> OB SET([Table]OBField;"Prop";"Val") // references the object field 
> itself and does set the dirty flag for this object field.
> [Table]ObField.Prop:="Val" // references a property of the object and 
> will not set the dirty flag for this object field.
> OB SET([Table]ObField.Prop;"Property2";"Val2") // references a 
> property of the object and does not set the dirty flag.
> [Table]ObField:=[MyObject]ObField // references the object field 
> itself and does set the dirty flag for this object field.
> 
> To be clear, in the example database that I submitted with my bug 
> report I demonstrated, as you demonstrated in your last update, that 
> other fields were being saved and that only the Object Field data was 
> being lost. I even demonstrated in code that the change to the object 
> field appeared to stick after a SAVE RECORD and it only reverted to 
> its original state when the record was reloaded. Because of this i 
> categorized the report as a Data Loss bug and made the data loss part 
> clear.
> 
> Today, (after i noticed it was marked as standard behavior) i 
> requested that our documentation be updated so that we can hopefully 
> prevent further reports of data loss.
> 
> Regards,
> Timothy PENNER
> --------------
> 
>> On Oct 31, 2017, at 2:39 PM, David Adams via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> On Wed, Nov 1, 2017 at 10:23 AM, Tim Nevels via 4D_Tech <
>> 4d_tech@lists.4d.com> wrote:
>> 
>> 
>>> I can guess the answer to that. The engineer responsible looked at the
>>> code and said, “yeah I can fix that, but it will be a lot of work”. And
>>> somebody said, "OK then don’t bother. You’ve got more important 
>>> things to
>>> do. We’ll just call it ‘Standard Behavior’”. Pitiful! :(
>>> 
>> 
>> We'll never know. It could be that it is the result of a carefully thought
>> out design.
>> 
>> Then again, you could have a function like Add(2;2) that returns 5 and
>> claim that it's "standard behavior" because it's consistent. No matter
>> what, it's still a bug (except for sufficiently large values of 2.)
>> **********************************************************************
>> 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:4d_tech-unsubscr...@lists.4d.com
>> **********************************************************************
> 
> John Baughman
> Kailua, Hawaii
> (808) 262-0328
> john...@hawaii.rr.com
> 
> 
> 
> 
> 
> **********************************************************************
> 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:4d_tech-unsubscr...@lists.4d.com
> **********************************************************************
------------
Hell is other people 
     Jean-Paul Sartre
**********************************************************************
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:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to