Miscellaneous questions about converting VO code to X#

[robert]

Kees,

Found it, it is probably String2Symbol("#NULL_DATE") right?

String2Symbol("NULL_DATE")

Robert

[Kees Bouw]

Hi all,

In the application I am converting to X# I found that in many places it relies on the fact that NULL_STRING is in fact an empty string. In X# however, NULL_STRING seems to be equal to NULL or NIL. In VO NULL_STRING seems to be just "". This behaviour can be simulated in X# by setting the /vo2 option. But because I want to convert everything to X# I am reluctant to change options which make it more like VO. Also this option initialises every string variable to an empty string automatically which I don't need or want. I am thinking about simply replacing every occurrence of NULL_STRING with "". Before I do that, I would like to ask if anyone knows any reason why that would not be a good idea.

Kees.

[Chris]

Hi Kees,

I think it's better to just enable the /vo2 option, this is why we introduced it, to help porting applications from VO.

In VO, not only NULL_STRING practically means "", but all locals and class variables are also used like that:

Code: Select all

FUNCTION Start() AS INT
LOCAL c AS STRING
LOCAL o AS TestClass
? c == "" // TRUE
o := TestClass{}
? o:c == "" // TRUE
RETURN 0

CLASS TestClass
EXPORT c AS STRING
END CLASS

When you enable the /vo2 option in X#, the compiler mimics also this behavior. If you do not initialize (or forget to do that) all such vars to "" in X#, all sorts of problems may arise (at runtime...) in cases where your VO code relies on that.

So I'd suggest to just enable the option, nothing wrong about it, it only makes code say 0.001% slower... If you write a new .Net app, it's probably better to not use it, but even if you want to enable it also in this case, there's nothing wrong with it.

[Kees Bouw]

Hi Chris,

Thank you very much for your advice. I have had many warnings about using unassigned local variables (XS0165) and fixed all these so I thought I would not have that problem anymore. I am not sure if X# also warns about using unassigned class variables or other unassigned variables. Also, you are right that other unforeseen problems may arise while there is not much harm in enabling the /vo2 option. So I shall follow your advice and enable the option.

Kees.

[Kees Bouw]

The application that I have to convert to X# (which I did not write and has almost no documentation or comments) uses some MAPI code. If anybody has experience with this, I have a few questions.

- The VO version uses a library called "MAPI.H" which defines MAPI classes, functions etc. using a lot of memory manipulation with pointers and buffers, very scary stuff. Is there a modern dot-net MAPI library that can be used instead?

- Where does this MAPI.H VO library come from, any ideas?

- I have tried to add a reference to "msapi32.ocx" but this gives the error "Operation is not valid due to the current state of the object". Would it be useful to use this ocx in some other way and if so, where can I find examples and documentation?

- After importing the code with VOXPorter, I get errors like these:

Code: Select all

LOCAL aRecip AS DWORD PTR

aRecip := PTR(DWORD, MemAlloc(ALen(oMessage:RecipList) * _SIZEOF(DWORD)))

Error XS9061 The "PTR(..) operation" is not allowed for method or function calls. If the method or function returns a pointer then consider using the (<Type> PTR) syntax instead.
What is the best way to fix this?

Kees.

[Chris]

Hi Kees,

A google search on .Net MAPI shows several hits of libraries available, but I don't have experience with any, so cannot suggest one. I am a bit surprised that nobody else had something to suggest, so bringing this up again for others to comment.

Regarding porting the VO library, I suspect it makes a lot of use of direct memory addressing so would need many changes to compile in .Net, so let's leave it for now as a worst case solution.

[wriedmann]

Hi Kees,
we have ported our MAPI library, and it seems to work also in X#.

MAPI.Classes.zip

(7.06 KiB) Downloaded 89 times

Wolfgang

[Kees Bouw]

In the VS debugger, I pressed F11 (step into) on this line of code:

Code: Select all

SELF:oDCRefBB:Server:Find("DESCRIPTION>='" + cDesc + "'", 0, adSearchForward)

The method Find does exist so I expected to go there. Instead, I got this message:



Then, when I clicked Yes:



Any ideas on why this may happen?

Kees.

[Chris]

Hi Kees,

This refers to the expression "SELF:oDCRefBB:Server" ("Server" is a property of the SELF:oDCRefBB object) which gets evaluated first, before the call to the method Find().

In order to help making debugging easier, you could split the call into 2 lines, first assign SELF:oDCRefBB:Server into an intermediate local, the call Find() on that local.

[Kees Bouw]

Hi Chris,

Thank you for your reply. Unfortunately it makes no difference. I changed the line to

Code: Select all

LOCAL oServer AS USUAL
oServer := SELF:oDCRefBB:Server
oServer:Find("DESCRIPTION>='" + cDesc + "'", 0, adSearchForward)

Now the same errors appear on the last line when I press F11 to go into the Find().

Kees.