Re: V18 plugins not showing as Notarized?

[Ronald Rosell via 4D_Tech]

I knew it would be something simple.  I’d actually completely forgotten that 4D 
InternetCommands is included in the 4D application package … I’ve generally had 
a copy in the database folder -> Plugins when compiling.

I just took that latter copy out, relaunched, and problem solved!  Thank you 
Miyako!

Ron Rosell
__

Ron Rosell
President
StreamLMS

> On Apr 30, 2020, at 9:29 PM, Keisuke Miyako via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> only the plugins pre-installed with the application (inside 4D or 4D Server) 
> are notarised.
> 
> the folder adjacent to the application are copies for distribution and 
> therefore not code signed at all.
> 
>> On May 1, 2020, at 12:00, Ronald Rosell via 4D_Tech <4d_tech@lists.4d.com> 
>> wrote:
>> Executing codesign --verify -- verbose against 4D InternetCommands.bundle, 
>> for example, brings back:
>>  /Applications/4D v18.1/Plugins/4D InternetCommands.bundle: code object 
>> is not signed at all
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: V18 plugins not showing as Notarized?

[Keisuke Miyako via 4D_Tech]

only the plugins pre-installed with the application (inside 4D or 4D Server) 
are notarised.

the folder adjacent to the application are copies for distribution and 
therefore not code signed at all.

> On May 1, 2020, at 12:00, Ronald Rosell via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> Executing codesign --verify -- verbose against 4D InternetCommands.bundle, 
> for example, brings back:
>   /Applications/4D v18.1/Plugins/4D InternetCommands.bundle: code object 
> is not signed at all

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[Tim Nevels via 4D_Tech]

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 the For each so that we don’t have to use that workaround.
> 
> As Tim Nevels is wont to say (paraphrasing) “This just the beginning - have
> patience!"

I see my name… and have to say “he’s right”. 4D is operating in a mode where 
they release what they can as quickly as they can. They don’t wait literally 
years to build a complete, finished product/feature set. They are in RAD mode. 
The “R” release is the example of that. We are getting a lot of features very, 
very fast. 

Yes, there are always some that complain that they are not getting everything 
right now. It is too slow. It is not complete. Why do we not have this or that? 
Gentlemen... grow up. Only babies don’t understand that you can’t have 
everything immediately. If 4D did what you claim you wanted — deliver a feature 
complete and totally stable new feature set — you’d be wait literally years. 
And you would then say “4D is doing nothing, I’ve seen nothing new for YEARS!"

I am 100% on 4D’s side. In my opinion they have made a good decision with doing 
the “R” releases and putting out new features every 3 months. Remember that you 
get a new “R” release every 3 months. Every 3 months you get new feature and 
more things that you did not have before. And now with the 2 year major Long 
Term Support (LTS) cycle you are going to get 8 “R” releases of new features 
every 3 months. Then you get a new, major LTS version that has 2 years worth of 
development work. 

And it will be a solid release. A deployable x.0 release. That’s the goal at 
least. And They got very, very close with v17.0. Unknown how much closer they 
got with v18.0 release. But for sure it is 1,000 times better than v11.0, or 
v12.0 or v13.0. I lived through v11, v12 and v13 at client sites in production. 
And back then EVERYONE with any sense waited for .2 or .3 before deploying to 
production at client sites. 

I deployed v17.0 at client sites — first time in my life I deployed a 4D x.0. 
And I continued to upgrade them to .1 and .2 and using hot fix version. My 
current v17 version is v17.3 HF2. Yeah… I know 17.4 has been releases and I’ll 
most likely upgrade to that at some point. But v17.3 HF2 fixed enough and was 
“good enough” that I’m happy with it.

ORDA and the new “classes” and the even more exciting web based options 4D is 
building will give us more options. Some we can use and incorporate into 
existing code easily. Some of the new feature REQUIRE doing new code. 
Retrofitting will not be possible or will not give you the desired results. 
Sometimes you just have to start over. I’ll give you an example… listboxes.

First there were no listboxes, so AreaList was created. And it filled a needed 
hole in the 4D environment. So we all used AreaList Pro and loved it. And built 
big code libraries with it. Then 4D implemented listboxes, but it did not 
compete with AreaList in many areas. So for something “simple” you would use a 
listbox, but for the power and features you stayed with AreaList Pro. Now that 
gap is very small. 4D listboxes are very close to the power and feature set of 
AreaList Pro. And if you want to use entities or use collections AreaList Pro 
is out of the picture. 4D listboxes are the only option. So throw the AreaList 
Pro code library away and start over. 

4D has ramped up to deliver a lot of fantastic, new and advanced features to 
the platform. They are doing it in pieces. It’s going to take time. But by 
releasing it in pieces over the next 2 years we will have time to get to know 
it, and learn it, and plan for it and figure out how we can integrate it into 
our existing projects. 

And to get some of the benefits we will need to start over. And we have to wait 
for the feature set to be completed. No retrofitting. All new code. But we get 
to choose if we do this. We can choose to not make the jump. Stay in “classic” 
mode and that’s OK. It’s a client driven world. If they don’t want to pay for 
it — and you don’t want to rewrite it all for free — you keep on the current 
path. Totally cool and supported. 

No 4D Summit 2020. It went virtual and online and it’s free. So zero complaints 
here.. other than missing seeing all my “old friends” again. I did miss that. A 
lot. 

2021 there will be 4D World Tour — as usual. And it will be filled with v18 “R” 
release “goodies”. So I’m looking forward to that. 

2022 will be another 4D Summit… and the release of 4D v19. 2 years worth of 
development that will finally be completed and released. It’s gonna be a big 
deal!

The TV show Kung Fu… I loved that show when it was on TV in reruns. (I have the 
entire series on DVD and have watched it all from beginning to end a few years 
ago.)

V18 plugins not showing as Notarized?

[Ronald Rosell via 4D_Tech]

Hi folks,

My apologies if this is a “RTFM” question, but I’ve searched the Knowledge 
Base, and the NUG archive, but haven’t found an answer to this problem.  (The 
4D support portal also appears to be having issues at the moment.)

I’m in the process of upgrading from v17.4 to v18.1, in large part to be able 
to run properly under Catalina.

I’m finding, however, that none of the 4D-provided set of plugins … Internet 
commands, etc. … are showing up as Notarized.  

Executing codesign --verify -- verbose against 4D InternetCommands.bundle, for 
example, brings back:

/Applications/4D v18.1/Plugins/4D InternetCommands.bundle: code object 
is not signed at all

Opening a structure that uses Internet Commands in 4D Developer throws an error 
message pointing to the unsigned plugin.  The structure compiles without 
errors, but opening the compiled database in 4D server generates the same 
unsigned plugin message about Internet Commands.

I’m not building a stand-alone application here, so not registering with Apple 
as a developer with signing privileges, just planning to have Server open and 
run a compiled structure.  (Most of the posts about notarization in the NUG 
appear to be for application developers producing standalone apps.)

I must be missing something basic.  (And yes, I’m sure I’m using the v18 
plugins, not v17.) Could someone please point me in the right direction?

Thanks!
__

Ron Rosell
President
StreamLMS

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[Douglas von Roeder via 4D_Tech]

"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
that?!". Lo and behold, it showed up a few R releases later.

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 the For each so that we don’t have to use that workaround.

As Tim Nevels is wont to say (paraphrasing) “This just the beginning - have
patience!"

--
Douglas von Roeder
949-910-4084


