Hi Kirk,
I appreciate how generous you are with answering questions on this forum.
I understand the 1) 2) 3) points you make. I love the fact we can ‘attach’
things to Form. Instead of using process vars. I do not use a single process
var in my most recent projects.
I had to do a weird work-around when I implemented comboBoxes that I could
define with parameters (and they just work).
I have a Form.cBoxes{ } object, which then contains objects that define the
function of the comboBox.
Form.cBoxes[objectName].storeLoc is set to the ‘full path name’ to the
attribute, such as "Form.en_edit.contact"
// The ‘field’ that needed to be updated with the KEY of the selected option
would be something like: //
Form.en_edit.contact // which, say, translates to [Company]contact in classic
4D
When I had done something similar in classic 4D, I could key a pointer to
[Company]contact and update it with something like: CompanyContact->:= $value
But with the key being stored in Form.en_edit.contact, there was no way to do
something similar.
So I had to resort to creating a FORMULA OBJECT that gets executed to do the
update of the .storeLoc
$formula:=Formula from string($storeLoc+":="+Qu ($UUID)) // $storeLoc is the
full ‘path’ of the attribute, such as Form.en_edit.contact
// $UUID is the value that needs to be put into
that attribute (i.e. field)
$formula.call() // ...this updates it into the entity’s attribute
Seems cumbersome to need to go about it that way, but it was the only way I
could find to accomplish it. But at least it worked.
The complexity is that when I define the comboBox specs, the storeLoc must be
text, like “Form.en_edit.contact"
Seems counter-intuitive to need to resort to a similar mechanism just to coerce
a way to update a value of a form object (i.e. a ‘variable’ on a form).
Chris
————
> On Feb 4, 2020, at 7:57 AM, Kirk Brooks via 4D_Tech <[email protected]>
> wrote:
>
> Chris,
> For a listbox the equivalent of 'self' is the Current Item Datasource.
> Let's say that is Form.LB.currentItem in keeping with your example. (It
> could be something else just as well.) This is the object that corresponds
> to the listbox row generally speaking. So you could have a method that
> validates and formats the whole object that you pass that object to.
>
> If it's a big object and this would take noticeable time or you need to do
> something more elaborate like lookups you can know still use the row and
> column (LISTBOX GET CELL POSITION) to work out what's changed.
>
> The object script has access to This. So you could use
> This.FirstName:=Uppercase(This.FirstName) in the column script.
>
> When using ORDA on a form keep in mind changing the data is what we want to
> do. The display will update itself if you are using Expressions.
>
> Let's say I have an Input I want to capitalize instead of a listbox column.
> Let's say Form.myInput is the expression and the input object is named
> InputObject. When the user changes the data I have options:
>
> 1) Self->:= Uppercase(Self->)
>
> 2) Object get pointer(Object named;"InputObject")->:=Uppercase(Object get
> pointer(Object named;"InputObject")->)
>
> 3) Form.myInput:=Uppercase(Form.myInput)
>
> #1 is the old-school approach. Simple but opaque (what exactly is Self
> pointing at?)
> #2 is the newer-school approach taking advantage of dynamic variables.
> Better sense of what is being operated on.
> #3 simply updates the property value directly. Completely transparent about
> what we are acting on.
>
> #1 and #2 are manipulating the input object which then updates Form.myInput
> whereas #3 simply updates Form.myInput directly and then the form input
> updates itself to reflect that.
>
> Hope this helps.
>
>
> On Mon, Feb 3, 2020 at 7:35 PM Chris Belanger via 4D_Tech <
> [email protected]> wrote:
>
>> What a weird ’subject’ for this question. Sorry. Seems quite confusing.
>>
>> ————
>>
>> Say that the “variable or expression” for a on-screen object is
>> Form.LB.Browser.en_edit.FirstName
>> This is entirely reasonable, as 4D’s ORDA has taught us to use such
>> ‘expressions’ for the fields
>>
>> BUT in the script for this, there is no way to use Self (as there would be
>> if it was a 4D variable) because it is an ATTRIBUTE of an object.
>>
>> This is stupid.
>> It makes it impossible to write a script as simple as:
>>
>> Self->:= Uppercase(Self->)
>>
>> Because Self returns a nil pointer.
>>
>> So how on earth do we retrieve and set the value under these
>> circumstances? [GENERICALLY; I do not want to use the object’s “expression”
>> in the script]
>>
>> There is no such 4D method as OBJECT Get Value( ) OBJECT SET VALUE( )
>> If there were, we could write:
>>
>> OBJECT SET VALUE(*; OBJECT Get Name; Uppercase( OBJECT Get Value(Object
>> Get Name) ) ) // really cumbersome, but is hypothetical because there is
>> no ‘OBJECT GET / SET VALUE’ command.
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
