X# Cahors 2.6a

[boonnam]

As I stated on the comment for the Cahors 2.6a, I'm having the same issue as Leonid where VS would check out the project files and change the version number. I'm also seeing two additional changes.
<Import Project="$(MSBuildExtensionsPath)XSharpXSharp.Default.props" /> was changed to <Import Project="$(XSharpMsBuildDir)XSharp.Default.props" />

<XSharpProjectExtensionsPath>$(MSBuildExtensionsPath)XSharp</XSharpProjectExtensionsPath> line was removed.

If these changes are correct, I can go ahead and check in the changes.

Thanks,
Boonnam

[robert]

Boonnam,

These changes are intended and should be accepted.
If you revert them then the projectsystem will keep on making them.

Robert

[leon-ts]

Boonnam,

Before 2.6a, there was version 2.6 (without a). And the changes you described were made in it, and Robert wrote about them in the whatsnew document in the "Changes to project files" section. After version 2.5.2, I installed version 2.6. All changes described by Robert were made to the xsproj files automatically and there were no problems with them. At the same time, the version in them remained 2.5.2.0 (but I did not immediately pay attention to this, since VS and GIT did not signal any problems). GIT marked the xsproj files as updated and committed successfully. Later I installed version 2.6a (when it came out). And it was on this version that the problem I described earlier arose. The version number in the xsproj files remained 2.5.2 and the files did not change in any way, but were marked as updated. Because of this, GIT started to go crazy.

Best regards,
Leonid

[Chris]

Hi Boonam,

I do not think there's any problem with those changes. But I assume your solutions/projects all still open and build correctly, is that right?

[boonnam]

Hello Chris,

Sorry for not replying to your question about the build. I got busy with our quarter release and decided to put our X# project on hold. We are not able to build with 2.6a. This morning I installed version 2.7, and with some minor changes, I was able to build. I was testing if passing by reference using @ is fixed. I don't believe it is fixed. If I use "ref" instead of @, my report is correct.

[Chris]

Hi Boonam,

Can you please post a sample of the code that fails, so we can look into it?

[boonnam]

I re-ran my report in debug to see the values again. This time I was surprised to see the number, so I decided to create a console app that represented our report.

Code: Select all

FUNCTION Start() AS VOID STRICT    
    local iRow as DWORD
    
    iRow := 100
    ? iRow   
    
    Header(@iRow)
    
    ? iRow
    
    wait
    
    RETURN	
   
function Header(iRow)
    ? iRow
    
    iRow := 0
    ? iRow
    
    return nil

Here is the result with 2.7:
100
16642860
0
100


Here is the result with version 2.5b:
100
100
0
100

[Chris]

Hi Boonam,

Thanks, I see the problem, it's because your argument LOCAL is defined as a DWORD, but the function expects a USUAL. To make it work, you need to either declare also the LOCAL as USUAL, or strongly type the parameter in the function as REF DWORD.

I don't see how it would be possible to support this code without changes (different type passed by reference, than the expected one), but will leave it to Robert to comment in case he has an idea.

[boonnam]

Chris,

Please correct my sample console app for me. I like to see the correct syntax. So far the only way I am able to get this working is by change

Code: Select all

Header(ref iRow)

but keep everything the same. This is what I did for our report program few months ago, but there are several other areas that I would need to fix. I was waiting to see if you guys would fix passing by reference by using @.

If I declare iRow as USUAL, I also have to strong type the parameter in Header function as usual in order to compile, but the result is also incorrect.

I could not get my console app to run when I strong type the parameter as dword in the Header function. This is why I am asking for the correct syntax. Thanks.

[Chris]

Hi Boonam,

The other two ways are the following:

1. Change line
LOCAL iRow AS DWORD

to

LOCAL iRow AS USUAL

2. Change only this line
FUNCTION Header(iRow)

to

FUNCTION Header(iRow REF DWORD)

and make no other change in the code in both. But in either case, you also must have enabled the option "Implicit casts and conversions (/vo7)" in the project options, because I suspect you have this disabled right now. This tells the compiler to handle in this case (when used in a parameter) the "@" operator as "pass by reference", instead of "address of". Of course this makes it impossible to directly pass the address of a var to a method, without using an intermediate variable first.

This is just a fundamental difference between VO and .Net, VO uses @ for two things, for both "by reference" and "address of", while in .Net those are two completely different things. So it is absolutely not possible to completely emulate VO's behavior 100% in .Net, we could only make it close enough, as described above. If you do not want to use the /vo7 option, then indeed you just need to use the "REF iRow" syntax instead of "@iRow", which removes the ambiguity and will always do what you intend.