Page 5 of 7
Re: Miscellaneous questions about converting VO code to X#
Posted: Tue Apr 23, 2024 12:10 pm
by robert
Kees,
Kees Bouw wrote: ↑Tue Apr 23, 2024 10:16 am
Found it, it is probably String2Symbol("#NULL_DATE") right?
String2Symbol("NULL_DATE")
Robert
Re: Miscellaneous questions about converting VO code to X#
Posted: Wed May 01, 2024 1:37 pm
by 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.
Re: Miscellaneous questions about converting VO code to X#
Posted: Wed May 01, 2024 5:15 pm
by 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.
Re: Miscellaneous questions about converting VO code to X#
Posted: Mon May 06, 2024 9:19 am
by 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.
Re: Miscellaneous questions about converting VO code to X#
Posted: Fri May 31, 2024 8:58 am
by 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.
Re: Miscellaneous questions about converting VO code to X#
Posted: Tue Jun 04, 2024 11:52 am
by 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.
Re: Miscellaneous questions about converting VO code to X#
Posted: Tue Jun 04, 2024 12:46 pm
by wriedmann
Hi Kees,
we have ported our MAPI library, and it seems to work also in X#.
Wolfgang
Re: Miscellaneous questions about converting VO code to X#
Posted: Fri Jul 12, 2024 10:36 am
by 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.
Re: Miscellaneous questions about converting VO code to X#
Posted: Fri Jul 12, 2024 11:11 am
by 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.
Re: Miscellaneous questions about converting VO code to X#
Posted: Fri Jul 12, 2024 3:23 pm
by 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.