On Thu, Apr 30, 2020 at 6:22 PM Chris Belanger via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> 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 data
> source object is an integral relationship and I can’t see how using the
> form object to obtain its underlying data source [an attribute of an
> object] is so bad.
> And I am trying to understand the counsel:
> >
> >  "I would focus my use of object notation to areas where classic
> > code could not go, not spaces already occupied by classic code."
>
>
> Not to mean any disrespect to Keisuke. He is one of the brightest 4D
> programmers around.
> But somehow this goes over my head. It is too philosophical to comprehend;
> almost metaphysical. When I examine code that Keisuke creates, it is
> elegant. I am confused as to how he would actually accomplish what we have
> been discussing in an object script — would he use ‘classic 4D’ on some
> screen elements, and not on others?
> I do not want to resort to a mixture of ‘classic’ and object notation.
> In the ‘perfect implementation’, within an object’s script:
>
> This.value := Pretty_Format(This.value)   // or something like this
>
> “This” would give you access to the data source (being as it is basically
> an attribute of an object, like Form.en_This.Company.Name).
>
> I understand that it creates some potential for confusion in the case of
> something like:
> Form.en_This.Company.Name
>
> In that this is actually an entity attribute. Perhaps the coder would
> somehow start trying to extrapolate other attributes from its entity (i.e.
> “owner").
> While one can traverse down the path  (eg. Form[en_This][Company][Name] )
> one cannot traverse up the path as in:
>
> Let $attribute  = Form.en_This.Company.Name // i.e. that is what
> $attribute is; pseudo-code
> $attribute.owner  is  Form.en_This.Company  // hypothetical
> code
>   ( applied to Form.en_This.Company.Name giving   Form.en_This.Company
> [in this case, an entity] )
>
> 
> 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:
> But:
> OBJECT Get data source ( *; $objName )   returns Nil for form objects (dot
> notation) because it returns a pointer.
>
>
> So it seems the only way to get the ’simple script’ is to do something
> like hard-coding:
> $temp:=Pretty_Format(Form.en_This.Company.Name) // so we don’t
> ’touch’ an attribute unnecessarily, triggering a save condition
> If   (Form.en_This.Company.Name # $temp) // if the formatting
> would change the value
> Form.en_This.Company.Name:= $temp
> End if
> And propagate it all over the place.
>
> — Chris
>
>
> > On Apr 30, 2020, at 6:23 PM, lists via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
> >
> > 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
> >
> > -Original Message-
> > From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Douglas von
> Roeder via 4D_Tech
> > Sent: Thursday, April 30, 2020 5:51 PM
> > To: 4D iNug Technical <4d_tech@lists.4d.com>
> > Cc: Douglas von Roeder 
> > Subject: Re: Object notation replacement for use of Self in a script —
> v18
> >
> > 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 everyone is all excited about object notation, but it’s not
> mandatory.  Why should we even consider using it if doesn’t do what we
> need?  I’m sure there are some areas where it’s useful, but it sounds like
> 

Re: Object notation replacement for use of Self in a script — v18

[Douglas von Roeder via 4D_Tech]

"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 audience that
will use ORDA + OOP in 4D)

"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.”
Agreed.

If change wasn’t an inherent part of all facets of life, life would have
stopped at the amoeba.
--
Douglas von Roeder
949-910-4084


On Thu, Apr 30, 2020 at 5:23 PM lists via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> 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
>
> -Original Message-
> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Douglas von
> Roeder via 4D_Tech
> Sent: Thursday, April 30, 2020 5:51 PM
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Cc: Douglas von Roeder 
> Subject: Re: Object notation replacement for use of Self in a script — v18
>
> 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 everyone is all excited about object notation, but it’s not
> mandatory.  Why should we even consider using it if doesn’t do what we
> need?  I’m sure there are some areas where it’s useful, but it sounds like
> there’s a lot where it isn’t.  Am I missing something”
> “[doing everything that] we need” is a pretty high bar, wouldn’t you
> agree? For me, I’ve been using ObjectTools + constructors since the late
> 90’s, biding my time for 4D to adopt objects/object notation/OOP. At this
> point, I’ll take what I can get.
>
> While I was quite not-happy with this particular limitation (I have forms
> with hundreds of fields that use Object name that are used with Object get
> pointer), I think the last paragraph of Miyako’s posting, above, is sound
> advice - "I would focus my use of object notation to areas where classic
> code could not go, not spaces already occupied by classic code."
>
> --
> Douglas von Roeder
> 949-910-4084
>
>
> On Thu, Apr 30, 2020 at 3:03 PM Randy Kaempen via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
> >
> > > 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 entry objects when loading the form, and copying the values
> > back when we want to save any user changes.
> > >
> > > OR
> > >
> > > We can use the Form.XXX notation to gain the advantage of that new
> > > nifty
> > option, but lose the generic coding ability.
> > >
> > > I'd say it's a choice, but the lack of the ability to address an
> > > object
> > from within generically definitely seems to be a glaring omission...
> >
> > If there is such an issue trying to get object values to work right,
> > what’s the reason to use them at all?
> >
> > I know everyone is all excited about object notation, but it’s not
> > mandatory.  Why should we even consider using it if doesn’t do what we
> > need?  I’m sure there are some areas where it’s useful, but it sounds
> > like there’s a lot where it isn’t.  Am I missing something?
> >
> >
> > Randy Kaempen
> > Intellex Corporation
> >
> > **
> > 4D Internet Users Group (4D iNUG)
> > Archive:  http://lists.4d.com/archives.html
> > Options: https://lists.4d.com/mailman/options/4d_tech
> > Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> > **
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
**
4D Internet Users Group 

Re: Object notation replacement for use of Self in a script — v18

[Chris Belanger via 4D_Tech]

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 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 any 
> user changes.
> 
> OR
> 
> We can use the Form.XXX notation to gain the advantage of that new nifty 
> option, but lose the generic coding ability.
> 
> I'd say it's a choice, but the lack of the ability to address an object from 
> within generically definitely seems to be a glaring omission...
> 
> Lahav
> 
> -Original Message-
> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via 
> 4D_Tech
> Sent: Thursday, April 30, 2020 3:20 PM
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Cc: Keisuke Miyako 
> Subject: Re: Object notation replacement for use of Self in a script — v18
> 
> 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 object name is only interesting to me for visibility, enable/disable, etc.
> I would have some kind of naming convention to take advantage of the @ 
> wildcard, but that's all.
> 
> as for the data source, if I wanted to implement some kind of rule on it, I 
> would do so without the form object.
> 
> in other words, I would only use object notation on form objects that do not 
> need to use form events.
> in my opinion, any form object that do use a form event should not have 
> object notation as their data source, since the event is attached to the form 
> object and not the data source object.
> there would be room for programming error if the same data source could be 
> manipulated outside the form event.
> 
> same with the current item/position/selection property of the collection type 
> listbox.
> the properties only make sense in the context of zero-coding.
> if I want to manage the binding by code, I would keep these properties empty.
> 
> classes are coming in 18 R3, but you can already create pseudo-classes by 
> writing custom constructors that return an object with prefab properties and 
> methods.
> 
> until the use of "This" is extended to text inputs and other form objects, I 
> would not expose object notation (which implies that the target is an object) 
> in any of my form objects, other than for form objects that exist purely for 
> display purposes.
> 
> I would focus my use of object notation to areas where classic code could not 
> go, not spaces already occupied by classic code. 
> 
>> On May 1, 2020, at 4:54, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> 
>> wrote:
>> (Object get name).prettyFormatHow would that be achieved?
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[Chris Belanger via 4D_Tech]

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 data source 
object is an integral relationship and I can’t see how using the form object to 
obtain its underlying data source [an attribute of an object] is so bad.
And I am trying to understand the counsel:
> 
>  "I would focus my use of object notation to areas where classic
> code could not go, not spaces already occupied by classic code."


Not to mean any disrespect to Keisuke. He is one of the brightest 4D 
programmers around.
But somehow this goes over my head. It is too philosophical to comprehend; 
almost metaphysical. When I examine code that Keisuke creates, it is elegant. I 
am confused as to how he would actually accomplish what we have been discussing 
in an object script — would he use ‘classic 4D’ on some screen elements, and 
not on others?
I do not want to resort to a mixture of ‘classic’ and object notation.
In the ‘perfect implementation’, within an object’s script:

This.value := Pretty_Format(This.value)   // or something like this

“This” would give you access to the data source (being as it is basically an 
attribute of an object, like Form.en_This.Company.Name).

I understand that it creates some potential for confusion in the case of 
something like:
Form.en_This.Company.Name

In that this is actually an entity attribute. Perhaps the coder would somehow 
start trying to extrapolate other attributes from its entity (i.e. “owner").
While one can traverse down the path  (eg. Form[en_This][Company][Name] ) one 
cannot traverse up the path as in:

Let $attribute  = Form.en_This.Company.Name // i.e. that is what $attribute 
is; pseudo-code
$attribute.owner  is  Form.en_This.Company  // hypothetical code
  ( applied to Form.en_This.Company.Name giving   Form.en_This.Company  [in 
this case, an entity] )


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:
But:
OBJECT Get data source ( *; $objName )   returns Nil for form objects (dot 
notation) because it returns a pointer.


So it seems the only way to get the ’simple script’ is to do something like 
hard-coding:
$temp:=Pretty_Format(Form.en_This.Company.Name) // so we don’t ’touch’ 
an attribute unnecessarily, triggering a save condition
If   (Form.en_This.Company.Name # $temp) // if the formatting would 
change the value
Form.en_This.Company.Name:= $temp
End if
And propagate it all over the place.

— Chris


> On Apr 30, 2020, at 6:23 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
> 
> 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
> 
> -Original Message-
> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Douglas von Roeder 
> via 4D_Tech
> Sent: Thursday, April 30, 2020 5:51 PM
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Cc: Douglas von Roeder 
> Subject: Re: Object notation replacement for use of Self in a script — v18
> 
> 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 everyone is all excited about object notation, but it’s not 
> mandatory.  Why should we even consider using it if doesn’t do what we need?  
> I’m sure there are some areas where it’s useful, but it sounds like there’s a 
> lot where it isn’t.  Am I missing something”
> “[doing everything that] we need” is a pretty high bar, wouldn’t you agree? 
> For me, I’ve been using ObjectTools + constructors since the late 90’s, 
> biding my time for 4D to adopt objects/object notation/OOP. At this point, 
> I’ll take what I can get.
> 
> While I was quite not-happy with this particular limitation (I have forms 
> with hundreds of fields that use Object name that are used with Object get 
> pointer), I think the last paragraph of Miyako’s posting, above, is sound 
> advice - "I would focus my use of object notation to areas where classic code 
> could not go, not spaces already occupied by classic code."
> 
> --
> Douglas von Roeder
> 949-910-4084
> 
> 
> On Thu, Apr 30, 2020 at 3:03 PM Randy Kaempen via 4D_Tech < 
> 4d_tech@lists.4d.com> wrote:
> 
>> 
>>> 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 

Re: Object notation replacement for use of Self in a script — v18

[Peter Hay via 4D_Tech]

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 the Expression, then we could use Evaluate Formula to
Get/Set the Value.

There's currently no 4D Command to do this directly, but you can do it
using "Form Convert to dynamic".  It's an "expensive" command, but it does
the job until 4D give us a better way.


  //Method: Object Get Expression
  //Returns the Expression / Data Source of the Form Object named $1

C_TEXT($0)  //Object Expression / Data Source
C_TEXT($1)  //Optional, Object Name.  Default = the Current Object

C_LONGINT($l_Page)
C_OBJECT($o_Form)
C_TEXT($t_ObjectName)

Case of
: (Count parameters<1)
$t_ObjectName:=OBJECT Get name(Object current)
: ($1="")
$t_ObjectName:=OBJECT Get name(Object current)
Else
$t_ObjectName:=$1
End case

If ($t_ObjectName#"")
If (Current form table=Null)
$o_Form:=FORM Convert to dynamic(Current form name)
Else
$o_Form:=FORM Convert to dynamic(Current form table->;Current form name)
End if

If ($o_Form.pages#Null)
$0:=String($o_Form.pages[FORM Get current
page].objects[$t_ObjectName].dataSource)  //The Object is most likely to be
on the Current Page, so start looking there

If ($0="")  //Not on the Current Page, so look at all Pages
For ($l_Page;0;$o_Form.pages.length-1)
If ($l_Page#FORM Get current page)  //We've already checked the Current
Page, so no need to check it again
$0:=String($o_Form.pages[$l_Page].objects[$t_ObjectName].dataSource)

If ($0#"")
$l_Page:=999
End if
End if
End for
End if
End if
End if



Ideally I'd like to have Object Get Value and Object Set Value commands.

I present to you;

---
  //Method: Object Set Vaule

C_TEXT($1)  //Object Name
C_VARIANT($2)  //Value

C_TEXT($t_DataSource;$t_ObjectName)

C_VARIANT(__ObjectValue)  //Required for EXECUTE FORMULA

If ($1="")
$t_ObjectName:=OBJECT Get name(Object current)
Else
$t_ObjectName:=$1
End if

If ($t_ObjectName#"")
$t_DataSource:=Object Get Expression ($t_ObjectName)

If ($t_DataSource#"")
__ObjectValue:=$2  //Params and Locals can't be used in EXECUTE FORMULA
EXECUTE FORMULA($t_DataSource+":=__ObjectValue")
End if
End if



---
  //Method: Object Get Vaule

C_VARIANT($0)  //Object Value
C_TEXT($1)  //Object Name.  Default = the Current Object

C_TEXT($t_DataSource;$t_ObjectName)

C_VARIANT(__ObjectValue)  //Required for EXECUTE FORMULA

Case of
: (Count parameters<1)
$t_ObjectName:=OBJECT Get name(Object current)
: ($1="")
$t_ObjectName:=OBJECT Get name(Object current)
Else
$t_ObjectName:=$1
End case

If ($t_ObjectName#"")
$t_DataSource:=Object Get Expression ($t_ObjectName)

If ($t_DataSource#"")
EXECUTE FORMULA("__ObjectValue:="+$t_DataSource)
$0:=__ObjectValue  //Params and Locals can't be used in EXECUTE FORMULA
End if
End if


It's very round about code, but not particularly complicated, which makes
me wonder why 4D don't just give us some commands to do it.

Anyway, I hope these work for you.  They work for me.

-- 
Pete Hay
Managing Director
Foreground Software Limited
New Zealand
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Object notation replacement for use of Self in a script — v18

[lists via 4D_Tech]

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

-Original Message-
From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Douglas von Roeder 
via 4D_Tech
Sent: Thursday, April 30, 2020 5:51 PM
To: 4D iNug Technical <4d_tech@lists.4d.com>
Cc: Douglas von Roeder 
Subject: Re: Object notation replacement for use of Self in a script — v18

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 everyone is all excited about object notation, but it’s not mandatory.  
Why should we even consider using it if doesn’t do what we need?  I’m sure 
there are some areas where it’s useful, but it sounds like there’s a lot where 
it isn’t.  Am I missing something”
“[doing everything that] we need” is a pretty high bar, wouldn’t you agree? For 
me, I’ve been using ObjectTools + constructors since the late 90’s, biding my 
time for 4D to adopt objects/object notation/OOP. At this point, I’ll take what 
I can get.

While I was quite not-happy with this particular limitation (I have forms with 
hundreds of fields that use Object name that are used with Object get pointer), 
I think the last paragraph of Miyako’s posting, above, is sound advice - "I 
would focus my use of object notation to areas where classic code could not go, 
not spaces already occupied by classic code."

--
Douglas von Roeder
949-910-4084


On Thu, Apr 30, 2020 at 3:03 PM Randy Kaempen via 4D_Tech < 
4d_tech@lists.4d.com> wrote:

>
> > 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 entry objects when loading the form, and copying the values 
> back when we want to save any user changes.
> >
> > OR
> >
> > We can use the Form.XXX notation to gain the advantage of that new 
> > nifty
> option, but lose the generic coding ability.
> >
> > I'd say it's a choice, but the lack of the ability to address an 
> > object
> from within generically definitely seems to be a glaring omission...
>
> If there is such an issue trying to get object values to work right, 
> what’s the reason to use them at all?
>
> I know everyone is all excited about object notation, but it’s not 
> mandatory.  Why should we even consider using it if doesn’t do what we 
> need?  I’m sure there are some areas where it’s useful, but it sounds 
> like there’s a lot where it isn’t.  Am I missing something?
>
>
> Randy Kaempen
> Intellex Corporation
>
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[Douglas von Roeder via 4D_Tech]

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 everyone is all excited about object notation, but it’s not
mandatory.  Why should we even consider using it if doesn’t do what we
need?  I’m sure there are some areas where it’s useful, but it sounds like
there’s a lot where it isn’t.  Am I missing something”
“[doing everything that] we need” is a pretty high bar, wouldn’t you agree? For
me, I’ve been using ObjectTools + constructors since the late 90’s, biding
my time for 4D to adopt objects/object notation/OOP. At this point, I’ll
take what I can get.

While I was quite not-happy with this particular limitation (I have forms
with hundreds of fields that use Object name that are used with Object get
pointer), I think the last paragraph of Miyako’s posting, above, is sound
advice - "I would focus my use of object notation to areas where classic
code could not go, not spaces already occupied by classic code."

--
Douglas von Roeder
949-910-4084


On Thu, Apr 30, 2020 at 3:03 PM Randy Kaempen via 4D_Tech <
4d_tech@lists.4d.com> wrote:

>
> > 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 entry
> objects when loading the form, and copying the values back when we want to
> save any user changes.
> >
> > OR
> >
> > We can use the Form.XXX notation to gain the advantage of that new nifty
> option, but lose the generic coding ability.
> >
> > I'd say it's a choice, but the lack of the ability to address an object
> from within generically definitely seems to be a glaring omission...
>
> If there is such an issue trying to get object values to work right,
> what’s the reason to use them at all?
>
> I know everyone is all excited about object notation, but it’s not
> mandatory.  Why should we even consider using it if doesn’t do what we
> need?  I’m sure there are some areas where it’s useful, but it sounds like
> there’s a lot where it isn’t.  Am I missing something?
>
>
> Randy Kaempen
> Intellex Corporation
>
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: 4D Summit Videos

[Keisuke Miyako via 4D_Tech]

Hello,

the team has just made the demo DB (v18) available for download.

https://events.4d.com/summit2020/session/document-production/

Regards,

> On Apr 23, 2020, at 22:37, Eric Naujock via 4D_Tech <4d_tech@lists.4D.com> 
> wrote:
> Keisuke Miyako's presentation on Document Production managed to get me 
> excited.
> But I cannot find in the V18 or v18R2 documentation more about what he 
> discussed. 

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[Randy Kaempen via 4D_Tech]

> 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 entry objects 
> when loading the form, and copying the values back when we want to save any 
> user changes.
> 
> OR
> 
> We can use the Form.XXX notation to gain the advantage of that new nifty 
> option, but lose the generic coding ability.
> 
> I'd say it's a choice, but the lack of the ability to address an object from 
> within generically definitely seems to be a glaring omission...

If there is such an issue trying to get object values to work right, what’s the 
reason to use them at all?

I know everyone is all excited about object notation, but it’s not mandatory.  
Why should we even consider using it if doesn’t do what we need?  I’m sure 
there are some areas where it’s useful, but it sounds like there’s a lot where 
it isn’t.  Am I missing something?


Randy Kaempen
Intellex Corporation

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Object notation replacement for use of Self in a script — v18

[lists via 4D_Tech]

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 any user changes.

OR

We can use the Form.XXX notation to gain the advantage of that new nifty 
option, but lose the generic coding ability.

I'd say it's a choice, but the lack of the ability to address an object from 
within generically definitely seems to be a glaring omission...

Lahav

-Original Message-
From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via 
4D_Tech
Sent: Thursday, April 30, 2020 3:20 PM
To: 4D iNug Technical <4d_tech@lists.4d.com>
Cc: Keisuke Miyako 
Subject: Re: Object notation replacement for use of Self in a script — v18

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 object name is only interesting to me for visibility, enable/disable, etc.
I would have some kind of naming convention to take advantage of the @ 
wildcard, but that's all.

as for the data source, if I wanted to implement some kind of rule on it, I 
would do so without the form object.

in other words, I would only use object notation on form objects that do not 
need to use form events.
in my opinion, any form object that do use a form event should not have object 
notation as their data source, since the event is attached to the form object 
and not the data source object.
there would be room for programming error if the same data source could be 
manipulated outside the form event.

same with the current item/position/selection property of the collection type 
listbox.
the properties only make sense in the context of zero-coding.
if I want to manage the binding by code, I would keep these properties empty.

classes are coming in 18 R3, but you can already create pseudo-classes by 
writing custom constructors that return an object with prefab properties and 
methods.

until the use of "This" is extended to text inputs and other form objects, I 
would not expose object notation (which implies that the target is an object) 
in any of my form objects, other than for form objects that exist purely for 
display purposes.

I would focus my use of object notation to areas where classic code could not 
go, not spaces already occupied by classic code. 

> On May 1, 2020, at 4:54, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> (Object get name).prettyFormatHow would that be achieved?

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Object notation replacement for use of Self in a script — v18

[lists via 4D_Tech]

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 question remains, what is the right "New World" approach to achieve 
functionality that seems to have no work around.

Lahav

-Original Message-
From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of kculotta via 4D_Tech
Sent: Thursday, April 30, 2020 3:03 PM
To: 4D iNug Technical <4d_tech@lists.4d.com>
Cc: kculotta 
Subject: Re: Object notation replacement for use of Self in a script — v18

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.
> 
> 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, 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 iNug Technical <4d_tech@lists.4d.com>
>> Cc: kculotta 
>> Subject: Re: Object notation replacement for use of Self in a script 
>> — v18
>> 
>> 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 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 
>>> name(object current)])
>>> 
>>> But that is not quite what we need to be truly generic
>>> 
>>> 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:29 PM
>>> To: 4D iNug Technical <4d_tech@lists.4d.com>
>>> Cc: kculotta 
>>> Subject: Re: Object notation replacement for use of Self in a script 
>>> —
>>> v18
>>> 
>>> 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 named;$1)-> $s:=$ent[$1]
>>> ALERT($s)  // the value entered into the text area
>>> 
>>> Keith - CDI
>>> 
 On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech 
 <4d_tech@lists.4d.com> wrote:
 
 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 describe is that I need a way to generically ‘get’ and ’set’ 
 the value of an object (meaning an entry variable on the form).
 
 1) A variable is placed on the form. It’s “variable or expression” is:
 Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
 “enLSDFromRigDispatch”
 
 I have given it this name because it gives me a simple methodology 
 to SHOW/HIDE a whole group of objects on the screen with OBJECT SET 
 VISIBLE(*; “enLSD@“;…)
 
 Now I wish to use a standard project method to ‘pretty-format’ this 
 variable.
 With ‘4D Classic’ this is easily achieved by making a project method that 
 takes a POINTER in $1. 
 The OBJECT SCRIPT would be something simple, like:   
 PRETTY_FORMAT(Self)
 [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of 
 the variable and do any formatting options needed]
 
 With ‘4D DOT NOTATION’ …
 —  How do I create a simple OBJECT SCRIPT that would do something 
 similar to that in 4D Classic?  — I don’t feel that I should have to 
 resort to using the ‘variable or expression’ name in every single script; 
 because what happens if I change that variable for some reason and it 
 totally screws up the object script? And it also makes it very complicated.
 THE OBJECT METHOD should be something as simple as:
 PRETTY_FORMAT ( Object Get Name )—— instead of Self

Re: 4D v18 — Need methodology to

[Chris Belanger via 4D_Tech]

By the way, I follows Lahav’s direction (and a few others of you who tried to 
say the same thing but it went clear over my head). I am very happy with the 
solution.
I just needed a project method flagged with ‘execute on server’ in its 
properties [or whatever you call it].
Then it was a very simple matter to ‘lookup’ the file on disk on the server and 
retrieve its contents in a blob.
In short:
[Lib] contains .SubFolder,  .FileName,  .FileExt
Storage.folder_docLibrary.path is the ‘MAIN PATH’ to the library of documents
Then I just needed to write   SVR_Lib_GetDocument ( [Lib]UUID ) which was 
executed on 4D Server.

Because of all your kind tips, I like to just ‘give back’ by providing at least 
some explanation of how I solved my problem.

—

  // SVR_Lib_GetDocument ( [Lib]UUID ) --> BLOB of the document stored. Is an 
empty BLOB if nothing could be retrieved
  // NOTE: THIS IS EXECUTED ON 4D SERVER 
C_TEXT($1)  // the [Lib]UUID to look up
C_BLOB($0)  // the RESULT we return to the 4D REMOTE
C_OBJECT($en_Lib)  // the LIB record
C_OBJECT($obj_File)  // the FILE( ) object

$en_Lib:=ds.Lib.get($1)  // retrieve the $Lib record. Note that if it does not 
exist, then the $en_Lib will be NULL
If ($en_Lib#Null)  // if we have a true $en_Lib entity... (the .get() may not 
actually retrieve one, possibly)

$obj_File:=File(Storage.folder_docLibrary.path+$en_Lib.SubFolder+$en_Lib.FileName+$en_Lib.FileExt)
If ($obj_File.isFile)
If ($obj_File.exists)  // if it actually exists...
$0:=$obj_File.getContent()
End if 
End if 
End if 
—

—— Chris



> On Apr 24, 2020, at 6:06 PM, Chris Belanger  wrote:
> 
> Wow! I never knew that. Thanks for explaining, Lahav. — Chris
> 
>> On Apr 24, 2020, at 4:52 PM, lists via 4D_Tech <4d_tech@lists.4d.com> wrote:
>> 
>> Chris,
>> 
>> Just create a regular method, mark it as "Execute on Server" in the method 
>> properties, then call it just like any other method.  You can return 
>> anything you want in $0
>> 
>> $myData:=ThisMethodRunOnServer(whatever)
>> 
>> Just make sure to check that little box in the ThisMethodRunOnServer Method 
>> properties and you are all done...
>> 
>> Lahav
>> 
>> -Original Message-
>> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Chris Belanger via 
>> 4D_Tech
>> Sent: Friday, April 24, 2020 4:44 PM
>> To: 4D iNUG Technical <4d_tech@lists.4d.com>
>> Cc: Chris Belanger 
>> Subject: Re: 4D v18 — Need methodology to 
>> 
>> Hi Olivier,
>> I am looking for SIMPLE, alright. 
>> I have looked at ‘execute on server’ but I do not see how it sends anything 
>> to the client other than the process number (in $0).
>> What have I missing about it?
>> I used it in the past (when I made a ‘communicator’ subsystem in classic 4D) 
>> but it involved ‘variable to variable’, pausing/resuming processes and the 
>> like, and involved quite a bit of intricate programming.
>> 
>> — Chris
>> 
>> 
>>> On Apr 24, 2020, at 5:27 AM, Olivier Flury via 4D_Tech 
>>> <4d_tech@lists.4d.com> wrote:
>>> 
>>> Maybe too simple for what you need to do, but have a look at the "execute 
>>> on server" property for project methods.
>>> 
>>> Create a method that is executed on server. It gets as $1 the id of the 
>>> document you want to display on the client side. The method does everything 
>>> to fetch the document from the directory on the server etc. and sends it to 
>>> the client in $0.
>>> 
>>> Keep in mind that this method (executed on server) behaves similar to a 
>>> trigger method: you are read/write for all tables and you should have your 
>>> own On Err Call method.
>>> 
>>> Best,
>>> 
>>> Olivier
>>> 
>>> || https://flury-software.ch/
>>> 
>>> -Ursprüngliche Nachricht-
>>> Von: 4D_Tech <4d_tech-boun...@lists.4d.com> Im Auftrag von Chris Belanger 
>>> via 4D_Tech
>>> Gesendet: Freitag, 24. April 2020 10:57
>>> An: 4D iNUG Technical <4d_tech@lists.4D.com>
>>> Cc: Chris Belanger 
>>> Betreff: 4D v18 — Need methodology to 
>>> 
>>> I have a methodology of allowing clients to transfer documents that are 
>>> thereafter stored by 4D Server in a ‘LIBRARY’ of system documents it 
>>> maintains automatically. [these are not stored in the DB, but in a managed 
>>> folder on disk.]
>>> 
>>> I do this by:
>>> • Loading a system document into a BLOB, then using BASE64 ENCODE to store 
>>> it in a TEXT field;—— thanks Peter Bozek for the tip on BASE64 ENCODE / 
>>> DECODE!
>>> • the TRIGGER method (running on 4D server) unpacks it and creates / 
>>> updates the files in its ‘Library’ directory on disk.
>>> 
>>> Now I need to be able to retrieve the contents of these files for 4D 
>>> [Client].
>>> I can display the files in a Web Area —> Thanks to Keith for the tip.
>>> 
>>> ** But I am looking for a simple way to get 4D Server to ’send’ the data to 
>>> the CLIENT (4D) upon request.
>>> 
>>> In the past [since v12), I made elaborate ‘communicator’ stored routines 

Re: Object notation replacement for use of Self in a script — v18

[Keisuke Miyako via 4D_Tech]

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 object name is only interesting to me for visibility, enable/disable, etc.
I would have some kind of naming convention to take advantage of the @ 
wildcard, but that's all.

as for the data source, if I wanted to implement some kind of rule on it,
I would do so without the form object.

in other words, I would only use object notation on form objects that do not 
need to use form events.
in my opinion, any form object that do use a form event should not have object 
notation as their data source,
since the event is attached to the form object and not the data source object.
there would be room for programming error if the same data source could be 
manipulated outside the form event.

same with the current item/position/selection property of the collection type 
listbox.
the properties only make sense in the context of zero-coding.
if I want to manage the binding by code, I would keep these properties empty.

classes are coming in 18 R3, but you can already create pseudo-classes by 
writing custom constructors that return an object with prefab properties and 
methods.

until the use of "This" is extended to text inputs and other form objects,
I would not expose object notation (which implies that the target is an object) 
in any of my form objects,
other than for form objects that exist purely for display purposes.

I would focus my use of object notation to areas where classic code could not 
go,
not spaces already occupied by classic code. 

> On May 1, 2020, at 4:54, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> (Object get name).prettyFormatHow would that be achieved?

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Users and group not converting when moving from v17r5 to v18

[Eric Naujock via 4D_Tech]

Yes I know they were changed I am walking my way though the changes now as I am 
working on preparing to move to the new 4D V18 project mode. In a way I like 
the movement of the User sand groups to the .json file. But breaking the 
conversion of users and groups for a large corporation and requiring the 
permissions be regenerated manually may be a major issue for a large 
organization.

> On Apr 30, 2020, at 4:43 PM, Guy Algot  wrote:
> 
> Eric, U were changed with v18 project mode. Check out the blog, I believe 
> there was a posting there about it.
> 
>> On Apr 30, 2020, at 2:29 PM, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com 
>> > wrote:
>> 
>> I have found that if you take a 4D v17r5 program and convert it to v18. Then 
>> change the database to a project database it will lose the memberships in 
>> the users and groups. When exported you will see all your groups and users. 
>> But the memberships between the two will disappear. With the exception being 
>> “Designer” and “Administrator”.
>> 
>> Even worse. If you took a User to blob file saved in 4D v17r5 and import it 
>> into v18 it will corrupt the minimal users and groups file created when the 
>> database was converted. Effectively all the groups will disappear and 
>> corrupt groups groups will come into existance.
>> 
>> A curiosity is that the designer and administrator will keep their 
>> memberships, but all the other users will lose the relationships. I have 
>> noticed the the new directory.json no longer has user numbers. I suspect 
>> this may be part of the problem. This is certainly causing issues with my 
>> linking users to their [Employee] table records. The user number used to be 
>> a constant and I would use it to tie a user to an employee record with a 
>> simple Longint.
>> 
>> Can anybody verify this is true or not.  Or is there something really simple 
>> that I am missing. The good thing is that my users and groups are pretty 
>> small so I can manually recreate the directory.json file. Then make a backup 
>> of the file in my v18 project. 
>> 
>> I am using the method of saving the directory.json file in the dat folder to 
>> keep my users and groups constant between versions of the database. 
>> 
>> I remember there was a discussion about users and groups in the past and 
>> issues with import-export of the data to a blob.
>> **
>> 4D Internet Users Group (4D iNUG)
>> Archive:  http://lists.4d.com/archives.html 
>> 
>> Options: https://lists.4d.com/mailman/options/4d_tech 
>> 
>> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com 
>> 
>> **
> 
> 
> Later,
> Guy
> 
> --
> Guy Algot, Solutions Specialist
> Edmonton, Alberta
> (780) 974-8538
> 
> hardware, installation, training, support, programming, internet
> specializing in 4th Dimension
> =-= =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> "Microsoft is a cross between the Borg and the Ferengi. Unfortunately,
> they use Borg to do their marketing and Ferengi to do their programming."
> -- Simon Slavin
> 
> 
> 

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[Chris Belanger via 4D_Tech]

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 name ended up having 
to be:
Form.en_This.Company.Name   — which is quite a valid ‘variable or expression’.

The simple solution is for there to be a way to get at the value of the form 
object, as per:
>> PRETTY_FORMAT ( Object Get Name )—— instead of Self

And for PRETTY_FORMAT( ) to thereafter be able to manipulate the value of that 
Object. [I hate the ambiguity of ‘Object’ in 4D; too many conflicting meanings].

- Chris



> On Apr 30, 2020, at 2: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 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 name(object 
> current)])
> 
> But that is not quite what we need to be truly generic
> 
> 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:29 PM
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Cc: kculotta 
> Subject: Re: Object notation replacement for use of Self in a script — v18
> 
> 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 named;$1)-> $s:=$ent[$1]
> ALERT($s)  // the value entered into the text area
> 
> Keith - CDI
> 
>> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> 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 describe is that I need a way to generically ‘get’ and ’set’ 
>> the value of an object (meaning an entry variable on the form).
>> 
>> 1) A variable is placed on the form. It’s “variable or expression” is:
>> Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
>> “enLSDFromRigDispatch”
>> 
>> I have given it this name because it gives me a simple methodology to 
>> SHOW/HIDE a whole group of objects on the screen with OBJECT SET 
>> VISIBLE(*; “enLSD@“;…)
>> 
>> Now I wish to use a standard project method to ‘pretty-format’ this variable.
>> With ‘4D Classic’ this is easily achieved by making a project method that 
>> takes a POINTER in $1. 
>> The OBJECT SCRIPT would be something simple, like:   
>> PRETTY_FORMAT(Self)
>> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of 
>> the variable and do any formatting options needed]
>> 
>> With ‘4D DOT NOTATION’ …
>> —  How do I create a simple OBJECT SCRIPT that would do something 
>> similar to that in 4D Classic?  — I don’t feel that I should have to resort 
>> to using the ‘variable or expression’ name in every single script; because 
>> what happens if I change that variable for some reason and it totally screws 
>> up the object script? And it also makes it very complicated.
>> THE OBJECT METHOD should be something as simple as:
>> PRETTY_FORMAT ( Object Get Name )—— instead of Self
>> 
>> The PRETTY_FORMAT( ) should be able to get at and set the value of the form 
>> object from that name.
>> 
>> Alternatively, if one wants to not bother having scripts for every input 
>> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD:
>> Case of
>> :( Form event code = on load ) 
>>  Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 
>> ) …  // objects that need to be ‘Pretty Formatted'
>> 
>> : ( Form event code = on losing focus )
>>  $curObjectName:= Form Event.objectName
>>  … see if is in the list of .col_toPrettyFormat …
>>  PRETTY_FORMAT( $curObjectName )
>> 
>> …
>> 
>> So how would one implement something like:
>>  PRETTY FORMAT ( Object Get Name ) in a script; or   PRETTY FORMAT ( 
>> Form Event.objectName )
>> ???
>> 
>> Thanks,
>> Chris
>> 
>> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create 
>> classes. That is very intriguing and a necessary development in 4D, as is 
>> C_VARIANT( ).
>> If one wanted to be able to have the script be:
>> 
>> (Object get name).prettyFormatHow would that be achieved?
>> 
>> Even if in the script one could use “This”, but it is null.
>> I think that ’This’ should be perfectly valid 

Re: Object notation replacement for use of Self in a script — v18

[kculotta via 4D_Tech]

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.
> 
> 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, 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 iNug Technical <4d_tech@lists.4d.com>
>> Cc: kculotta 
>> Subject: Re: Object notation replacement for use of Self in a script — v18
>> 
>> 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 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 
>>> name(object current)])
>>> 
>>> But that is not quite what we need to be truly generic
>>> 
>>> 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:29 PM
>>> To: 4D iNug Technical <4d_tech@lists.4d.com>
>>> Cc: kculotta 
>>> Subject: Re: Object notation replacement for use of Self in a script — 
>>> v18
>>> 
>>> 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 named;$1)-> $s:=$ent[$1]
>>> ALERT($s)  // the value entered into the text area
>>> 
>>> Keith - CDI
>>> 
 On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech 
 <4d_tech@lists.4d.com> wrote:
 
 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 describe is that I need a way to generically ‘get’ and ’set’ 
 the value of an object (meaning an entry variable on the form).
 
 1) A variable is placed on the form. It’s “variable or expression” is:
 Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
 “enLSDFromRigDispatch”
 
 I have given it this name because it gives me a simple methodology to 
 SHOW/HIDE a whole group of objects on the screen with OBJECT SET 
 VISIBLE(*; “enLSD@“;…)
 
 Now I wish to use a standard project method to ‘pretty-format’ this 
 variable.
 With ‘4D Classic’ this is easily achieved by making a project method that 
 takes a POINTER in $1. 
 The OBJECT SCRIPT would be something simple, like:   
 PRETTY_FORMAT(Self)
 [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of 
 the variable and do any formatting options needed]
 
 With ‘4D DOT NOTATION’ …
 —  How do I create a simple OBJECT SCRIPT that would do something 
 similar to that in 4D Classic?  — I don’t feel that I should have to 
 resort to using the ‘variable or expression’ name in every single script; 
 because what happens if I change that variable for some reason and it 
 totally screws up the object script? And it also makes it very complicated.
 THE OBJECT METHOD should be something as simple as:
 PRETTY_FORMAT ( Object Get Name )—— instead of Self
 
 The PRETTY_FORMAT( ) should be able to get at and set the value of the 
 form object from that name.
 
 Alternatively, if one wants to not bother having scripts for every input 
 variable that needs PRETTY_FORMAT, they could just do it in the FORM 
 METHOD:
 Case of
 :( Form event code = on load ) 
Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 
 ) …  // objects that need to be ‘Pretty Formatted'
 
 : ( Form event code = on losing focus )
