Other compatibility issues
There are a lot of small issues. Some of them should be listed here:
- You are using a method
Open()in any of your VO windows classes? This will not compile anymore because the Window class has a variable
oPenthat conflicts with this method name
- you are using '-' in resource paths? For example something like this:
icoFett Icon c:\cavowork\brandnamic\ba-erp\icons\Fett.ico
You need to surround the filename with double apostrophes like this:
icoFett Icon "c:\cavowork\brandnamic\ba-erp\icons\Fett.ico"
_CodeBlockclass: if you are using subclasses of the
_CodeBlockclass: the Eval method in VO is using the Clipper calling convention, the one in the Vulcan runtime the Strict calling convention
- Functions or methods that pass an object by reference, and you pass a inherited object. This code
function CleanUpServer( oServer ref DataServer ) as void oServer:Close() oServer := null_object return
compiles in VO without any issue when you call it with any subclass of DataServer or DBServer. This is very dangerous and therefore it will not work anymore in X#.
Local staticin VO is currently (X# 1.1.2) not recognized by the X# compiler, but is valid in VO. Change it to
staticalone in your VO code.
Fontcannot work anymore because there is also a method. Change to
:ControlFont, that should also work on the VO side. For bBrowser use
- never versions of the VO GUI classes contain an access
IsDisabledin the class
Control. This is missing in the .NET classes. The same is true for the methods
GetStyle(). Add these methods to you X# version of the GUI classes, or write your own methods.
DynToOldSpace()is not supported anymore. Replace in your code by MemAlloc()/MemFree()
- if you use
CreateInstance()on classes that have no constructor, you will receive a runtime error. Add Init() methods to all of your classes on the VO side.
- the function
B64EncString()is missing from the Vulcan runtime library
intare two different parameter types. If you have a dword parameter in one class and a int parameter in a subclass (or the way around), the .NET runtime will treat them as different methods and call the one or the other based on the parameter type. This is true only for strong typed methods (for the others, the parameters are alway typed