Re: 4D command returning a value request

[Bill Weale]

ummm….

divine wisdom = Engineering?

or, Engineering:=divine wisdom?



www

> On Aug 30, 2016, at 12:47 AM, Keisuke Miyako  wrote:
> 
> but this is just my own way of reasoning, not divine wisdom (I did not 
> consult Engineering).

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

Re: 4D command returning a value request

[Keisuke Miyako]

the language is evolving, so some rules can feel a bit arbitrary if not 
retrospective.

my understanding is that the OK variable is used to interact with the user.

sure, a command may fail because of the system, network, etc.
but for me, as far as OK is concerned, the focus is on the user.

some old commands are designed to present a dialog when a parameter is omitted,
so the boundary becomes blurry.

new commands such as JSON Parse or DOCUMENT TO TEXT do not update OK,
even though they do throw an error.

what is interesting with these commands is that they never interact with the 
user.

but this is just my own way of reasoning, not divine wisdom (I did not consult 
Engineering).


宮古 啓介
セールス・エンジニア

株式会社フォーディー・ジャパン
〒150-0043
東京都渋谷区道玄坂1-10-2 渋谷THビル6F
Tel: 03-6427-8441
Fax: 03-6427-8449

keisuke.miy...@4d.com
www.4D.com/JP

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

Re: 4D command returning a value request

[Kirk Brooks]

Aaron,
Without speaking to your illustration of Receive Packet in particular but
to speak more generally you can accomplish much of this sort of
functionality using an IP c-obj.

Since v15 I've started initializing a var called <>appObject on startup.
You can call it anything, of course. Once it's there you can write pretty
much any sort of setters and getters you need to keep track of whatever.
More specific to your example would be a process scope var. I call that one
prosObject and it works exactly the same way.

For example, let's say I want to replace the system OK with my own which
will be boolean. Since this is a process level var I'll use prosObject:

// isOK -> boolean
$0:=ob get(prosObject;"OK";Is boolean)


I suppose that should be 'Get_OK' but I like the shorter version. The
setter would be:

// SET_OK (bool)
ob set(<>appObject;"OK";$1)


Let's say I want to monitor a printing job. Process level again.

// PRINT_SET_printableWidth (longint)
// PRINT_SET_printableHeight (longint)
// PRINT_SET_printedHeight(longint)
and so on with the complimentary getters. For something like this I'd use
Canon Smith's excellent component to allow me to group these things into a
single JSON object most likely called 'printjob' so a setter would look
like:

// PRINT_SET_printableWidth (longint)

Obj_set_long(prosObject;"printjob.printableWidth";$1)

​and the getter:​

// PRINT_GET_printableWidth

Obj_get_long(prosObject;"printjob.printableWidth:)


by doing that I can clean up at the end with

// PRINT_CLEAR

ob remove(prosObject;"printjob")


An aspect of this I like a lot is that I don't have to dedicate specific
variables to those things I need. I also like that I can easily see
everything I have declared in the process by looking at a single variable:
prosObject. Much easier than having to look through the entire database
variable table with I'm trying to troubleshoot something.

And it's easy to extend this idea without a lot of refactoring. Let's say I
want both a process level and an app level OK var. Not sure why but this is
just an example. I could write two different setters and getters or:

// SET_OK (bool;pointer)

// $1 is the value

// $2 is pointer to the obj

ob set($2->;"OK";$1)


Now SET_OK can be used to "OK" in any c-obj. I'm really liking the
flexibility this provides.


On Mon, Aug 29, 2016 at 3:04 PM, Aaron  wrote:

> Question:
> Will There be a 4D release soon to increase the usage of returned values
> on 4D command, so that I can reduce the reliance on system global process
> variables, like “OK"?
> a good 4D command canidate is Receive Packet.
> I consider "OK" global variable because it never looses scope, which is
> what a global variable is.
>

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