$curObjectName:= Form Event.objectName
… see if is in the list of .col_toPrettyFormat …
PRETTY_FORMAT( $curObjectName )
 
 …
 
 So how would 

Re: Object notation replacement for use of Self in a script — v18

[kculotta via 4D_Tech]

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, 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 iNug Technical <4d_tech@lists.4d.com>
> Cc: kculotta 
> Subject: Re: Object notation replacement for use of Self in a script — v18
> 
> 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 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 
>> name(object current)])
>> 
>> But that is not quite what we need to be truly generic
>> 
>> 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:29 PM
>> To: 4D iNug Technical <4d_tech@lists.4d.com>
>> Cc: kculotta 
>> Subject: Re: Object notation replacement for use of Self in a script — 
>> v18
>> 
>> 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 named;$1)-> $s:=$ent[$1]
>> ALERT($s)  // the value entered into the text area
>> 
>> Keith - CDI
>> 
>>> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech 
>>> <4d_tech@lists.4d.com> wrote:
>>> 
>>> 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 describe is that I need a way to generically ‘get’ and ’set’ 
>>> the value of an object (meaning an entry variable on the form).
>>> 
>>> 1) A variable is placed on the form. It’s “variable or expression” is:
>>> Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
>>> “enLSDFromRigDispatch”
>>> 
>>> I have given it this name because it gives me a simple methodology to 
>>> SHOW/HIDE a whole group of objects on the screen with OBJECT SET 
>>> VISIBLE(*; “enLSD@“;…)
>>> 
>>> Now I wish to use a standard project method to ‘pretty-format’ this 
>>> variable.
>>> With ‘4D Classic’ this is easily achieved by making a project method that 
>>> takes a POINTER in $1. 
>>> The OBJECT SCRIPT would be something simple, like:   
>>> PRETTY_FORMAT(Self)
>>> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of 
>>> the variable and do any formatting options needed]
>>> 
>>> With ‘4D DOT NOTATION’ …
>>> —  How do I create a simple OBJECT SCRIPT that would do something 
>>> similar to that in 4D Classic?  — I don’t feel that I should have to resort 
>>> to using the ‘variable or expression’ name in every single script; because 
>>> what happens if I change that variable for some reason and it totally 
>>> screws up the object script? And it also makes it very complicated.
>>> THE OBJECT METHOD should be something as simple as:
>>> PRETTY_FORMAT ( Object Get Name )—— instead of Self
>>> 
>>> The PRETTY_FORMAT( ) should be able to get at and set the value of the form 
>>> object from that name.
>>> 
>>> Alternatively, if one wants to not bother having scripts for every input 
>>> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD:
>>> Case of
>>> :( Form event code = on load ) 
>>> Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 
>>> ) …  // objects that need to be ‘Pretty Formatted'
>>> 
>>> : ( Form event code = on losing focus )
>>> $curObjectName:= Form Event.objectName
>>> … see if is in the list of .col_toPrettyFormat …
>>> PRETTY_FORMAT( $curObjectName )
>>> 
>>> …
>>> 
>>> So how would one implement something like:
>>> PRETTY FORMAT ( Object Get Name ) in a script; or   PRETTY FORMAT ( 
>>> Form Event.objectName )
>>> ???
>>> 
>>> Thanks,
>>> Chris
>>> 
>>> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create 
>>> classes. That is very intriguing and a necessary 

