I am having an issue with the OpenEdge.Core.String and OpenEdge.Core.Collections.Array classes in 11.6.3. I am trying to split a String into an Array. When I call the static Split or non-static Split methods, I am getting an OpenEdge error
Routine Split OpenEdge.Core.String sent called routine String
OpenEdge.Core.String mismatched parameters. (2570)
Error attempting to push run time parameters on the stack. (984)
Sample code that produces this error in 11.6.3 is shown below.
using OpenEdge.Core.* from propath.
using OpenEdge.Core.Collections.* from propath.
define variable x as String no-undo.
define variable a as Array no-undo.
x = new String("this is a test").
a = String:Split(x).
Has anyone seen this before?
Thanks,
Nick Watkins
There are some, um, interesting behaviours with certain functions and LONGCHARs , which get fixed as as they're found. The ENTRY() function here can return CHAR or LONGCHAR (which it arguably should, since the Value property is defined as LONGCHAR.
new String(entry(1,obString:Value,pcDelimiter)).
After doing some more debugging, the code at line 98 is the following:
do iLoop = 1 to iMax:
oArray:Add(new OpenEdge.Core.String(entry(iLoop, poValue:Value, pcDelimiter))).
end.
The issue appears to be with the constructors in the String class. This can be replicated by trying to create a String using the entry function like above.
using OpenEdge.Core.String.
define variable obString as String no-undo.
define variable pcDelimiter as character no-undo.
define variable obNewString as String no-undo.
assign
obString = new String("this is a test.")
pcDelimiter = ",".
obNewString = new String(entry(1,obString:Value,pcDelimiter)).
The above code causes the error. The weird thing is that doing the entry function to a longchar and using that longchar to create the string works.
There are 2 constructors, one with a CHAR parameter and one with a LONGCHAR parameter. If you pass a LONGCHAR (or ENTRY(<a longchar>), it should call the constructor that takes a LONGCHAR. If you pass a character string or a CHARACTER variable, it should call the other one. Even though you could call either in this case, the one with the CHARACTER parameter is a better match so that's the one it should pick. This is all pretty vanilla. But if it's not working, it looks like an AVM bug to me.
There are some, um, interesting behaviours with certain functions and LONGCHARs , which get fixed as as they're found. The ENTRY() function here can return CHAR or LONGCHAR (which it arguably should, since the Value property is defined as LONGCHAR.
new String(entry(1,obString:Value,pcDelimiter)).
This is what I would have thought as well. Even if the ENTRY function returned a CHARACTER, it should have still worked. Since the AVM sent an invalid parameter message, it seems that something (the ENTRY function, the AVM, something else?) thinks that something that was not a CHARACTER and not a LONGCHAR was returned.
I will send this to TS as a potential bug.
Thanks,
Nick
> On Jul 10, 2017, at 5:10 PM, Peter Judge wrote:
>
> There are some, um, interesting behaviours with certain functions and LONGCHAR
a goal when longchar was added (in v9) was that programming with longchars should be exactly the same as when using char and they should be /mostly/ interchangeable (max length and character set being two obvious differences).