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.
If this is not the Right forum for this question, then the answer to this question might be where do I make that request.
Why returned values are a benefit: (optional reading)-------------------------------------------------------------
I don’t want to get into a discussion why global variables should not be used. There are very legitimate reasons for wanting enhancements of 4D commands to return a values
Back to Receive Packet. and why its specifically is a benefit
Receive Packet($docref;$data;$EOL) for example sets the OK system global process variable to 1, unless it reads no data ,then it is sets it to 0
It should be expanded, to return 1 or 0, and for backward compatibility the OK could be maintained as is.
while( (line = file.readline()) ==1)
Currently, because Receive Packet does not return a value, I instead need to write code like this in 4D.
Receive Packet($docref;$data;$EOL) //read the first line
Receive Packet($docref;$data;$EOL) //read, this example not as good because if in do stuff changes OK and I don’t program around it, the until will break
I realize I could write my own read line method(which I have), but I just thought it would be handy if Receive Packet itself could return 1 or 0, in a future code release.
It would also be nice if the read line supported CR, CRLF, LF types… I got around this by writing my own open file routine, which gets the EOL (this code is not shown)
Example of Readline:
While (Readline ($docref;->$read;$EOL)=1) //Parse the text file referenced , returns 1 if not end of File, 0 at end; read is the contents of line; EOL must be provided
// Method: readline
C_LONGINT($0) //returns 1 or 0
C_TIME($1) //doc reference
C_POINTER($2) //data can be updated and returned to user
//read to EOL character
$0:=1 //sometimes the last line does not have a EOL, so we still need to return 1
> > If this is not the Right forum for this question, then the answer to this question might be where do I make that request.
> This is not the right forum you will need to make a feature request for that
Here is some more info that should help you get your request to the right location:
Having the feature requests handled through the forums is quite valuable to the community because of the following:
1. 4D Engineering participates on the 4D Forums, so you have the opportunity to discuss the feature request in a more immediate fashion.
2. Other users can participate in the feature request discussion and help refine the feature request so that it is appealing to more users. Also, the more users who participate in the discussion, the more visibility that particular feature request will have.
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:
I suppose that should be 'Get_OK' but I like the shorter version. The
setter would be:
// SET_OK (bool)
Let's say I want to monitor a printing job. Process level again.
// PRINT_SET_printableWidth (longint)
// PRINT_SET_printableHeight (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
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
Now SET_OK can be used to "OK" in any c-obj. I'm really liking the
flexibility this provides.
> 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.
You're requresting 4D to change all 4D command to become 4D function. It
might not be too practical especially 4D has been very busy on v16 which
is a very major upgrade - preemptive threading on 4D language. Not to
mention fine tuning the new 4D network on MacOS 64bit server.
We have doing the following to cater the OK issue you mentioned
On Err Call("CatchError")
//do your stuff (this might change OK variable or generate other error
captured to Trans_error variable)
On Err Call("")
4D iNug Technical <[hidden email]> writes:
>Receive Packet($docref;$data;$EOL) //read, this example not as good
>because if in do stuff changes OK and I don’t program around it, the
>until will break
> //do stuff
A interprocess variable can be very convenient in 4D , it doesn’t exist in other languages,
but in other languages a solution would be to implement a database table storing settings for each userid.
Aaron Blazer - Database Analyst
North American Marketing Solutions, Inc. | 3245 N 126th St | Brookfield, WI 53005-3187
Phone: (262)289-9200 x119 | Fax: (262)289-9208
North American Marketing Solutions, Inc. - http://www.nams-inc.com/ <http://www.nams-inc.com/>
Home of 360 Direct - http://www.360direct.com/ <http://www.360direct.com/>
CONFIDENTIALITY NOTE: This email and any attachments are confidential and may be protected by legal privilege. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this email or any attachments is prohibited under applicable law. If you have received this email in error, please notify us immediately by returning it to the sender and delete this message in its entirety from your computer.