RE: Object notation replacement for use of Self in a script — v18

[lists via 4D_Tech]

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 iNug Technical <4d_tech@lists.4d.com>
Cc: kculotta 
Subject: Re: Object notation replacement for use of Self in a script — v18

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 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 
> name(object current)])
> 
> But that is not quite what we need to be truly generic
> 
> 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:29 PM
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Cc: kculotta 
> Subject: Re: Object notation replacement for use of Self in a script — 
> v18
> 
> 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 named;$1)-> $s:=$ent[$1]
> ALERT($s)  // the value entered into the text area
> 
> Keith - CDI
> 
>> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> 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 describe is that I need a way to generically ‘get’ and ’set’ 
>> the value of an object (meaning an entry variable on the form).
>> 
>> 1) A variable is placed on the form. It’s “variable or expression” is:
>> Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
>> “enLSDFromRigDispatch”
>> 
>> I have given it this name because it gives me a simple methodology to 
>> SHOW/HIDE a whole group of objects on the screen with OBJECT SET 
>> VISIBLE(*; “enLSD@“;…)
>> 
>> Now I wish to use a standard project method to ‘pretty-format’ this variable.
>> With ‘4D Classic’ this is easily achieved by making a project method that 
>> takes a POINTER in $1. 
>> The OBJECT SCRIPT would be something simple, like:   
>> PRETTY_FORMAT(Self)
>> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of 
>> the variable and do any formatting options needed]
>> 
>> With ‘4D DOT NOTATION’ …
>> —  How do I create a simple OBJECT SCRIPT that would do something 
>> similar to that in 4D Classic?  — I don’t feel that I should have to resort 
>> to using the ‘variable or expression’ name in every single script; because 
>> what happens if I change that variable for some reason and it totally screws 
>> up the object script? And it also makes it very complicated.
>> THE OBJECT METHOD should be something as simple as:
>> PRETTY_FORMAT ( Object Get Name )—— instead of Self
>> 
>> The PRETTY_FORMAT( ) should be able to get at and set the value of the form 
>> object from that name.
>> 
>> Alternatively, if one wants to not bother having scripts for every input 
>> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD:
>> Case of
>> :( Form event code = on load ) 
>>  Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 
>> ) …  // objects that need to be ‘Pretty Formatted'
>> 
>> : ( Form event code = on losing focus )
>>  $curObjectName:= Form Event.objectName
>>  … see if is in the list of .col_toPrettyFormat …
>>  PRETTY_FORMAT( $curObjectName )
>> 
>> …
>> 
>> So how would one implement something like:
>>  PRETTY FORMAT ( Object Get Name ) in a script; or   PRETTY FORMAT ( 
>> Form Event.objectName )
>> ???
>> 
>> Thanks,
>> Chris
>> 
>> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create 
>> classes. That is very intriguing and a necessary development in 4D, as is 
>> C_VARIANT( ).
>> If one wanted to be able to have the script be:
>> 
>> (Object get name).prettyFormatHow would that be achieved?
>> 
>> Even if in the script one could use “This”, but it is null.
>> I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in 
>> a TRIGGER (referring to the record/entity being operated on), etc. But it is 
>> not, and I have trouble understanding 

