Real Software Forums

Hello all!

For some reason, after performing the import sequence per the readme file, there is never any indication that the conversion is done - although the xml file is created. The converter does not start RS automatically and when I try to open the project (which is successful) there are none of the forms or objects that were in the original VB6 code presented.

What am I doing wrong?

Thank you!
Tim

I am getting the same problem. I hope someone is able to help in this ...

Same problem here.

I am using RS2010R5.1 on Windows 7 and the latest VB Migration Assistant.

Someone could make it work recently?

Actually, it seems to work with some projects. I have just downloaded a very simple one (http://www.visualbasic6class.com/combo.zip) and the migration assistant does a very good job.

However, it did not work at all on this project here:http://www.lvr.com/files/usbhidio2.zip

I could read the VB6 code directly from the source files of the USBHIDIO2 project and that's ok for for me right now, but I think it would be good to know why some projects do not migrate at all (I see no code, no window, nothing when I open the xml file the VBMA is creating in the RealBasic IDE).

Any ideas? Thank you.

Pixe

I would create a Feedback report along with the VB6 source (if you can) so the engineers can duplicate the issue. VBMA is a very lightweight tool and don't really convert much. It's almost easier, IMO, to start from scratch, and in fact do that with any conversion projects we get.

OK, I created the feedback case: 15358


Probably you are right.

I just wanted to look at the API calls and how they are used in that project to see if I can do the same in RB and I didn't want to install VB6 (which I have, but I would not like to use again) just to open the project. Finally I opened the vbp and bas files using a text editor, but although in that way I see the API calls it is more difficult to follow the sequence of code/events.

Pixe

Well, VBMA doesn't convert ANY code. It imports it and immediately comments it out. It attempts (with some accuracy) to put it in the proper events but even that's not foolproof.

It's been my experience that you will need SOME API calls but not many. And those that you do need will mostly likely be fairly common. I suggest taking a look at the Windows Functionality Suite at http://arbpmembers.org/windows-functionality-suite since it has the biggest collection of Windows declares that I know of.

As far as converting from VB6 to RB there are many similarities until you get into file I/O and database operations. Since those are generally important areas I'd highly recommend writing that code from scratch anyway and learn the RB way.

Impossible question, probably, but do you have any rules of thumb about how many man hours a conversion job will require?
I found the vbconvert! tool to be far better than the vbma but for anything other than trivial projects the time investment looks to be enormous.

You're right, it's an impossible question. When we look at conversions we look at the complexity of each window and class and make some guestimates based on that. We know that a simple window/class takes x hours, medium y hours and a complex one z hours. Add it all up and hope you didn't overlook something big.

VBConvert attempts to convert code and did a reasonable job (AFAIK it's no longer available for sale). But since you pretty much have to look at every line of code to make sure it works we found that it didn't help us all that much and in some cases made it harder. While VB and RB have 'basic' in the name, they are completely different beasts.

I've heard that the commercial VB6 to .NET conversion services can charge as much at $1 PER line of code. After doing conversions for years (to RB) it is a reasonable yard stick. Bottom line is that a big, hairy VB6 project will still be a big, hairy RB project.

Thanks Bob, I was interested to hear your take on migrating code



I dunno Bob, this suggests it might be cheaper to pay an hourly rate :





POI: the migration wizard in VB2008 is pretty good (and a big improvement over earlier incarnations), making that a far easier port than to RB.

Marketing-speak and reality often don't mix.

Since VBMA doesn't convert any code you're essentially rewriting it anyway. Where VBMA *might* save you some time is converting all the forms layouts over to RB Windows. But since most VB programs have 3rd party controls that don't match what RB has it's a crap shoot on how well those will convert anyway. As with anything technology related, YMMV.

I did manage to get hold of a copy of VBConvert!.

The biggest factor is that it does convert the forms layout very well, at least for the non-3rd-party controls. The labels wind up in the right positions on the RB forms.

The code conversion wasn't bad either. But, you do have to go over it line by line.

Another big time saver was the ability to include error handlers in each converted procedure/event.

Basically, you just start including the forms/modules one at a time. After checking/modifying and getting the project to run, you load the next form/module and repeat to the end of the project.

No matter the route, it does take a long time.

I think it's a shame that VBConvert is no longer for sale. It did some nice things and IMO does not really compete with VBMA.

I really don't know why REAL didn't buy it and provide it as a tool, as it far surpasses their own attempt.

The developer of vbconvert came across very well in the emails I had from him. He's also a very able programmer. I suspect he felt a bit undermined by REAL's decision to bring out their free vbma at the same time as he brought out his very reasonably priced ($65) product. It can't have helped his sales any.