xsharp.eu

Hi Chris,
I have opened a new thread in the forums to answer to your website article.

And here is my opinion: please don't loose time to emulate this strange behavior!
Maybe invest the time to analys current code either through the XPorter/VO or with a separate tool to find problematic places in VO code.

Wolfgang
P.S. I'm currently helping an Italian customer to migrate his large VO 2.5 application to 2.8, and I'm really wondering how many things that make no sense were allowed by VO or sometimes are threated in a completely illogic manner

Wolfgang,
i'd second to "drop" this - although, i'm probably not qualified to talk, as a quick search all in my projects shows only a handful of "BYTES"

Chris, what about the bigger types? "WORD" i find quite more... most are holding return vals from windows dialogs, so should be unproblematic.
Maybe it might make sense to build a tool to list "operations" on this types...

Hi,

I am happy that you find this. In some old codes a I wondered about some strange arithmetic behaviours.
I had to refactor code like this: to this: to have correct results.

My opinion: keep the dotnet standard.

Stefan

Guys,

This has to do with all 3 types BYTE, WORD and SHORT. Everywhere you are using them in calculations, in some cases results (intermediate or final ones) might be overflowing to 8 bits or 16 bits and in other cases they may not. If you are using them just to store values, without doing calculations with them (or your calculations use small enough numbers so that they never overflow), then there is no potential problem.

Hi Chris

There are some things (sets of incompatibilities) that will simply defy all means of resolution within compiler logic.

If this is the case here, I'd suggest separate packages which effectively poke their noses back into the source code and amend as required.

They'd only be used once by those who need them to get everything "XSharped", or have I got the wrong end of the stick?

Terry