ProgressLink case submission manual entry doesn't work

Posted by cverbiest on 14-Sep-2015 02:51

Entering the information manually does not work.  I guess there are mandatory fields on the form where I do not have access to, making it impossible to fill out all fields.

Below is the case I tried to submit.

Inconsistent compiler results with .Net datatypes casing

Following sample code does not compile
Invalid datatype specified: System.byte[]. Specify a datatype such as 'character' or the name of a class. (5638)
**  Could not understand line 4. (196)

If you change lcfirst to no, it does compile. If you change it back to yes it continues to compile until you start a new prowin session.

To reproduce : start a new prowin(/prowin32) session and execute the sample below

/* Sample */
&scoped lcfirst yes
&if {&lcfirst}
def var ba as "System.byte[]".
def var bac as "System.Byte[]".

All Replies

Posted by Mike Fechner on 14-Sep-2015 03:02

Hi Carl, what you are seeing is expected behavior.

.NET Class names are case sensitive. So the proper type name in .NET is System.Byte[] - not System.byte.

Progress relaxes this requirement so that when the type was initially found (and in a way cached in the AVM bridge) it allows case insensitive access.

If you ask me, I'd rather not have Progress relaxing the case requirement after first usage. But that would be an enhancement request, not a bug.

Posted by TheMadDBA on 14-Sep-2015 09:54

I guess it depends on your definition of "bug" ;-)

I will never understand why someone thought relaxing the case restriction was a good idea. It just causes more issues than it is worth imo.

Posted by cverbiest on 14-Sep-2015 10:57

Compiling one class causes the compilation of an unrelated class to succeed , this looks like a side effect to me.

I'll post an idea for an option to make class variables case sensitive anyway . If the case isn't correct for a class reference it won't compile on linux either.  This issue isn't limited to .Net data types.

This thread is closed