VS replaces tabs by spaces

[Kees Bouw]

One more strange replacement by the Winforms designer in VS. After making a totally unrelated small change in the window (I added a button) and saving, the following line of code:

PROTECTED aEmacc AS ARRAY OF EAccount // Holds objects of type EAccount

had changed to these 2 lines:

PROTECTED aEmacc AS VOID
// Holds objects of type EAccount

So the type was changed to VOID and the line was split. Of course it caused a compilation error ("Field cannot have void type") which was easy to correct but it is weird that this code was changed.

Added note: It may be easy to change back but I have to do it every time I change something on the form!

[Chris]

Kees, thanks for your report, I see the problem as well. Will log it for Robert to look into it.

[ic2]

Hello Chris,

Kees, thanks for your report, I see the problem as well. Will log it for Robert to look into it.

I was curios about one thing: this is an error which should come up for everyone using X# & Winforms en VS when editing something in a Winform.

Is Kees the first one using this combination? I would say this is the most common way of using X# except for those who left all on VO forms or those who use WPF?

Dick

[robert]

Dick,

This problem only happens (in your build) when you declare a field "AS ARRAY OF <something>".
I have fixed this today in our internal build.

Robert

[ic2]

Hello Robert,

I have fixed this today in our internal build.

That is (again) amazingly fast!

Dick

[Kees Bouw]

Hi,

On https://docs.xsharp.it/doku.php?id=code ... _net_array I read that an array can be initialized with:

local aNumbers as int[]

So I thought instead of:

PROTECTED aEmacc AS ARRAY OF EAccount

which gets corrupted by the designer, I could use:

PROTECTED aEmacc AS EAccount[]

But this behaves differently, I get error XS0266 ("Cannot implicitly convert type 'ARRAYBase<iConnectEmail.EAccount>' to 'iConnectEmail.EAccount[]'.") on the line:

SELF:aEmacc := GetAccountData()

where GetAccountData is defined as follows:

FUNCTION GetAccountData() AS ARRAY PASCAL

and error XS1503 ("Argument 1: cannot convert from 'iConnectEmail.EAccount[]' to 'ARRAYBase<iConnectEmail.EAccount>'") on the line:

dwFrom := GetDefAccNum(SELF:aEmacc)

where GetDefAccNum is defined as follows:

FUNCTION GetDefAccNum(aAccounts AS ARRAY OF EAccount) AS DWORD PASCAL

What is the difference between AS ARRAY OF EAccount and AS EAccount[] ?

Another question: is there any benefit in adding PASCAL or STRICT? In the documentation it says "Most calling conventions are for backward compatibility only." Can I just remove the PASCAL and STRICT without any consequence?

Kees.

[FFF]

Kees,
AFAIU, ARRAY is an array of Usuals, EAccount[] is an Array of "typed" EAccount members, which certainly is not "equal".
What happens, if you write FUNCTION GetAccountData() AS EAccount[] ?

[wriedmann]

Hi Kees,

What is the difference between AS ARRAY OF EAccount and AS EAccount[] ?

"AS ARRAY OF EAccount" is a VO style dynamic array, on which youn can work with the VO array functions like AADD(), AScan(), ASort() etc.
"AS EAccount[]" is a fixed size .NET array.

The first one cannot be used in Core dialect applications, because the .NET Framework does not knows nothing about the xBase ARRAY datatype.

Wolfgang

[Chris]

Hi Kees,

Regarding using STRICT/PASCAL:

When a method definition has typed parameters like that:

METHOD Test(n AS INT) AS STRING

then the compiler knows this is a STRICT calling convention method, so you do not need to specify it yourself.

When it uses untyped parameters:

METHOD Test(n)

then the compiler automatically emits it as a CLIPPER method.

Problem is when there are no parameters in the method

METHOD Test()
METHOD Test() AS INT

In both cases, the compiler does not know for sure what your intention is. There is a compiler/project option for that, "Implicit Clipper calling convention" (/vo5), found in the "Dialect" page of the project properties. When this option is enabled, then parameterless methods become CLIPPER by default, otherwise they are emitted as STRICT. This was introduced in order to make code compatible with VO, where methods are CLIPPER by default.

So, if you have this option enabled and want to make such a (parameterless) method emitted as STRICT, then you need to specify the keyword. If you have the option disabled, then there's no need to specify STRICT, the method becomes STRICT by default. When a method does include typed parameters (as in your specific example), then you do not need to specify it, the method again becomes STRICT automatically.