On Oct 31, 2017, at 10:32 PM, Keisuke Miyako via 4D_Tech <4d_tech@lists.4d.com>
wrote:
> but that's not how references work.
>
> for example, imagine a method that does this:
>
> // myMethod
> C_OBJECT($0)
> $0:=[myTable]myField
>
> it is possible to do something like this:
>
>
On Oct 31, 2017, at 9:17 PM, Keisuke Miyako via 4D_Tech <4d_tech@lists.4d.com>
wrote:
> but objects are references, so it is possible to modify the field without
> "touching" it.
> the object notation is one way to do that.
> but it is also possible using classic coding,
> whereby you obtain a
Hi Bernd,
> Problem is: how does the public find that forum?
Sorry - I was wrong about the public visibility of that particular subforum. It
does appear to require a login, any user account should work (it does not need
to be a partner). Once you have logged in to the forums you can find the
+1 - all of it
On Wed, Nov 1, 2017 at 9:56 PM, David Adams via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> Thanks to TIm and Brian for responding here, always appreciated.
>
> There is no lack of clarity from 4D that the official channel is to post on
> the forums. Before that, it was bugs.4d.fr.
.nabble.com/Re-Warning-Settings-properties-values-on-object-field-by-object-notation-td5755127.html
I guess 4D does not allow internal staffs filing feature request.
Alan chan
4D iNug Technical <4d_tech@lists.4d.com> writes:
>These arguments should be posted on the feature request fo
Thanks to TIm and Brian for responding here, always appreciated.
There is no lack of clarity from 4D that the official channel is to post on
the forums. Before that, it was bugs.4d.fr. That's always been clear. Heck,
I can't even count the number of times I said that on this list over the
years.
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.
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
I think the “standard behaviour” answer is a mistake on the part of 4D, and I
hope they will reconsider their stand on this.
As others have said, “Target:=value“ should always mean the target gets changed
to the value.
Anything else is “non-standard behaviour”.
It may be tricky to make it
On Nov 1, 2017, at 4:01 PM, Timothy Penner wrote:
> I am sorry if you do not see the information I am providing as helpful. I
> sincerely feel bad for the people who have been bitten by this bug and I am
> trying to help the situation by asking the doc team to update the docs, and
> also at
> Does 4D realize that *officially* ignoring their customers isn't exactly an
> example of great customer service.
I am not ignoring customers; I am responding. I am directing people in the
right direction, the direction of the official channels... My intent is to help
the customers get better
> So, if you want to officially request such a change, it needs to go on
the forums.
Does 4D realize that *officially* ignoring their customers isn't exactly an
example of great customer service.
I tried the forums for about six months, I don't think I got _any_
information from 4D Engineering,
Hi Tim,
We have official channels for reporting issues, feature requests, and bugs.
- Requests for help/answers are handled through taow.4d.com
- Feature requests are handled through forums.4d.com
- Bugs are also handled through the forums but partners can get help filing the
bug via taow.4d.com
On Nov 1, 2017, at 2:00 PM, Timothy Penner wrote:
>> It is good we are having this discussion because this will lead to a
>> change/solution to this issue.
>
> This discussion would more constructive if it took place on the Feature
> Request forum.
>
> As described in tech tip 76725;
> {
>
Tim,
On Wed, Nov 1, 2017 at 10:13 AM, Tim Nevels via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> On Nov 1, 2017, at 11:04 AM, Keisuke Miyako wrote:
>
> > like a global preference, to the effect of
> >
> > "Call OB Copy implicitly when performing object assignments"
> >
> > it is an interesting
On 11/1/17, 2:08 PM, "4D_Tech on behalf of Tom Swenson via 4D_Tech"
<4d_tech-boun...@lists.4d.com on behalf of 4d_tech@lists.4d.com> wrote:
➢ And, yes, I too was told that the engineers were leaning to declaring
this as standard behavior. Why? I have not a clue.
Ooops, I was just
➢ And, yes, I too was told that the engineers were leaning to declaring this as
standard behavior. Why? I have not a clue.
**
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive:
> It is good we are having this discussion because this will lead to a
> change/solution to this issue.
This discussion would more constructive if it took place on the Feature Request
forum.
As described in tech tip 76725;
{
Feature requests are handled on the 4D Forums:
On Nov 1, 2017, at 11:04 AM, Keisuke Miyako wrote:
> like a global preference, to the effect of
>
> "Call OB Copy implicitly when performing object assignments"
>
> it is an interesting point of view,
> to frame it as an issue of the assignment operator being different,
> as opposed to how
> Le 1 nov. 2017 à 02:46, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> a écrit
> :
>
> The real “sloppy” part is that this was not documented with a big red flag
> saying something like “object fields don’t work like other fields so if you
> do this … it does not work the same as if you do
On Wed, Nov 1, 2017 at 2:17 AM, Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:
>
> to explicitly indicate that the object has been modified, just use the line
>
> [myTable]myObjectField:=[myTable]myObjectField
>
YEs, I use wrapper around SAVE RECORD, so can put there
> it is an interesting point of view,
> to frame it as an issue of the assignment operator being different,
> as opposed to how objects and their properties are different "because
they are references".
I think that the real issue for a 4D programmer is that a record is a
persistent data store and
like a global preference, to the effect of
"Call OB Copy implicitly when performing object assignments"
it is an interesting point of view,
to frame it as an issue of the assignment operator being different,
as opposed to how objects and their properties are different "because they are
This bug was first discovered in July of 2016. See the NUG thread "Does 4D
Support Dotted Notation in Object Fields?” if you are interested in how it was
discovered (thanks to Douglas Von Roeder). ACI0095526.
Even though I filed the bug report, I can think of at least twice since then
that
Is a ‘2’ in BOLD type sufficiently large, David?
> On Oct 31, 2017, at 5: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
I hate to repeat myself,
but it seems the problem with object notation
is that it's not as straightforward to know if a field has been changed or not.
perhaps until now,
we have been thinking of simply code like
[myTable]myField.prop:="123"
and it seems crazy that 4D doesn't understand that the
On Wed, Nov 1, 2017 at 1:05 PM, Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:
>
> I thought it was also quite clear in Tim's reply which was reposted here,
> that we failed you on this, and that we are in the process of updating the
> documentation.
>
If changing a field and then
I wasn't trying to avoid taking responsibility,
I feel very sorry for that.
I thought it was also quite clear in Tim's reply which was reposted here,
that we failed you on this, and that we are in the process of updating the
documentation.
but again, I apologise.
> 2017/11/01 10:46、Tim Nevels
On Oct 31, 2017, at 8:17 PM, Keisuke Miyako wrote:
> to explicitly indicate that the object has been modified, just use the line
>
> [myTable]myObjectField:=[myTable]myObjectField
>
> and you have total control of when to save the field,
> which results in better performance, immediately as
Quackers.
> On Oct 31, 2017, at 9:17 PM, Keisuke Miyako via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
> "standard behaviour" is a specific term that means the result is "expected,
> if not intended" by design or specification.
Keisuke,
I don't think anyone is arguing for a 'Save always' system.
I think we are saying IF the data (inside the object field) has been modified -
it needs to be saved, if the request is made to save the record, REGARDLESS of
how the modification occurred.
a direct assignment
via dot
> On Oct 31, 2017, at 3:17 PM, Keisuke Miyako via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
> to explicitly indicate that the object has been modified, just use the line
>
> [myTable]myObjectField:=[myTable]myObjectField
>
> and you have total control of when to save the field,
> which
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
> OB SET ([Table1]Object;”value”;b_value) //this will set the record dirty.
> And, yes, I too was told that the engineers were leaning to declaring
> this as standard behavior. Why? I have not a clue.
obviously I can't speak for "the engineers", but I would not rush to the
conclusion that it is
>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.
It's a bug. If 4D wants to document it as standard behavior, that's their
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
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
On Oct 31, 2017, at 2:00 PM, Chip Scheide wrote:
> OB SET ([Table1]Object;”value”;b_value) //this will set the record dirty.
>
> And, yes, I too was told that the engineers were leaning to declaring
> this as standard behavior. Why? I have not a clue.
I can guess the answer to that. The
I’m glad I came in today.
> On Oct 31, 2017, at 1:35 PM, Charles Miller via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
> It must be a duck, cause calling this standard behavior is quackers.
**
4D Internet Users Group (4D
It must be a duck, cause calling this standard behavior is quackers. There
are many issues with object fields. I for one refuse to use them (Yes I
know how powerful they are and can be) as I do so much with sql and can not
get them using a sql statement. I have commented before that 4D should not
> It looks like this bug ACI0097454 was marked as Standard Behavior on
October 24th.
Smells like a bug.
Looks like a bug.
Sounds like a bug.
Walks like a bug.
I mean, if you have a light switch that gives you a shock every time you
touch it, you wouldn't say "Oh, it always does that. It's
THIS is definitely a bug.
Past behavior is if a field is modified (even assigning itself to
itself) sets the 'dirty' flag, and the ENTIRE record is to be saved.
On Tue, 31 Oct 2017 09:58:09 -1000, John Baughman via 4D_Tech wrote:
>
> ALL RECORDS([Patient Record])
> [Patient Record]
>
> The problem is that the dirty flag is not set when dot notation is
> used against an object field. In your scenario the following will work
> …
field modified = field modified --right?!?!
> OB SET ([Table1]Object;”value”;b_value) //this will set the record dirty.
>
> And, yes, I
> Le 31 oct. 2017 à 05:03, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> a
> écrit :
>
> Alberto,
> doesn't Goto REcord ([table];0) - generate an error?
> there is no record number 0
Hi Chip,
"physical" record numbers start from zero, see here:
Chip,
Record 0 is the first record in the table.
Of course it may have been deleted and the number not reallocated.
Regards,
Wayne
Sent from my iPhone
> On 31 Oct 2017, at 15:03, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> Alberto,
> doesn't Goto REcord ([table];0) -
On Tue, Oct 31, 2017 at 8:21 AM, Alberto Bachler via 4D_Tech <
4d_tech@lists.4d.com> wrote:
Just a quick note of thanks for posting this behavior to the list.
On Tue, Oct 31, 2017 at 3:49 PM, John Baughman via 4D_Tech <
4d_tech@lists.4d.com> wrote:
...and to you too John for posting that you
On Tue, Oct 31, 2017 at 3:49 PM, John Baughman via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> And, yes, I too was told that the engineers were leaning to declaring this
> as standard behavior. Why? I have not a clue.
>
I'm failing to come up with any good arguments in support of such a
posture.
I went through the same thing with TS. Tim will probably chime in.
The problem is that the dirty flag is not set when dot notation is used against
an object field. In your scenario the following will work…
OB SET ([Table1]Object;”value”;b_value) //this will set the record dirty.
And, yes, I
Alberto,
doesn't Goto REcord ([table];0) - generate an error?
there is no record number 0
from documentation :
If record is less than the smallest record number in the database or greater
than the greatest record number in the database
> Hello,
>
> If the value of a property is modified using
49 matches
Mail list logo
