I figured as much, I think a human doing the conversion would obviously do a more thorough job.
Not only that, but when we do a conversion project we just include all the proper stuff to do it cross platform. VB6 probably does it the Windows way which might be okay on Mac and Linux but there are plenty of things that aren’t. I don’t think any conversion tool will get that part of it right - ever.
In one of my previous contracts we worked on a big VB6 project (accounting app - think QuickBooks but geared for a specific industry). The quotes we were getting to convert to .NET was $1 per line of code. The project at that time was 750,000 lines of code (not including comments). And on top of that they said it would take a year to do it.
These guys were the ‘experts’ in .NET and all they were doing was rewriting it. Some conversion took place I’m sure, but any UI and framework changes were being rewritten.
OOP isn’t a cult thinking (though some take it to the extreme). It’s the way Xojo works best. VB6 let you do a tiny portion because it just wasn’t good at it (or even possible). It’s a 20 year old language. I don’t proscribe that EVERYTHING needs to be an object but I’ve seen an awful lot of very complex VB6 code replaced with some simple Xojo classes that was extremely easy to understand afterwards.
If it works for you, that’s great, but Xojo OOP isn’t bad when done properly. It can make your life easier as a developer. VB6 didn’t so don’t judge Xojo by VB6 capabilities.
I started in RealBasic back in 2002 mainly to port to Mac a couple programs I was already selling for Windows. So in essence, as I could not write Mac apps in VB, I had to start directly in RealBasic without trying to convert the VB code.
Quickly, I discovered that in order to get the best, I had to think in RealBasic instead of trying to translate. It’s just like speaking a foreign language. You know you are fluent when you do not try to translate. If I had tried to convert my VB code, it would have held me back and been for sure a frustrating experience.
When the Mac app was complete, it was sleeker and more compact than the VB one. I generated a Windows version, and appreciated the fact that it worked right away. Since then, I have developed with it and am a fervent Xojo user.
Last year I needed to create Windows 8 Metro apps and went back to Visual Basic. It is indeed a foreign language. What I also found out was that Microsoft documentation is often cryptic, events are not as easy to use, and debugging is a lot less friendly.
I found that there is no VB place like this forum. MSDN forums are cold and mainly run by Microsoft engineers that mostly refer to documentation without the slightest effort to provide ideas or workaround. And other members could not care less about giving a hand. As for Stach Overflow, although one surely finds answers there, it is haunted by obnoxious anonymous snits who seem to thrive into abusing others.
By contrast, the Xojo forum has a tight community of competent and friendly users who range from amateurs to high end professionals. I have never seen one of my questions stay unanswered. It is not uncommon to see people go out of their way and offer complete sets of code to solve a problem submitted in the forum.
Many of us here started with VB and some still use both languages, or even other flavors such as Basic4Android. So you will find in this forum many examples of topics about ways of doing in Xojo what was done in other languages, including VB6 and .Net. Fact remains, the longer one uses Xojo, the less reference to VB is needed.
Finally, as OOP is mentioned, Xojo is built for it and makes it quite natural. But it is not as rigid as forbidding other approaches. At the risk of shocking extreme adepts of the OOP doctrine, let me just say that using global variables and even a unique procedural code chunk in the Open event with GOTO in it is even possible. Just like good old QuickBasic. Meaning Xojo is still open enough to be a free thinker 
[quote=80530:@Michel Bujardet]
Last year I needed to create Windows 8 Metro apps and went back to Visual Basic. It is indeed a foreign language. What I also found out was that Microsoft documentation is often cryptic, events are not as easy to use, and debugging is a lot less friendly. [/quote]
Yes! This is the reason I tried VB.NET and even VB2013 and immediately was put off by it. Everything was overly verbose, took forever, and was largely unfriendly when compared to Xojo or even VB6, and even if you manage to finish it, VB.Net apps required a very large .NET framework to be installed to really run right. It was NOT easy to use or efficient to get stuff done. Xojo is much less rigid in OOP stuff and getting going out of the gate, which was what led me to consider it as a replacement for dear ole’ VB6.
VB is dead - MS has stopped supporting it. So yes the programs will still run but that too may come to an end depending on what MS does with Windows down the road. VB.Net has “replaced” it as far as MS is concerned.
You don’t have a choice if you want to support new targets (web, mobile, cross platform).
The only certainty is that sticking with VB6 is 100% certain to make it impossible to support those and move to take advantage of any new opportunities they present.
So the question isn’t so much “should I move to something else” but “when and how should I do it”
[quote=80534:@Norman Palardy]VB is dead - MS has stopped supporting it. So yes the programs will still run but that too may come to an end depending on what MS does with Windows down the road. VB.Net has “replaced” it as far as MS is concerned.
[/quote]
Given that Xojo does not use .Net technology, is not the issue similar? Looking at the Cocoa transition, we know retooling the Xojo Windows framework is not something that could be done quickly if MS took a quick turn.
No
Apples and Toyotas comparison
MS would have to rip the Win32 API’s out of Windows to cause Xojo issues
MS doesn’t have to do quite that to break VB6 programs
They’d just need to break the VB runtime dll
http://msdn.microsoft.com/en-ca/vstudio/ms788708.aspx
MS has, in their usual style, committed to support VB6 (which was discontinued in 2008) until seemingly forever on Windows
But VB is not alive & well - its on life support until things just stop working some unspecified time in the future
It appears ms is moving back to win32, they will be releasing a version that will natively compile .net code. To me, they are admiting.net is not good enough for everyone.
So maybe i should not worry, but i will eventually move from vb6 when i have to, and xojo is definetly a option, just wish i could import my project, i would move today.
I respect xojo, i was just making a suggestion. I know there are obsticles to code conversion… But we did go to the moon, i think if someone smart enough tried they could do it.
Mechanically converting code from one language to another can be done - but converting the intent of the code can’t. Software has a hard time deducing intent. Nor does it take into account that things like DoEvents, while syntactically similar, or not semantically similar (you need it in VB and should avoid it in Xojo)
So yes someone could write a code converter & you’d probably hate the results & complain that "Xojo doesn’t
"
That’s not good for you or us
Hence why when this topic comes up (frequently) the advice is “don’t do this you’ll hate the results”
Its been that same advice for years
Seriously, we looked at it making a converter a number of years ago. As Norman said above, trying to determine the intent of the code is very hard to do. Sure, I can convert line by line into something that compiles in Xojo but it might be utterly worthless code, as in not needed, or worse yet, doing something very wrong in Xojo. There are just too many things that Xojo does better, or completely different, than VB6 to make any conversion app work well.
I’m going to go totally out of character here to try and correct this flawed notion. I believe I fall in the “smart enough” category, and I have tried and even knowing the original code and its intent and having the freedom to lean that direction (and not have to create a generic tool), it could not be done in a satisfying way. The rewrite was much, much better. I’m glad I swallowed my pride (it became a pet project) and gave up on the converter. It was some kick-■■■ code, but the results weren’t good enough.
One of my projects I am most proud of started in 1984 on an Acorn BBC-B computer, moved mid-ninetees to VB4 and VB6. Around 1998 it moved again to Visual FoxPro and in 2005 was converted to Xojo (RealBasic 5.5.2 at that time) and is still in use and in RealStudio code.
For a very long time, it was just a procedural written application. When i rewrote it in 2005 to RealBasic it was still a procedural application which was very poorly written despite it worked as expected for the end user.
It took me two years to learn and master OOP application development. When I see back in the past, I do not understand why I did not the Realbasic rewrite immediatelly in OOP.
Xojo is not made for procedural development, that is what I learned the hard way. Also OOP gives the advantage of using classes and objects directly from other projects. Create it once and use it many times in different projects. That is how I do it. My most important classes which are self contained, I place in a kind of library project which is not meant to work but to copy from.
What I want to say is that rewriting is much better than converting. Like others already have said, software cannot deduce the intent of the human programmer. You will learn a lot from rewriting your application and it will add to your programming in the future.
Xojodevspot.com has a library with lots of code and a neat builtin feature is VB6 to Xojo conversion
I have been thinking about making the vb6 to xojo converter open source for about a year now… but there arent too many developers around that would actively bring further life to it. Its quite efficient in handling code and even comments areas of “line by line incapable conversion” for easy xojo translation and suggests using say textinput/output stream in place of
open “filename” for input as #1
Line input #1, inputstring
close #1
Would be interesting to further work to make these conversions “automated”.
I am the owner of vbconvert; a collaboration of will brokenbourgh and myself some time ago before he left feeling realbasic was inadequate (tisk tisk)… That is the source I have been speaking of and have maintained to date.
Lets be clear matt - you can mechanically convert those three lines into something
Whether it would run in Xojo is another question
What you probably won’t get is the proper intent
For instance, that little 3 lines
-
Open “svi.nan” For Input As #1
not too hard as this maps to a folder item & open binary stream -
Close #1
close the binary stream -
Input #1, svn, mn, tb
are svn, mn, and tb locals ? globals ? properties on a module ? declared forward (in a module you have not parsed yet?)
what types are they ? you’ll need to know all that just to convert that one line even close to correctly to xojo code
So now you also need to build symbol tables and such to convert the code
And thats only one line that isn’t that complex for a person to deal with
Then there’s the whole On error handling
Or on error goto 0
This has virtually no equivalent
Or Lock & Unlock (which have no equivalent)
I wish you luck
Agreed, since it already converts most code and will comment with “cannot convert” and generates a conversion report, I suppose the only thing to add would be direct links to “close to” representation directly to documentation.xojo.com/whateverisclose since the Xojo ide I believe does handle links still (haven’t tried since Realbasic IDE). That way if a developer does choose to use the migration application, “reason” (for not converting some code) and “possible means to achieve the full conversion” are given…In the end they will ultimately need to leave “what they know about vb6” behind, to fully understand Xojo (better OOP handling in Xojo!). The more complex an application, the more probability for the conversion to be less accurate. This is true in foreign language translation as in any language. The true essence of what is being said in English cannot always be fully conveyed in another language; Not because English is ‘advanced’, rather confusing and a sleuth of many congealed languages to make one(complex). A VBMigration tool should be only a means to AID (an existing developer with a firm grip on programming in the former language) in migrating from VB to Xojo. Definitely not to “port” already established ‘works’ to Xojo. For quite a while this had been missed, where I’d thought about making a “cut and paste” translation boxes so a developer can see the vb6 and xojo code conversion side-by-side and see the commented out areas where conversion could not happen; thus adding links to Xojo docs in the conversion on the subject so the developer could “learn to fish.” Along the lines of. …
I could fish for you, but when I was gone you’d starve. But if I teach you to fish, you can feed yourself for a lifetime. Experience and understanding are the only two 100% successful conversion tools available.
I bought a license of the VBConvert when it was for sale several years ago. I wasn’t able to use any of the Converted Forms or UI code (the event model is just too different from VB6). But it did a decent enough job on the subs and functions in the core business code. That was a pretty big help at the time because I was getting started with RS and at that time it was easier to take the converted code and get it to work and then optimize the spots that didn’t work well. Now that I have been using RS/Xojo for about 4 years now, some of those functions I would probably just code up from scratch, if I was doing it now. But all in all, it was well worth the money I spent on the converter.
After Will left, development sort of fizzled (as I rarely used VB at that point) until i picked back up development of VBM (now VB to Xojo Converter) in 2011. But glad to hear it helped you out. The aim was never to be 100% efficient (impossibility) rather as you said to aid in the transition process and handle the bulk of the code migration. 
it was recently updated to handle the latest MBS & Einhuger plugins and latest graffitisuite.