VO to X# migration questions (v1)

[Stavros Spanos]

Hi all

Starting our – long awaited – migration from VO 2.8 to X# we would like some help in the following issues.

1./ How about bBrowser, VO2ADO, ReportPro3?

What is the status of what we need from the above three products (Updates, New X# Versions, New Vn Versions), so that we complete the transition?

2./ VO XPorter Resource Issue

In our first effort to compile our base Classes we found the following.

VO Compiler allowed both two version of code:

//Path with no quotes
RESOURCE Button_Search_23x127_256 Icon G:CAVOAPPSImagesVO IconsButton_Search_23x127_256.ico
//Path with quotes
RESOURCE Button_Search_23x127_256 Icon "G:CAVOAPPSImagesVO IconsButton_Search_23x127_256.ico"

Building in VS the first version leads to an RC2135 ( file not found ) error. Furthermore the build rises the errors one by one and stops.

Of course we could fix this by editing the (many..) VO lines but I think this could be addressed by the VO Xporter tool.

Should we wait for a workaround?

3./ Error XS9010 due to VO Setup OLE Control generated Code

We use a lot of OLE Controls. For them VO has already generated code like the following:

ACCESS Appearance( )

LOCAL oMethod AS cOleMethod
LOCAL uRetValue AS USUAL

oMethod := cOleMethod{}
oMethod:symName := String2Symbol("Appearance")
oMethod:iMemberid := 6
oMethod:wInvokeKind := INVOKE_PROPERTYGET
oMethod:bRetType := 29

uRetValue := SELF:oAuto:__Invoke(oMethod, DWORD(_BP+16),PCount())

RETURN (uRetValue)


When building every block like this receives ERROR XS9010 (The function 'PCount' is only supported in functions or methods with CLIPPER calling convention (and not in ACCESS or ASSIGN methods) concerning the following line:

>>uRetValue := SELF:oAuto:__Invoke(oMethod, DWORD(_BP+16),PCount())

Is there something we have to do? Is there something to be addressed in VO Xporter Tool?

TIA

Stavros Spanos

[Chris]

Hi Stavro!

1./ How about bBrowser, VO2ADO, ReportPro3?

ReportPro there's already a version using the vulcan runtime available, for bBrower people have recompiled the vulcan version as well (it is really easy), again using the vulcan runtime. But very soon (I think in very few weeks) the X# runtime will be completely stable, so there will be a final version of those products available, to be used with the X# runtime alone.

I will let Robert reply about VO2ADO, but I think he will also have a X# version ready soon.

2./ VO XPorter Resource Issue

//Path with no quotes
RESOURCE Button_Search_23x127_256 Icon G:CAVOAPPSImagesVO IconsButton_Search_23x127_256.ico
//Path with quotes
RESOURCE Button_Search_23x127_256 Icon "G:CAVOAPPSImagesVO IconsButton_Search_23x127_256.ico"

Building in VS the first version leads to an RC2135 ( file not found ) error. Furthermore the build rises the errors one by one and stops.

Of course we could fix this by editing the (many..) VO lines but I think this could be addressed by the VO Xporter tool.

Thanks, VOXporter should had identified this and added the quotes automatically, will check why it didn't do that. So yeah, you can wait for a workaround, but on the other hand, do you have THAT many resources in your app, so you cannot quickly add the quotes in the VO version before exporting?

3./ Error XS9010 due to VO Setup OLE Control generated Code

We use a lot of OLE Controls. For them VO has already generated code like the following:

ACCESS Appearance( )

LOCAL oMethod AS cOleMethod
LOCAL uRetValue AS USUAL

oMethod := cOleMethod{}
oMethod:symName := String2Symbol("Appearance")
oMethod:iMemberid := 6
oMethod:wInvokeKind := INVOKE_PROPERTYGET
oMethod:bRetType := 29

uRetValue := SELF:oAuto:__Invoke(oMethod, DWORD(_BP+16),PCount())

RETURN (uRetValue)


When building every block like this receives ERROR XS9010 (The function 'PCount' is only supported in functions or methods with CLIPPER calling convention (and not in ACCESS or ASSIGN methods) concerning the following line:

>>uRetValue := SELF:oAuto:__Invoke(oMethod, DWORD(_BP+16),PCount())

Is there something we have to do? Is there something to be addressed in VO Xporter Tool?

This will not work the same way in .Net unfortunately. This is why I suggested you to read the "migrating VO to X#" section in the help file, examples 4 and 5 give information on what to do with OLE libraries and controls. Please give them and read, also better follow the insturctions in practice for the specific samples mentioned, so you have a hands-on experience on how to deal with that. Then please ask for more info/instructions if needed, also please mention which OLE controls you are using in your VO apps.

hope this helps!

[robert]

I will let Robert reply about VO2ADO, but I think he will also have a X# version ready soon.

I have an internal version working. Will be released when X# is released.

Robert

[Stavros Spanos]

Robert & Chris thank for the immediate reply!

In general our Classes are being maintained day - by - day for hundreds of customers, so the transition (when done) must be accurate and final. Meanwhile we understand that we will try several times so we will be sure for the stabillity of the released product. Otherwise - as you can understand - we will have to support duplicate coding...

And yes Chris unfortunatelly we have 50+ different and complicated OCX controls (DBI, Codejock, Pegasus Imaging, ZIP, FTP, Http, etc to name a few)

So by your answers I guess:

1./ Considering Roberts answer VO2ADO availability will be with the final product. Is there an estimation about it? No problem for us but I guess we'll have to wait till then for bBrowser/ReportPro/VO2ADO final versions - right?

2./ Concerning the path for the Icons - yes Chris you are right. We can work on the code but as we have a stopper waiting the final product then we can also wait for a possible solution. This is not a severe issue.

3./ Conserning the OCX's we'll read the papers you mention to see if we can find something. I assume that we'll have to regenerate classes of all of them in VS so that transfered business code can work - is that right?

TIA

Stavros

[Chris]

Hi Stavros,

1. I think that should be a few weeks from now

2. It's not the code that you'd need to change, just the resource definitions. Bt i am working on a fix for VOXporter, will send it to you as soon as it's ready to give it a test.

3. You can auto-generate the needed classes as the help file topics explains. But 50 OCXs...do you extensively use all of them? I assume for many of them there are already standard .Net libraries that do the same work, you may want to look into using those instead.

[Chris]

Stavro, please check your mail!

[Stavros Spanos]

Ha, ha, I checked the e-mail - fast as hell...

> I think that should be a few weeks from now

Good to hear, I thought it could be months. Then there's no problem to wait for the release version of X#, VO2ADO, bBrowser (will it be an X# one?), RPro 3. Robert if you think it would be ok , you could send us any beta VO2ADO to see how transition goes.

> It's not the code that you'd need to change, just the resource definitions. Bt i am working on a fix for VOXporter, will send it to you as soon as it's ready to give it a test.

Allready got it...

> You can auto-generate the needed classes as the help file topics explains. But 50 OCXs...do you extensively use all of them? I assume for many of them there are already standard .Net libraries that do the same work, you may want to look into using those instead.[/quote]

Unfortunatelly these have to work when we upgrade and after working in a stable X#-only project we would consider replacing them with any .NET libs. Some of them (like CJ or DBI) are complete suits of various activex's that have to do with UI etc. We'll read the sample and keep posting here how things are going.

Thanks for all!

[Chris]

You are welcome! Yes, it will be X# versions of all the tools.