Well, for the heck of it you could copy and paste the code and watch 1000's of errors appear LOL
Actually no, well I'm not quite sure of your circumstances, but the above is why porting and adapting is such a pain. In a perfect world, we could set our requirements, then design, then write code, then debug...
Seems like in the real workplace that process sometimes gets reversed, suddenly you find out that you need to write in a different language or for a different platform.
If at all possible, figure out what your requirements are first and then code your program in the language you intend to finish in.
Also of note is that managed C++ .NET code compiles into the same CLR as VB .NET, so maybe there is hope if you ported to C++ .NET. Honestly, I'm not familiar with how the communication between languages would work however.
It would probably be easier to create a new VB project and just reverse engineer the C++ code to make them preform the same...
You can grab small parts of the C/C++ code that is specific to your program, such as the main loop, and functions, and port those individualy...
But you do realize, that in a VC++ program, there are a lot of things that are not needed in a VB program, like all of the modules that build the form and tell it how to act...
VB controls that part for you, so all you have to do in VB is tell it what to do when an event occurs... VC++ also (more or less) does this, but the code for it is stored in the code with the event handlers...
If you really want to spend sometime...
I guess you could try to create a program to automate most of the changes, then debug the errors that are left from there...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.