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
>> <[email protected]> wrote:
>>
>> On Wed, Nov 1, 2017 at 10:23 AM, Tim Nevels via 4D_Tech <
>> [email protected]> 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:[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]
> **********************************************************************
------------
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:[email protected]
**********************************************************************