Re: Object notation replacement for use of Self in a script — v18

[kculotta via 4D_Tech]

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 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 name(object 
> current)])
> 
> But that is not quite what we need to be truly generic
> 
> 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:29 PM
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Cc: kculotta 
> Subject: Re: Object notation replacement for use of Self in a script — v18
> 
> 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 named;$1)-> $s:=$ent[$1]
> ALERT($s)  // the value entered into the text area
> 
> Keith - CDI
> 
>> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> 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 describe is that I need a way to generically ‘get’ and ’set’ 
>> the value of an object (meaning an entry variable on the form).
>> 
>> 1) A variable is placed on the form. It’s “variable or expression” is:
>> Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
>> “enLSDFromRigDispatch”
>> 
>> I have given it this name because it gives me a simple methodology to 
>> SHOW/HIDE a whole group of objects on the screen with OBJECT SET 
>> VISIBLE(*; “enLSD@“;…)
>> 
>> Now I wish to use a standard project method to ‘pretty-format’ this variable.
>> With ‘4D Classic’ this is easily achieved by making a project method that 
>> takes a POINTER in $1. 
>> The OBJECT SCRIPT would be something simple, like:   
>> PRETTY_FORMAT(Self)
>> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of 
>> the variable and do any formatting options needed]
>> 
>> With ‘4D DOT NOTATION’ …
>> —  How do I create a simple OBJECT SCRIPT that would do something 
>> similar to that in 4D Classic?  — I don’t feel that I should have to resort 
>> to using the ‘variable or expression’ name in every single script; because 
>> what happens if I change that variable for some reason and it totally screws 
>> up the object script? And it also makes it very complicated.
>> THE OBJECT METHOD should be something as simple as:
>> PRETTY_FORMAT ( Object Get Name )—— instead of Self
>> 
>> The PRETTY_FORMAT( ) should be able to get at and set the value of the form 
>> object from that name.
>> 
>> Alternatively, if one wants to not bother having scripts for every input 
>> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD:
>> Case of
>> :( Form event code = on load ) 
>>  Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 
>> ) …  // objects that need to be ‘Pretty Formatted'
>> 
>> : ( Form event code = on losing focus )
>>  $curObjectName:= Form Event.objectName
>>  … see if is in the list of .col_toPrettyFormat …
>>  PRETTY_FORMAT( $curObjectName )
>> 
>> …
>> 
>> So how would one implement something like:
>>  PRETTY FORMAT ( Object Get Name ) in a script; or   PRETTY FORMAT ( 
>> Form Event.objectName )
>> ???
>> 
>> Thanks,
>> Chris
>> 
>> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create 
>> classes. That is very intriguing and a necessary development in 4D, as is 
>> C_VARIANT( ).
>> If one wanted to be able to have the script be:
>> 
>> (Object get name).prettyFormatHow would that be achieved?
>> 
>> Even if in the script one could use “This”, but it is null.
>> I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in 
>> a TRIGGER (referring to the record/entity being operated on), etc. But it is 
>> not, and I have trouble understanding why not.
>> 
>> 
>> 
>> 
>>> On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech 
>>> <4d_tech@lists.4d.com> wrote:
>>> 
>>> 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.
>>> 

