Bernard,
This works perfectly fine until you use an object member as your data source.
Once you do that, the Object get pointer command will return a nil pointer.
In your example, put Form.Note as your data source (Variable or Expression),
run it and see what you get
Regards,
Lahav
Why not use Form event.objectName ?
I find it very useful ; I use it and write in form method :
Case of
:(Form event.code=On data change)
Case of
:(Form event.objectName="Name)
Object get pointer(Object named;"Name")->:=MyMethodUppercase(
Object get pointer(Object
Jim:
"This is pretty much the same way you enumerate in reverse order in the
other languages I use.”
Thank you for posting that.
I brought this up on the Forum a while back and I even brought it up in a
tech support call but…nada.
Interesting thread -
I agreed on your request. Thanks for initiating it. Hopefully more will see its
value and join in. — CB
> On May 2, 2020, at 12:42 AM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
>
> I've created a feature request on the new forum. Voting is open.
>
> Lahav
>
> -Original
> On May 1, 2020, at 1:13 PM, James Crate via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
>> Here is an idea which seems to work, but needs more evaluation. What if you
>> named the form object with the property path in the form data? Even if
>> periods are not allowed (they seem to be),
I've created a feature request on the new forum. Voting is open.
Lahav
-Original Message-
From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Kirk Brooks via
4D_Tech
Sent: Friday, May 1, 2020 3:13 PM
To: 4D iNug Technical <4d_tech@lists.4d.com>
Cc: Kirk Brooks
Subject: Re:
Lahav,
not 'That', 'This' :)
Chip
>
>> I have one word that will do all of what we are after : "This"
>>
> Damn - I wish I'd said that.
Hell is other people
Jean-Paul Sartre
**
4D Internet Users Group (4D
On Apr 30, 2020, at 9:36 PM, Douglas von Roeder via 4D_Tech
<4d_tech@lists.4d.com> wrote:
>
> Another WTF is that you can’t iterate from the end of a collection to the
> start. You can reorder the collection and then run a For each loop but
> that’s a complete kludge.
For each
On May 1, 2020, at 3:44 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
wrote:
>
> I have not had any great joy attempting to use pop-ups with object
> references. Haven't tried in v18 so maybe it's improved.
In V17, popups work with form object expressions. If you set the expression to
Exactly. Lahav really gets it. — CB
> On May 1, 2020, at 2:51 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
>
> Kirk,
>
> I have one word that will do all of what we are after : "This"
>
> It works in listbox, which is a form object, any reason it can't be extended
> to other form
Hi Kirk,
Thanks for replying.
I think I stated this much earlier in this thread, but the project I am working
on is ENTIRELY orda / object based. I do not mix ‘classic’ into it; except I
would say some 4D commands basically still are ‘classic-oriented’ but they are
working on ‘ORDA-izing’ it. I
Lahav,
On Fri, May 1, 2020 at 1:51 PM lists via 4D_Tech <4d_tech@lists.4d.com>
wrote:
> I have one word that will do all of what we are after : "This"
>
Damn - I wish I'd said that.
> Again, I don't think anyone on this thread is complaining, we are just
> trying to understand how to use the
Kirk,
I have one word that will do all of what we are after : "This"
It works in listbox, which is a form object, any reason it can't be extended to
other form objects?
Again, I don't think anyone on this thread is complaining, we are just trying
to understand how to use the new
Tim Nevels wrote:
>if you want to use entities or use collections AreaList Pro is out of the
>picture.
As posted on e-node’s forum two weeks ago: “ALP v11 will definitely support
entity selections and collections. Mostly it seems to already work in ALP
11.0a5"
It may not do everything you
Jim,
On Fri, May 1, 2020 at 11:53 AM James Crate via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> Suppose you have a section on the form with labels/fields for payment
> info. You have a popup with payment type, and fields for credit card, ACH
> (bank name/acct number), check, cash. When you choose
Chris,
On Tue, Apr 28, 2020 at 10:53 PM Chris Belanger via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> Generic programming of vars on a form is very complicated when one uses
> object attributes for the data source.
>
> For example, on screen you make a simple text input object named
> “enCompany”.
On May 1, 2020, at 2:23 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
wrote:
>
> On Fri, May 1, 2020 at 11:14 AM James Crate via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
>> The problem with this approach, as others have mentioned, is that you can
>> no longer use object name prefixes to
Jim,
On Fri, May 1, 2020 at 11:14 AM James Crate via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> The problem with this approach, as others have mentioned, is that you can
> no longer use object name prefixes to show/hide/enable/etc groups of form
> objects.
>
Why do you say that?
In v18R2 I'm
On May 1, 2020, at 10:07 AM, John DeSoi via 4D_Tech <4d_tech@lists.4d.com>
wrote:
> Here is an idea which seems to work, but needs more evaluation. What if you
> named the form object with the property path in the form data? Even if
> periods are not allowed (they seem to be), another
Here is an idea which seems to work, but needs more evaluation. What if you
named the form object with the property path in the form data? Even if periods
are not allowed (they seem to be), another character could be used. I think the
maximum length of an object name is 255 characters which
On Apr 30, 2020, at 10:00 PM, Douglas von Roeder wrote:
> Another WTF is that you can’t iterate from the end of a collection to the
> start. You can reorder the collection and then run a For each loop but
> that’s a complete kludge. Dollars to doughnuts, 4D will eventually add a
> parameter to
"If we could at least get the DATA SOURCE of the object that is using
object notation as its data source, it would be nice:”
Feature request time!
Back in 2018 (way back then!), I asked to be able to get the table number
for a entity selection and got the equivalent of “Why would you want to do
"Just for discussion sake, I'd say that a good portion of long established
systems have 100% of their space already occupied by classic code….”
Couldn’t agree more!
As the average age of installed base of programmers decreases, the % of
“classic” code in production systems will drop (hat’s the
You say things much more succinctly and clearly than do I, Lahav. I agree.
— Chris
> On Apr 30, 2020, at 3:43 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
>
> OK, based on this design, we are back to using variables (or dynamic
> variables) for data entry of anything that needs any kind
I thoroughly enjoy using object notation and the Form. object. That is why I
want a way to continue to use it to designate the data source of form objects.
I have read and re-read Keisuke’s comment, and there are aspects I do not
comprehend. I thought that the attachment between form object and
Hi Chris,
What we really need is a way to access a Form Object's "Variable or
Expression". There's a Command named "Object Get Data Source" which was
added in v14, but it only returns a Pointer if "Variable or Expression" is
a Variable. If it's an Expression it returns Nil.
If we could get
Doug,
Just for discussion sake, I'd say that a good portion of long established
systems have 100% of their space already occupied by classic code
The use of the Form object offers so much that I am resigned to let go of some
generic code, not happy, but willing to pay that price.
Lahav
Randy:
"If there is such an issue trying to get object values to work right,
what’s the reason to use them at all?”
The new language is extremely powerful and I found it quite easy to pick up
(mostly). The fact that it doesn’t give us 100% backward compatibility is
not unexpected.
"I know
> On Apr 30, 2020, at 4:43 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
>
> OK, based on this design, we are back to using variables (or dynamic
> variables) for data entry of anything that needs any kind of processing done
> to it after an entry, having to load the values to these data
OK, based on this design, we are back to using variables (or dynamic variables)
for data entry of anything that needs any kind of processing done to it after
an entry, having to load the values to these data entry objects when loading
the form, and copying the values back when we want to save
Indeed, if you are using a process or an IP variables to hold the entity (or
object for that matter), you will get a pointer to that variable. But if you
are using the Form.XXX notation and eliminate the use of process or IP
variables, the pointer always return Nil, so it's useless.
The
I can only share how I would design my user interface,
but in short, I would not have this problem
> (Object get name).prettyFormat()
and here's why.
I see that the form object should either be bound to (=managed automatically by
4D)
or divorced from (managed by me) its data source.
the
Agree with Lahav.
I think the point of OBJECT NAMES is to also help with SHOW/HIDE objects on
screen by OBJECT SET VISIBLE ( *; “Prefix@“) sort of thing.
The object name should not need to be exactly what the ‘Variable or expression’
is.
And besides, there would be quite a problem if the object
Sorry, meant to say the pointer that results from the Object Get name is to the
entity
> On Apr 30, 2020, at 3:59 PM, kculotta via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> 18.1
>
> The pointer OBJECT Get name(Object current) is to the entity instead of the
> to the entity attribute.
>
>
18.1
The pointer OBJECT Get name(Object current) is to the entity instead of the to
the entity attribute.
The field is eg, MyEntity.MyName, but the pointer to the form object ends up
being ->MyEntity
> On Apr 30, 2020, at 3:52 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
>
> Sorry,
Sorry, Are you saying that you can get a valid pointer with Object get
pointer() on a dot notation object of a form?, if so what version?
Lahav
-Original Message-
From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via 4D_Tech
Sent: Thursday, April 30, 2020 2:50 PM
To: 4D
Yes, I'm using it, but it really seems like an artificial way to get an entity
field's displayed contents.
I'll explore your example.
Keith - CDI
> On Apr 30, 2020, at 3:45 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
>
> Did you actually test this?, any kind of a get pointer on a form
Did you actually test this?, any kind of a get pointer on a form object having
a dot notation source will return a Nil pointer, regardless of the name
matching or not.
If you are using matched names, you could use the following:
Form[Object get name(object current)]:=DoWhatever(Form[Object get
Is there a "Get edited text without having to type anything first" kind of
function.
Does an entry area have an Object that contains its type and contents?
> On Apr 30, 2020, at 2:58 PM, Chris Belanger via 4D_Tech
> <4d_tech@lists.4d.com> wrote:
>
> Exactly … that is my question. — Chris
>
This example does not avoid having to carefully name form objects and
the form object must have "matching" variable and object names: variable
entity.MyName with its object name of "MyName"
// the object method
a_test (OBJECT Get name(Object current))
// a_Test
$ent:=OBJECT Get pointer(Object
Exactly … that is my question. — Chris
> On Apr 29, 2020, at 11:15 AM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
>
> OK, so can we get a real example of how to replace the *old* way with the
> new? In a case where there are several entry objects:
>
> Form.Name
> Form.Address
> Form.Note
I don’t wish to imply that I ‘prefer’ pointers; in fact, I am not using a
single process variable, interprocess variable, or any other ‘vestiges’ of 4D
Classic. I am ‘fully committed’ to object notation. I also use Storage
extensively for system-wide values, and really love it.
The problem I
I drank deeply from the “dynamic variables” Koolaid well with the release
of V12. As soon as I started working with Form.foo, I ran headlong into the
issue described above.
The email thread "One Set of Code for Form Object Populated Forms as well
as Field-Based Detail View Forms” may shed some
OK, so can we get a real example of how to replace the *old* way with the new?
In a case where there are several entry objects:
Form.Name
Form.Address
Form.Note
I want to enforce a proper uppercase/lowercase on all three, so in the old days
I created an object, set the method to
my feeling is that generic coding is very much possible in object notation,
but we need to accept that the approach is different.
if you prefer to use pointers such as "Self",
I think it's best to avoid object notation,
at least if your goal is to make the code generic.
it's not a defect of
*OBJECT Get pointer*(Object named;"")
does return the Form object.
If you standardise your naming convention of the form field objects you
could determine the sub object and attribute you're looking for.
example:
FormObj_Wrap_Trim("en_company";"name")
FormObj_Wrap_Trim:
$vT_Object:=*$1*
quite simple actually, just get a pointer to the actual form element
in the object method just call:
OBJECT GET POINTER (object current)
you can even go one further und just put all that into the form method:
If (Form event code=On Data Change)
$p_entry:=OBJECT Get pointer(Object with
47 matches
Mail list logo
