Length function in Progress 11

Posted by ankitshukla on 03-Sep-2015 08:57

Hi,

I have a example code below

DEFINE VARIABLE l AS int NO-UNDO.

l = asc("A").

MESSAGE length(l)
VIEW-AS ALERT-BOX INFO BUTTONS OK.

This code doesn't throw incompatible error while compiling in OpenEdge 11.4 environment. But it does throw the compilation error in OE 10.2B. It seems that length function functionality has been changed in OE 11.

Can any one explain why it is happening ? And please provide any link which explain the OE 11's new functionality. I have found so many links which explains the new functionality of OE 11 but I don't find these small amendment like length function etc in any of the OE 11 document. If someone has a detail information regarding all these changes in OE 11 please provide some link.

All Replies

Posted by Garry Hall on 03-Sep-2015 09:05

I can't put my finger on it right now, but this was a change between 10.2B and 11.0. IIRC, there was a behaviour change release note added for this recently, within the past couple of years. Check the 11.4 and 11.5 release notes. I'll see if I can dig it up.

Posted by gus on 03-Sep-2015 09:12

What do you expect the length of an integer variable to be?

Posted by Lieven De Foor on 03-Sep-2015 09:18

The length function applies to string, raw or blob and can return the length in character units, bytes or columns.

By default, the unit of measurement is character units.

Posted by George Potemkin on 03-Sep-2015 09:41

In V11.4 length() works with any data types like:

length(var) = length(string(var)).

Posted by ankitshukla on 03-Sep-2015 10:02

Thanks Guys.

But can someone please provide the any link which explain all these new changes in OE 11 or latest.

Posted by Garry Hall on 03-Sep-2015 10:27

It is scheduled for adding to the doc in 11.6. Apparently this behaviour also existed in 10.2B for handling values that could only be determined at runtime e.g. LENGTH(BUFFER-FIELD:BUFFER-VALUE) or LENGTH(WIDGET-HANDLE:INPUT-VALUE). In 11.0, this was extended to all circumstances.The LENGTH doc will reflect something like this:

As of 11.0, the ABL LENGTH() function now handles non-character datatypes e.g. LENGTH(10), where is a literal integer. The returned value is the length in characters of the value when represented in the ABL's default display format for that datatype. e.g the default format for an INTEGER is "->,>>>,>>9", so 10 would be represented as "10", resulting in LENGTH(10) returning 2. The default format for a LOGICAL value is "yes/no", so LENGTH(yes) or LENGTH(true) would return 3.

I cannot find a release note explaining this change.

Posted by gus on 03-Sep-2015 12:49

when would one want to have that?


> On Sep 3, 2015, at 10:42 AM, George Potemkin wrote:
>
>[collapse] From: George Potemkin
> Post: RE: Length function in Progress 11
> Posted in: Forum
> Link: https://community.progress.com/community_groups/openedge_development/f/19/p/20013/71026.aspx#71026
>
> In V11.4 length() works with any data types like:
> length(var) = length(string(var)).
>
>
> --
> You were sent this email because you opted to receive email notifications when someone created a new thread.
>
> To unsubscribe[collapse] from:
> - ...only this thread, disable notifications at https://community.progress.com/community_groups/openedge_development/f/19/p/20013/71026.aspx#71026.
> - ...all email notifications from Progress Community, navigate to "Settings", click on the "Email" tab, then under the "Email Configuration" section, set Send Notifications to "No".
>[/collapse][/collapse]

Posted by Roberta Miller on 03-Sep-2015 13:45

Recently logged defect PSC00339768 is also related to this discussion. In OpenEdge 10.2B and earlier, using the LENGTH function on a MEMPTR raises the compilation error mentioned earlier ( "** Incompatible data types in expression or assignment. (223)" ). In 11.0 and up no error is raised, but the function returns 0 no matter what the size of the MEMPTR actually is.

Posted by Frank Meulblok on 04-Sep-2015 03:46

'The returned value is the length in characters of the value when represented in the ABL's default display format for that datatype. e.g the default format for an INTEGER is "->,>>>,>>9", so 10 would be represented as "10" '

That is not according to the current actual behavior. It returns the length of the *unformatted* string representation.

"disp 1234567 length(1234567).." shows a length of 7 - thousands seperators from the default format aren't included.

Posted by Garry Hall on 04-Sep-2015 08:23

In light of this forum question, and the bug Roberta referenced, we have been looking at this change to the LENGTH() function.

The correct way to get the size of a MEMPTR is GET-SIZE(), as documented.

This thread is closed