RE: Object notation replacement for use of Self in a script — v18

[lists via 4D_Tech]

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 name(object 
current)])

But that is not quite what we need to be truly generic

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:29 PM
To: 4D iNug Technical <4d_tech@lists.4d.com>
Cc: kculotta 
Subject: Re: Object notation replacement for use of Self in a script — v18

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 named;$1)-> $s:=$ent[$1]
ALERT($s)  // the value entered into the text area

Keith - CDI

> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> 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 describe is that I need a way to generically ‘get’ and ’set’ 
> the value of an object (meaning an entry variable on the form).
> 
> 1) A variable is placed on the form. It’s “variable or expression” is:
> Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
> “enLSDFromRigDispatch”
> 
> I have given it this name because it gives me a simple methodology to 
> SHOW/HIDE a whole group of objects on the screen with OBJECT SET 
> VISIBLE(*; “enLSD@“;…)
> 
> Now I wish to use a standard project method to ‘pretty-format’ this variable.
> With ‘4D Classic’ this is easily achieved by making a project method that 
> takes a POINTER in $1. 
> The OBJECT SCRIPT would be something simple, like:   
> PRETTY_FORMAT(Self)
> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of 
> the variable and do any formatting options needed]
> 
> With ‘4D DOT NOTATION’ …
> —  How do I create a simple OBJECT SCRIPT that would do something 
> similar to that in 4D Classic?  — I don’t feel that I should have to resort 
> to using the ‘variable or expression’ name in every single script; because 
> what happens if I change that variable for some reason and it totally screws 
> up the object script? And it also makes it very complicated.
> THE OBJECT METHOD should be something as simple as:
> PRETTY_FORMAT ( Object Get Name )—— instead of Self
> 
> The PRETTY_FORMAT( ) should be able to get at and set the value of the form 
> object from that name.
> 
> Alternatively, if one wants to not bother having scripts for every input 
> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD:
> Case of
> :( Form event code = on load ) 
>   Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 
> ) …  // objects that need to be ‘Pretty Formatted'
> 
> : ( Form event code = on losing focus )
>   $curObjectName:= Form Event.objectName
>   … see if is in the list of .col_toPrettyFormat …
>   PRETTY_FORMAT( $curObjectName )
> 
> …
> 
> So how would one implement something like:
>   PRETTY FORMAT ( Object Get Name ) in a script; or   PRETTY FORMAT ( 
> Form Event.objectName )
> ???
> 
> Thanks,
> Chris
> 
> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create 
> classes. That is very intriguing and a necessary development in 4D, as is 
> C_VARIANT( ).
> If one wanted to be able to have the script be:
> 
> (Object get name).prettyFormatHow would that be achieved?
> 
> Even if in the script one could use “This”, but it is null.
> I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in 
> a TRIGGER (referring to the record/entity being operated on), etc. But it is 
> not, and I have trouble understanding why not.
> 
> 
> 
> 
>> On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> 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 notation, but the way to write generic 
>> code is different.
>> 
>> if you want to make your code generic in object notation, I think you 
>> need to fully commit.
>> 
>> what I mean by that, is that you need to think of objects and classes, 
>> properties and methods.
>> 
>> basically, instead of
>> 
>> doIt(Self)
>> 
>> you would write
>> 
>> 

Re: Users and group not converting when moving from v17r5 to v18

[Guy Algot via 4D_Tech]

Eric, U were changed with v18 project mode. Check out the blog, I believe 
there was a posting there about it.

> On Apr 30, 2020, at 2:29 PM, Eric Naujock via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> I have found that if you take a 4D v17r5 program and convert it to v18. Then 
> change the database to a project database it will lose the memberships in the 
> users and groups. When exported you will see all your groups and users. But 
> the memberships between the two will disappear. With the exception being 
> “Designer” and “Administrator”.
> 
> Even worse. If you took a User to blob file saved in 4D v17r5 and import it 
> into v18 it will corrupt the minimal users and groups file created when the 
> database was converted. Effectively all the groups will disappear and corrupt 
> groups groups will come into existance.
> 
> A curiosity is that the designer and administrator will keep their 
> memberships, but all the other users will lose the relationships. I have 
> noticed the the new directory.json no longer has user numbers. I suspect this 
> may be part of the problem. This is certainly causing issues with my linking 
> users to their [Employee] table records. The user number used to be a 
> constant and I would use it to tie a user to an employee record with a simple 
> Longint.
> 
> Can anybody verify this is true or not.  Or is there something really simple 
> that I am missing. The good thing is that my users and groups are pretty 
> small so I can manually recreate the directory.json file. Then make a backup 
> of the file in my v18 project. 
> 
> I am using the method of saving the directory.json file in the dat folder to 
> keep my users and groups constant between versions of the database. 
> 
> I remember there was a discussion about users and groups in the past and 
> issues with import-export of the data to a blob.
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **


Later,
Guy

--
Guy Algot, Solutions Specialist
Edmonton, Alberta
(780) 974-8538

hardware, installation, training, support, programming, internet
specializing in 4th Dimension
=-= =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"Microsoft is a cross between the Borg and the Ferengi. Unfortunately,
they use Borg to do their marketing and Ferengi to do their programming."
-- Simon Slavin



**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[kculotta via 4D_Tech]

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
> 
>> 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 want to enforce a proper uppercase/lowercase on all three, so in the old 
>> days I created an object, set the method to "UpperLower(self)", duplicated 
>> it three times, change the object name and I'm done.  For simplicity sake, 
>> lets say that UpperLower simply do $1->:=Uppercase($1->).
>> 
>> How would you do the same while using object notation instead of a variable, 
>> dynamic or not?
>> 
>> Thanks,
>> 
>> Lahav
>> 
>> 
>> -Original Message-
>> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via 
>> 4D_Tech
>> Sent: Wednesday, April 29, 2020 10:14 AM
>> To: 4D iNug Technical <4d_tech@lists.4d.com>
>> Cc: Keisuke Miyako 
>> Subject: Re: Object notation replacement for use of Self in a script — v18
>> 
>> 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 notation,
>> but the way to write generic code is different.
>> 
>> if you want to make your code generic in object notation, I think you need 
>> to fully commit.
>> 
>> what I mean by that, is that you need to think of objects and classes, 
>> properties and methods.
>> 
>> basically, instead of
>> 
>> doIt(Self)
>> 
>> you would write
>> 
>> $obj.doIt()
>> 
>> where the doIt() formula works on "This".
>> 
>> in my opinion, to take full advantage of object notation, it is pretty much 
>> mandatory to use 
>> 
>> This
>> Signal
>> Formula
>> Form
>> 
>> extensively, as well as 
>> 
>> Storage
>> New shared object
>> New shared collection
>> 
>> strategically.
>> 
>> simply replacing interprocess/process variables with object notation, may 
>> semantically look like object based coding, but at that level you may be 
>> losing major advantages of classic code, while not gaining much from what 
>> the new way of coding has to offer.
>> 
>>> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech 
>>> <4d_tech@lists.4d.com> wrote:
>>> And v18r3 does not even have a solution to this in its documentation.
>> 
>> **
>> 4D Internet Users Group (4D iNUG)
>> Archive:  http://lists.4d.com/archives.html
>> Options: https://lists.4d.com/mailman/options/4d_tech
>> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
>> **
>> **
>> 4D Internet Users Group (4D iNUG)
>> Archive:  http://lists.4d.com/archives.html
>> Options: https://lists.4d.com/mailman/options/4d_tech
>> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
>> **
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Users and group not converting when moving from v17r5 to v18

[Eric Naujock via 4D_Tech]

I have found that if you take a 4D v17r5 program and convert it to v18. Then 
change the database to a project database it will lose the memberships in the 
users and groups. When exported you will see all your groups and users. But the 
memberships between the two will disappear. With the exception being “Designer” 
and “Administrator”.

Even worse. If you took a User to blob file saved in 4D v17r5 and import it 
into v18 it will corrupt the minimal users and groups file created when the 
database was converted. Effectively all the groups will disappear and corrupt 
groups groups will come into existance.

A curiosity is that the designer and administrator will keep their memberships, 
but all the other users will lose the relationships. I have noticed the the new 
directory.json no longer has user numbers. I suspect this may be part of the 
problem. This is certainly causing issues with my linking users to their 
[Employee] table records. The user number used to be a constant and I would use 
it to tie a user to an employee record with a simple Longint.

Can anybody verify this is true or not.  Or is there something really simple 
that I am missing. The good thing is that my users and groups are pretty small 
so I can manually recreate the directory.json file. Then make a backup of the 
file in my v18 project. 

I am using the method of saving the directory.json file in the dat folder to 
keep my users and groups constant between versions of the database. 

I remember there was a discussion about users and groups in the past and issues 
with import-export of the data to a blob.
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[kculotta via 4D_Tech]

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 named;$1)->
$s:=$ent[$1]
ALERT($s)  // the value entered into the text area

Keith - CDI

> On Apr 30, 2020, at 2:54 PM, Chris Belanger via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> 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 describe is that I need a way to generically ‘get’ and ’set’ 
> the value of an object (meaning an entry variable on the form).
> 
> 1) A variable is placed on the form. It’s “variable or expression” is:
> Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
> “enLSDFromRigDispatch”
> 
> I have given it this name because it gives me a simple methodology to 
> SHOW/HIDE a whole group of objects on the screen with OBJECT SET VISIBLE(*; 
> “enLSD@“;…)
> 
> Now I wish to use a standard project method to ‘pretty-format’ this variable.
> With ‘4D Classic’ this is easily achieved by making a project method that 
> takes a POINTER in $1. 
> The OBJECT SCRIPT would be something simple, like:   
> PRETTY_FORMAT(Self)
> [PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of the 
> variable and do any formatting options needed]
> 
> With ‘4D DOT NOTATION’ …
> —  How do I create a simple OBJECT SCRIPT that would do something similar to 
> that in 4D Classic?  —
> I don’t feel that I should have to resort to using the ‘variable or 
> expression’ name in every single script; because what happens if I change 
> that variable for some reason and it totally screws up the object script? And 
> it also makes it very complicated.
> THE OBJECT METHOD should be something as simple as:
> PRETTY_FORMAT ( Object Get Name )—— instead of Self
> 
> The PRETTY_FORMAT( ) should be able to get at and set the value of the form 
> object from that name.
> 
> Alternatively, if one wants to not bother having scripts for every input 
> variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD:
> Case of
> :( Form event code = on load ) 
>   Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 
> ) …  // objects that need to be ‘Pretty Formatted'
> 
> : ( Form event code = on losing focus )
>   $curObjectName:= Form Event.objectName
>   … see if is in the list of .col_toPrettyFormat …
>   PRETTY_FORMAT( $curObjectName )
> 
> …
> 
> So how would one implement something like:
>   PRETTY FORMAT ( Object Get Name ) in a script; or   PRETTY FORMAT ( 
> Form Event.objectName )
> ???
> 
> Thanks,
> Chris
> 
> p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create 
> classes. That is very intriguing and a necessary development in 4D, as is 
> C_VARIANT( ).
> If one wanted to be able to have the script be:
> 
> (Object get name).prettyFormatHow would that be achieved?
> 
> Even if in the script one could use “This”, but it is null.
> I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in 
> a TRIGGER (referring to the record/entity being operated on), etc. But it is 
> not, and I have trouble understanding why not.
> 
> 
> 
> 
>> On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech 
>> <4d_tech@lists.4d.com> wrote:
>> 
>> 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 notation, 
>> but the way to write generic code is different.
>> 
>> if you want to make your code generic in object notation, 
>> I think you need to fully commit.
>> 
>> what I mean by that, is that you need to think of objects and classes, 
>> properties and methods.
>> 
>> basically, instead of
>> 
>> doIt(Self)
>> 
>> you would write
>> 
>> $obj.doIt()
>> 
>> where the doIt() formula works on "This".
>> 
>> in my opinion, to take full advantage of object notation, 
>> it is pretty much mandatory to use 
>> 
>> This
>> Signal
>> Formula
>> Form
>> 
>> extensively, as well as 
>> 
>> Storage
>> New shared object
>> New shared collection
>> 
>> strategically.
>> 
>> simply replacing interprocess/process variables with object notation,
>> may semantically look like object based coding, 
>> but at that level you may be losing major advantages of classic code,
>> while not gaining much from what the new way of coding has to offer.
>> 
>>> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech 
>>> 

Re: Object notation replacement for use of Self in a script — v18

[Chris Belanger via 4D_Tech]

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 want to enforce a proper uppercase/lowercase on all three, so in the old 
> days I created an object, set the method to "UpperLower(self)", duplicated it 
> three times, change the object name and I'm done.  For simplicity sake, lets 
> say that UpperLower simply do $1->:=Uppercase($1->).
> 
> How would you do the same while using object notation instead of a variable, 
> dynamic or not?
> 
> Thanks,
> 
> Lahav
> 
> 
> -Original Message-
> From: 4D_Tech <4d_tech-boun...@lists.4d.com> On Behalf Of Keisuke Miyako via 
> 4D_Tech
> Sent: Wednesday, April 29, 2020 10:14 AM
> To: 4D iNug Technical <4d_tech@lists.4d.com>
> Cc: Keisuke Miyako 
> Subject: Re: Object notation replacement for use of Self in a script — v18
> 
> 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 notation,
> but the way to write generic code is different.
> 
> if you want to make your code generic in object notation, I think you need to 
> fully commit.
> 
> what I mean by that, is that you need to think of objects and classes, 
> properties and methods.
> 
> basically, instead of
> 
> doIt(Self)
> 
> you would write
> 
> $obj.doIt()
> 
> where the doIt() formula works on "This".
> 
> in my opinion, to take full advantage of object notation, it is pretty much 
> mandatory to use 
> 
> This
> Signal
> Formula
> Form
> 
> extensively, as well as 
> 
> Storage
> New shared object
> New shared collection
> 
> strategically.
> 
> simply replacing interprocess/process variables with object notation, may 
> semantically look like object based coding, but at that level you may be 
> losing major advantages of classic code, while not gaining much from what the 
> new way of coding has to offer.
> 
>> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> 
>> wrote:
>> And v18r3 does not even have a solution to this in its documentation.
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Object notation replacement for use of Self in a script — v18

[Chris Belanger via 4D_Tech]

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 describe is that I need a way to generically ‘get’ and ’set’ the 
value of an object (meaning an entry variable on the form).

1) A variable is placed on the form. It’s “variable or expression” is:
Form.LB.Browser_JobForms.en_edit.RigFrom.  It has an object name of  
“enLSDFromRigDispatch”

I have given it this name because it gives me a simple methodology to SHOW/HIDE 
a whole group of objects on the screen with OBJECT SET VISIBLE(*; “enLSD@“;…)

Now I wish to use a standard project method to ‘pretty-format’ this variable.
With ‘4D Classic’ this is easily achieved by making a project method that takes 
a POINTER in $1. 
The OBJECT SCRIPT would be something simple, like:   
PRETTY_FORMAT(Self)
[PRETTY_FORMAT, given Self, would be able to get at the CONTENTS of the 
variable and do any formatting options needed]

With ‘4D DOT NOTATION’ …
—  How do I create a simple OBJECT SCRIPT that would do something similar to 
that in 4D Classic?  —
I don’t feel that I should have to resort to using the ‘variable or expression’ 
name in every single script; because what happens if I change that variable for 
some reason and it totally screws up the object script? And it also makes it 
very complicated.
THE OBJECT METHOD should be something as simple as:
PRETTY_FORMAT ( Object Get Name )—— instead of Self

The PRETTY_FORMAT( ) should be able to get at and set the value of the form 
object from that name.

Alternatively, if one wants to not bother having scripts for every input 
variable that needs PRETTY_FORMAT, they could just do it in the FORM METHOD:
Case of
:( Form event code = on load ) 
Form.col_toPrettyFormat:= new collection ( Object Name 1, Object Name 2 
) …  // objects that need to be ‘Pretty Formatted'

: ( Form event code = on losing focus )
$curObjectName:= Form Event.objectName
… see if is in the list of .col_toPrettyFormat …
PRETTY_FORMAT( $curObjectName )

…

So how would one implement something like:
PRETTY FORMAT ( Object Get Name ) in a script; or   PRETTY FORMAT ( 
Form Event.objectName )
???

Thanks,
Chris

p.s. what you describe, Keisuke, is in 4D v18r3; the ability to create classes. 
That is very intriguing and a necessary development in 4D, as is C_VARIANT( ).
If one wanted to be able to have the script be:

(Object get name).prettyFormatHow would that be achieved?

Even if in the script one could use “This”, but it is null.
I think that ’This’ should be perfectly valid to use in an OBJECT SCRIPT, in a 
TRIGGER (referring to the record/entity being operated on), etc. But it is not, 
and I have trouble understanding why not.




> On Apr 29, 2020, at 10:14 AM, Keisuke Miyako via 4D_Tech 
> <4d_tech@lists.4d.com> wrote:
> 
> 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 notation, 
> but the way to write generic code is different.
> 
> if you want to make your code generic in object notation, 
> I think you need to fully commit.
> 
> what I mean by that, is that you need to think of objects and classes, 
> properties and methods.
> 
> basically, instead of
> 
> doIt(Self)
> 
> you would write
> 
> $obj.doIt()
> 
> where the doIt() formula works on "This".
> 
> in my opinion, to take full advantage of object notation, 
> it is pretty much mandatory to use 
> 
> This
> Signal
> Formula
> Form
> 
> extensively, as well as 
> 
> Storage
> New shared object
> New shared collection
> 
> strategically.
> 
> simply replacing interprocess/process variables with object notation,
> may semantically look like object based coding, 
> but at that level you may be losing major advantages of classic code,
> while not gaining much from what the new way of coding has to offer.
> 
>> On Apr 29, 2020, at 14:55, Chris Belanger via 4D_Tech <4d_tech@lists.4d.com> 
>> wrote:
>> And v18r3 does not even have a solution to this in its documentation.
> 
> **
> 4D Internet Users Group (4D iNUG)
> Archive:  http://lists.4d.com/archives.html
> Options: https://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  

Re: 4D Friday Happy Hour on ZOOM - Again! May 1 @ 3:30 PM PDT / 6:30 PM EDT

[Milan Adamov via 4D_Tech]

> On 30 Apr 2020, at 17:18, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Hope you can join us.

That’s after midnight for me. I’ll try to attend, but I might be in bed already.

Milan
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Multple windows within the same process

[Jeffrey Kain via 4D_Tech]

A lot more scalable too - one server process per client dedicated to the UI, no 
matter how many windows are open locally...

> On Apr 29, 2020, at 11:52 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Where workers come in is to do, well - work. All the heavy processing be it
> lookups, calculations, whatever can be done by workers and just the results
> are pass back to the form that initiated them. It's a really different way
> of thinking about building your forms.

**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

4D Friday Happy Hour on ZOOM - Again! May 1 @ 3:30 PM PDT / 6:30 PM EDT

[Kirk Brooks via 4D_Tech]

Hi folks,
Last week was fun so we're doing it again tomorrow.

>> Please note I pushed the start time back half an hour 'cause 3 is a
little early over here on the left coast. It is a work day, after all.

Topic: 4D Friday Happy Hour
Time: May 1, 2020 03:30 PM Pacific Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/83417515161?pwd=Zk1FSDVHQ3BWdHlSdi9TNU53SkpZdz09

Meeting ID: 834 1751 5161
Password: 4d4all   <<<

One tap mobile
+16699006833,,83417515161#,,1#,729196# US (San Jose)
+13462487799,,83417515161#,,1#,729196# US (Houston)

Hope you can join us.

-- 
Kirk Brooks
San Francisco, CA
==
**
4D Internet Users Group (4D iNUG)
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**