Your safe journey from VB 6 to REALbasic
VB Convert! Usage FAQ [Updated 28 July 2008]
Before purchasing and using VB Convert!:
BEFORE You Convert Your VB 6 Project
Please read this section carefully BEFORE you attempt to convert your VB 6 project!
Use 'Option Explicit'
While inside the VB 6 IDE, it is strongly recommended that you clean up your code by using 'Option Explicit' in the Declarations section of each VB 6 Form, Module and Class you use, then attempt to run or compile your project within VB 6. This will will force you to declare each and every variable in your code.
Unfortunately, VB 6 enables programmers to develop bad coding habits, and one of those bad habits is when implicit variable declaration is used. REALbasic requires explicit declaration of variables, so sorting all of that out in VB 6 before converting is a better bet. While VB Convert! Pro has the option to automatically add most declarations missing from your code, it's still good coding practice to explicitly declare variables. This will make cleanup after the conversion much easier in RB and will actually make your app run more efficiently in VB 6 while you're still using it.
Trust me, I know this can be a pain if you have a big project. I personally had to type thousands of missing variable declarations in my large VB 6 project before attempting a VB 6 to RB conversion, but in the end, it's worth it.
Line Numbers Cause Inaccuracies
Using line-numbers in your VB 6 code is NOT recommended. REALbasic does NOT support line-numbers at all. If you use line-numbers, your project will be converted, but your converted project's accuracy may suffer and you'll have to manually convert any GoTo statements. It is recommended you remove or comment out line numbers and use more structured coding in VB 6 before you convert.
Multiple Statements on One Line Using Colons Should Be Separated
Multiple statements on one line using colons, i.e...
Code:
If True Then A = 0 Else B = 0: C = 1: G = 2: GoTo Jimmy
...is not
recommended. Your project will be converted, and the converter
will do its best to separate each statement on its own line, but
separating such multi-statement lines in VB 6 before conversion is strongly
encouraged.
'GoSub'...'Return' Is NOT Supported in REALbasic
Eliminate any 'GoSub...Return' code in your VB 6 project and replace with more structured code. 'GoSub...Return' simply is NOT supported at all in REALbasic.
API Declares
If you use Win32 API declares: 1) You cannot pass arrays to API declares in REALbasic and 2) The 'As Any' data-type is not allowed in REALbasic. You'll need to fix these issues before converting.
User Data-Types
VB 6 user data types will be converted to REALbasic Structures. You need to make sure any UDT string elements specify their length, such as: strString As String * 255 otherwise you'll get an error in REALbasic after conversion.
Child Controls Should Not Be Larger Than Their Parent Controls
REALbasic can be very picky about how child controls are placed on their parent controls. Say you have a StaticText (Label) that is inside a GroupBox (Frame) and this StaticText is a little bit wider or taller than the GroupBox. This can trip up REALbasic and cause the Label/StaticText to be placed on the wrong parent. Always make sure you adjust all child controls in Visual Basic so they are NEVER wider or taller than their parent controls, and that they are always positioned completely inside their parent control.
Control Names with Underscores (_)
You may want to change any VB 6 control names with underscores in them. If you have a control, for example, named 'UserTextEntry_Box', you may want to change it to 'UserTextEntryBox' instead. Underscores sometimes cause problems both with VB Convert! as well as REALbasic.
Overlapping or 'Stacked' Controls
If you use controls that overlap or sit directly on top of each other (such as multiple GroupBoxes (Frames)), this may cause a problem in REALbasic. REALbasic may have difficulty figuring out which child controls belong to which parent control and you'll have a big mess. Try to redesign your forms so they use Tabs or similar controls so that you do not have overlapping or stacked container controls.
Shapes and Lines
Many VB 6 users have forms that use Shapes and Lines to offer the end-user a more pleasing or organized experience. According to REAL Software, Line, Oval, Rectangle, and RoundRectangle are deprecated and will be substituted with a canvas control in future releases of REALbasic. VB 6 Shapes and Lines are converted to these RB controls, so you may wish to redesign your forms to minimize or eliminate Shapes and Lines altogether. If you choose to leave Shapes in your VB 6 project, keep in mind that Oval, Rectangle and RoundRectangle are not currently capable of having a transparent background.
VB 6 - RB Naming Conflicts
If any of your VB6 subs, functions or controls are named 'ISA' or 'IsA', you'll need to change the name (and all references to it) to something else. REALbasic has a function named 'IsA' and this will cause you problems. RB has many other methods and operators that may conflict with VB 6 names. While VB Convert! will usually rename things to avoid conflicts, it sometimes cannot catch every single instance of this. You may want to run through RB's Language Reference or the index in the User Guide to make sure you don't have other methods or functions that may conflict with existing RB ones.
VB 6 Control - RB Class-name Conflicts
VB 6 controls that have the same name as REALbasic classes may cause problems in RB after conversion. For example, if you have a VB 6 toolbar named 'Toolbar', this will conflict with the Toolbar class in RB. In this case, just change it to 'Toolbar1', 'vbToolbar' or something similar. This applies to all controls, so carefully check your VB 6 project for similar conflicts. Going through the REALbasic Language Reference will help you identify existing class names.
Backing Up VB 6 Files Before Conversion
Back up all of your VB 6 files BEFORE you convert them. While VB Convert! is non-destructive, you never know what Windows or the RB framework will accidentally do. Play it safe...back up your files beforehand. By using VB Convert!, you agree not to hold us responsible for any damage done to your VB 6 project files.
Don't Forget About The 'Conversion Options' Panel
Remember that VB Convert! has an options panel where you can change the way VB Convert! converts your VB 6 project. After selecting the VB 6 file to convert, click on the 'View / Change conversion options' link toward the bottom of the window BEFORE you click the 'Begin Conversion' button. The 'Conversion Options' panel appears automatically after selecting a project in VB Convert! Pro.
Non-Converting Controls [ Pro-only ]
VB Convert! Pro will perform a pre-scan of your project before it proceeds with the actual conversion. During this time, if VB Convert! Pro finds any non-native controls that normally wouldn't be converted, the conversion process will pause and a list will appear containing the non-native control classes. You can then click on the class name in the list and choose from a list of native or third-party controls to substitute with. (See image below for preview)
Post-conversion questions:
Q. What should I do right after the conversion is complete?
Q. When I open my converted project in REALbasic, there are errors and my project won't compile. What's happening?
A. Unless your VB 6 project was extremely simple, most converted projects need cleanup work before they will compile in REALbasic. Set your options to display multiple build errors, then you should do a 'Check Project for Errors' right after you save your converted project to the '.rbp' project format to see everything that needs work. While the converter does convert as much as possible, there are just some VB 6 concepts that won't convert over without a little extra help from you. This is not so much a fault of the converter, it's just the big differences that a converter just can't do.
Q. When I check my project for errors or attempt to compile, I get failed assertions or REALbasic just disappears. Why?
A. Some unconverted code can and will trip up REALbasic when you try to debug, compile or check the project for errors. If you think VB Convert! messed up or didn't convert your code correctly, post a message on the forums with as much detail as possible. At any rate, the majority of the blame lies on RB because REALbasic needs to fail more gracefully, regardless of what quality of code your project has. Try to find the offending code in your converted project and file a feedback report with REAL so that they can fix this problem in RB. If you have a hard time finding the offending code, look for problems with menu-bars, duplicate window or control events (such as two or more window Open events in the same window) or methods with incomplete or invalid parameters. Remember, RB requires that you fully declare every parameter, and don't forget the type, such as "As Integer" or "As Boolean".
Q. When I go to select, move or edit controls that are within a tab panel, groupbox or other container control, I can't select them. When I move the container control, only a few of the child controls move with it and the rest stay behind. Why is this happening?
A. VB 6 and REALbasic have very different concepts about control order and the 'z-level' of controls. Because they are so different, REALbasic sometimes assumes things about the parent-child relationships of controls, and sometimes it assumes incorrectly. When RB does get it wrong, child controls can't be selected because they end up 'behind' or 'below' the parent control. When this happens, you need to select the parent control, and usually keep clicking the 'Backward' or 'Back' buttons
until
the children controls can be selected individually and they are
'claimed' by their parent control. Correct use of these
buttons, as well as the 'Forward' and 'Front' buttons, can get a
container control to properly 'claim' its children controls.
Q. Why does the converter leave non-compatible VB 6 statements that can't be converted un-commented, wouldn't it be better to comment this stuff out so I have less errors?
A. The converter leaves these non-compatible statements uncommented so you can find them and fix them. If these statements were commented out, they wouldn't show up on a project error-check or build-error list and this could introduce unwanted or unpredictable behavior when your converted project is being debugged or run. Because these statements weren't converted, it's probably because there's no RB equivalent, so you'll have to do a bit of manual conversion or redesign.
Q. When I'm checking my project for errors, fixing the errors then rechecking, why does the number of errors sometimes jump higher instead of getting lower?
A. I don't have a solid answer for this question, but I'm guessing this happens because some errors prevent the error checker from 'seeing' other errors. When you fix some errors, this allows the error checker to parse other parts of your code and there may be a lot more errors there. This is my best guess, but you should contact REAL for the definitive answer.
Q. When I open my converted project in Linux or Mac OS X, controls and the layout of my forms don't look right. Why?
A. Keep in mind that controls often look much different on different operating systems. A good example is the TabPanel. In Windows and Linux, the TabPanel usually looks fairly normal, and the tabs usually wrap when you have many tabs. On OS X, however, if you have many tabs, they don't wrap and the converted TabPanel looks much too wide. This is NOT an issue with VB Convert!, it is simply a situation where OS X's TabPanel cannot handle so many tabs. The same issue may be apparent for other controls, as well. Each operating system has different default fonts, so some StaticTexts may overflow or look incorrect, PopupMenu or ListBox items may be too long for the control, etc. While cross-platform development is a big advantage with REALbasic, getting everything to look good on all three platforms often requires much work and frequent testing.
Q. I use a lot of toolbars in my VB 6 project and have them at different positions on my form. After converting, my toolbars don't seem to be in the right spot, are on the wrong TabPanel and look wrong when I run my app. ¿Porqué?
A. From how it appears, Toolbars in REALbasic (version 2007r4) can only be displayed at the very top of the parent window, unlike VB 6 where you can put them anywhere. I have seen users put toolbars on TabPanels and other container-type controls in VB 6 and after conversion and running in RB, the toolbars actually display at the top of those controls, but it usually displays incorrectly, and there is still a space left open at the top of the window for the toolbar. This issue is more prevalent in VB Convert! Pro because Pro converts VB 6 Toolbars to native RB toolbars, where in VB Convert! Standard, VB 6 Toolbars are converted to a non-native facsimile which can be placed anywhere on the window. This is due to the fact that at the time VB Convert! Standard was first designed, Toolbars in REALbasic were a new feature and were not yet stable.
Q. When I look at my forms/windows after converting, a lot of the controls are black and things aren't in the right color. What's up with that?
A. Due to some quirks with REALbasic parsing the .rbvcp file, controls do get converted with the right color, but aren't displayed properly right after conversion. What you need to do (as mentioned in the section above) is save the converted project as a .rbp file, close the converted project, then open the .rbp file you just saved. (Be sure to change the .rbvcp extension to .rbp when saving as a .rbp file...the Save As...dialog doesn't do this automatically). When you open the .rbp file, your controls should look close to how they did in VB 6. ALSO understand that RB may still not display everything in the custom color until you actually run or compile your project. (Some of these color issues have been resolved in VB Convert! Pro after some workarounds were developed for RB's quirky parsing of RBVCP projects)
Q. Some of the controls in my converted project are in the wrong place on the window. Why?
A. In 90 percent cases where your controls aren't showing up in the right position it's because REALbasic isn't parsing the RBVCP project correctly. The other 10 percent is due to vast differences between VB 6 and REALbasic that make exact placement difficult if not impossible. As mentioned earlier, opening your converted project in REALbasic 2007r1 is highly recommended, simply because 2007r2 and higher seem to have issues parsing RBVCP projects. If your project does not have complex window layouts, as of this writing, 2007r4 is the last recent RB version that seems to parse converted projects decently.
Q. I have images in my VB 6 project that used the Stretch property, but they don't appear stretched after conversion. Why is this?
A. If your images had their 'Stretched' property enabled in VB 6, VB Convert! will add code to their Paint events in REALbasic, so at runtime they will appear stretched. They will NOT appear stretched during design-time in REALbasic, however. NOTE: If you choose the 'Convert forms only, don't transfer or convert code' conversion option, this stretching code will NOT be automatically added; it will need to be added by you manually.
Q. When I open my project and look at some of the converted windows, I see a lot of controls that appear to be doubled or blurry. Explain!
A. If some of your controls look doubled or blurry (as seen in the image below), it's due to a bug in REALbasic and is usually NOT a problem with VB Convert! This usually happens with controls inside of GroupBoxes, though it can happen in TabPanels and other places. If it bothers you a lot, you can select all controls, then move them up or down one pixel (with the up or down arrow keys on the keyboard) and the doubling will be fixed...temporarily. Newer versions of REALbasic might have already fixed this, but it's still an issue with 2007r4. (The image below actually is NOT from a converted project but from a fresh, start-from-scratch RB project...showing that it's not just a VB Convert! issue)
Q. Why do I keep getting "There are several items with this name and its not clear which one the call refers to" when checking my project for errors?
A. This error comes up if there is more than one method with the same name but with different parameter signatures. Unlike VB 6, REALbasic allows you to 'overload' methods, so, for example, you could make a special version of the built-in Val method that does something the built-in one doesn't do. As long as each one of these overloaded methods has different parameter signatures, there shouldn't be too much trouble. If you had two overloaded methods and they have somewhat similar parameter signatures, you may get the 'several items' error. So if you had made a special Val function that accepts the Currency datatype, and then made another that accepts the Double datatype, this may be too confusing to RB, and it then throws this error. Another situation where this happens is if you're using a database field as a parameter for a method. VB 6 database fields usually all end with '.Value'. Just by glancing at it quickly we don't know what datatype the database field is, but VB 6 figures it out automatically. REALbasic, on the other hand, needs to have its hand held (constantly), so you'll need to figure out what data-type the database field is and use one of the specific database field types, such as '.StringValue', '.BooleanValue', '.IntegerValue', etc.
Q. I have a lot of database code in my VB 6 project, but REALbasic doesn't appear to have the 'AddNew' method. What can I do?
A. Yes, one of the unfortunate things about REALbasic is the missing AddNew method for RecordSets. There is another way, however. REALbasic provides us with the DatabaseRecord class. Let me explain it with code:
In the following code, assume 'db' is a Database, 'rs' is a RecordSet and the table we're working with is called 'Names'.
Again, the DatabaseRecord class is not as easy to use as AddNew, but it's not that hard. VB Convert! can actually convert AddNew blocks into DatabaseRecord blocks, but it doesn't do this automatically. You must select the 'Substitute
'DatabaseRecord' code to replace VB 6 'AddNew' ' checkbox.
Also, since VB Convert! Standard can't readily determine what
database or table you're working with, it will put a place-holder in
the database and table names within the InsertRecord method.
You'll have to use search/replace to put the right values there.
Q. What's this "You must use the value returned by this function" I keep seeing?
A. VB 6 didn't force us to do a lot of sensible things, and forcing us to use the returned value of functions was one of them. As you know, functions return values, even if the value is zero or Nil. In REALbasic, you must put the Call statement in front of a function if you don't care about the returned value, otherwise, you can just set up a global variable to 'use' the function's returned value. So, if one line of your VB 6 code was like this: MySpiffyFunction(a, b) ... you must now do this: Call MySpiffyFunction(a, b) or create a variable to handle the returned value like this: intReturn = MySpiffyFunction(a, b). Note that VB Convert! Pro will fix most of these non-used return value issues automatically.
Q. In VB 6, I could add or subtract from Dates, but that same code doesn't work in REALbasic. Why not?
A. In VB 6, a Date could be used for addition or subtraction, such as:
Q. Does the converter support VBG (group) files?
A. Not currently, though this is planned for an upcoming version
Q. My VB 6 project uses one or more StatusBars. After conversion, they don't look right in my RB project. Why?
A. As of version 2007r4, REALbasic does not have a native StatusBar control. VB Convert! Standard will not attempt to convert StatusBars at all, while VB Convert! Pro creates a non-native facsimile of your StatusBar. If this facsimile does not meet your needs, there are alternatives available from third-party RB control makers.
Q. Does the converter support projects with data environments?
A. Nope, not currently. This feature is also planned for an upcoming version. If you are trying to convert a project that has a data environment, it may convert okay, but the data environment will obviously not convert as there's no direct REALbasic equivalent.
Before purchasing and using VB Convert!:
- The
converter is just a tool, not some complex
artificial-intelligence package that will completely transform your VB
6-specific code into beautiful REALbasic code. You'll be hard-pressed
to find a converter that will generate a 100 percent perfect converted
project. There's always going to be some cleanup work necessary. Bottom
line, don't ask for a refund because there are unconverted items or
errors due to incompatibilities in your converted project...these are
normal with more complex VB 6 projects and don't necessarily indicate a
problem with VB Convert!
- Remember
the computer adage of days gone by: GIGO - Garbage In,
Garbage Out. If your VB 6 code is not 'clean', or you have completely
incompatible code such as 'GoSub...Return', your converted project is
not
going to run without some re-engineering. See the 'BEFORE
You Convert Your VB 6 Project' section below.
- It would
be very rare to find a software product that is 100
percent perfect and bug-free. While I strive to produce a quality
converter, I only have a limited amount of time and resources and very few reliable beta-testers.
The more feedback you provide, the better the converter can be.
- Remember, the converter is not capable of converting EVERYTHING,
simply because there are some VB 6 concepts that don't convert over
directly to REALbasic. Because of this, your converted project may have
quite a few lines of incompatible code, and this can trip RB up. While
I will fix and correct any converter bugs you bring to my attention,
REALbasic needs to be fixed, as well. Just because some of your source
code might be bad or incompatible is no excuse for REALbasic to crash
or disappear while working with it. Please take any problems you have
with REALbasic up with REAL Software. RB crashing because of bad source
code means that RB has weaknesses. If RB parses incorrect code, it
shouldn't crash RB, instead, it should fail gracefully.
- All feedback regarding the converter must be posted on the VB Convert! forums! E-mailing or IMing me with bug reports without prior arrangement will end up getting your bug report lost, stolen or mutilated. Just keep it on the forums.
BEFORE You Convert Your VB 6 Project
Please read this section carefully BEFORE you attempt to convert your VB 6 project!
Use 'Option Explicit'
While inside the VB 6 IDE, it is strongly recommended that you clean up your code by using 'Option Explicit' in the Declarations section of each VB 6 Form, Module and Class you use, then attempt to run or compile your project within VB 6. This will will force you to declare each and every variable in your code.
Unfortunately, VB 6 enables programmers to develop bad coding habits, and one of those bad habits is when implicit variable declaration is used. REALbasic requires explicit declaration of variables, so sorting all of that out in VB 6 before converting is a better bet. While VB Convert! Pro has the option to automatically add most declarations missing from your code, it's still good coding practice to explicitly declare variables. This will make cleanup after the conversion much easier in RB and will actually make your app run more efficiently in VB 6 while you're still using it.
Trust me, I know this can be a pain if you have a big project. I personally had to type thousands of missing variable declarations in my large VB 6 project before attempting a VB 6 to RB conversion, but in the end, it's worth it.
Line Numbers Cause Inaccuracies
Using line-numbers in your VB 6 code is NOT recommended. REALbasic does NOT support line-numbers at all. If you use line-numbers, your project will be converted, but your converted project's accuracy may suffer and you'll have to manually convert any GoTo statements. It is recommended you remove or comment out line numbers and use more structured coding in VB 6 before you convert.
Multiple Statements on One Line Using Colons Should Be Separated
Multiple statements on one line using colons, i.e...
Code:
If True Then A = 0 Else B = 0: C = 1: G = 2: GoTo Jimmy
'GoSub'...'Return' Is NOT Supported in REALbasic
Eliminate any 'GoSub...Return' code in your VB 6 project and replace with more structured code. 'GoSub...Return' simply is NOT supported at all in REALbasic.
API Declares
If you use Win32 API declares: 1) You cannot pass arrays to API declares in REALbasic and 2) The 'As Any' data-type is not allowed in REALbasic. You'll need to fix these issues before converting.
User Data-Types
VB 6 user data types will be converted to REALbasic Structures. You need to make sure any UDT string elements specify their length, such as: strString As String * 255 otherwise you'll get an error in REALbasic after conversion.
Child Controls Should Not Be Larger Than Their Parent Controls
REALbasic can be very picky about how child controls are placed on their parent controls. Say you have a StaticText (Label) that is inside a GroupBox (Frame) and this StaticText is a little bit wider or taller than the GroupBox. This can trip up REALbasic and cause the Label/StaticText to be placed on the wrong parent. Always make sure you adjust all child controls in Visual Basic so they are NEVER wider or taller than their parent controls, and that they are always positioned completely inside their parent control.
Control Names with Underscores (_)
You may want to change any VB 6 control names with underscores in them. If you have a control, for example, named 'UserTextEntry_Box', you may want to change it to 'UserTextEntryBox' instead. Underscores sometimes cause problems both with VB Convert! as well as REALbasic.
Overlapping or 'Stacked' Controls
If you use controls that overlap or sit directly on top of each other (such as multiple GroupBoxes (Frames)), this may cause a problem in REALbasic. REALbasic may have difficulty figuring out which child controls belong to which parent control and you'll have a big mess. Try to redesign your forms so they use Tabs or similar controls so that you do not have overlapping or stacked container controls.
Shapes and Lines
Many VB 6 users have forms that use Shapes and Lines to offer the end-user a more pleasing or organized experience. According to REAL Software, Line, Oval, Rectangle, and RoundRectangle are deprecated and will be substituted with a canvas control in future releases of REALbasic. VB 6 Shapes and Lines are converted to these RB controls, so you may wish to redesign your forms to minimize or eliminate Shapes and Lines altogether. If you choose to leave Shapes in your VB 6 project, keep in mind that Oval, Rectangle and RoundRectangle are not currently capable of having a transparent background.
VB 6 - RB Naming Conflicts
If any of your VB6 subs, functions or controls are named 'ISA' or 'IsA', you'll need to change the name (and all references to it) to something else. REALbasic has a function named 'IsA' and this will cause you problems. RB has many other methods and operators that may conflict with VB 6 names. While VB Convert! will usually rename things to avoid conflicts, it sometimes cannot catch every single instance of this. You may want to run through RB's Language Reference or the index in the User Guide to make sure you don't have other methods or functions that may conflict with existing RB ones.
VB 6 Control - RB Class-name Conflicts
VB 6 controls that have the same name as REALbasic classes may cause problems in RB after conversion. For example, if you have a VB 6 toolbar named 'Toolbar', this will conflict with the Toolbar class in RB. In this case, just change it to 'Toolbar1', 'vbToolbar' or something similar. This applies to all controls, so carefully check your VB 6 project for similar conflicts. Going through the REALbasic Language Reference will help you identify existing class names.
Backing Up VB 6 Files Before Conversion
Back up all of your VB 6 files BEFORE you convert them. While VB Convert! is non-destructive, you never know what Windows or the RB framework will accidentally do. Play it safe...back up your files beforehand. By using VB Convert!, you agree not to hold us responsible for any damage done to your VB 6 project files.
Don't Forget About The 'Conversion Options' Panel
Remember that VB Convert! has an options panel where you can change the way VB Convert! converts your VB 6 project. After selecting the VB 6 file to convert, click on the 'View / Change conversion options' link toward the bottom of the window BEFORE you click the 'Begin Conversion' button. The 'Conversion Options' panel appears automatically after selecting a project in VB Convert! Pro.
Non-Converting Controls [ Pro-only ]
VB Convert! Pro will perform a pre-scan of your project before it proceeds with the actual conversion. During this time, if VB Convert! Pro finds any non-native controls that normally wouldn't be converted, the conversion process will pause and a list will appear containing the non-native control classes. You can then click on the class name in the list and choose from a list of native or third-party controls to substitute with. (See image below for preview)
Post-conversion questions:
Q. What should I do right after the conversion is complete?
- Exit VB Convert!
- Open the
converted project by clicking on the .rbvcp file within
the conversion folder. On Linux or Mac OS X, you may have to use 'Open with...' > 'REALbasic' when attempting to open .rbvcp files.
(Keep in mind, if your VB 6 project was a medium or larger-sized project, it may take a long time for REALbasic to parse the converted project depending on the speed of your computer. Be patient. Because REALbasic 2007r1 and older do not have a load progress indicator, you just have to wait until the project finally appears after loading. Newer versions of RB have load progress indicators, but RB often goes unresponsive and 'whites out' during the load, so this load progress bar often is of little use.)
- Once
your
project appears, and before doing anything else, save
the project in the '.rbp' project format, using 'File' > 'Save
as...', close your converted project, then open the .rbp file you just
saved.
WARNING! Before you perform the 'Save As...', be sure to rename the extension from .rbvcp to .rbp when you save the project the first time, otherwise, you'll over-write the original converted project and your project's extension will not be consistent with its contents. This is an issue with REALbasic, NOT VB Convert!.
- In REALbasic, go to:
'Edit' > 'Options' > 'Build Process' and make
sure the 'Show multiple compile errors' check box is checked.
- In REALbasic, go to:
'Project' > 'Check project for errors' or 'Analyze Project' to start an
error-check of your project.
Sometimes you may get failed assertion and other compiler errors during this time (I'm not talking about the errors that display on the error list). While the cause of these errors is mostly unconverted VB 6 code tripping up the error-checker, REALbasic is showing its flaws here and not failing gracefully. Don't blame me. Write down the error messages you see during this phase and submit a feedback report on their system. If you find that REALbasic crashes, freezes or just plain disappears during this error check, please send me your project and I will see what could be causing the problem.
- If you
finally do get to the error list after your whole project has
been checked, start going through the errors.
- You will see plenty of unconverted VB 6 code
if you use a lot of
features that won't convert directly to REALbasic, such as generic file
I/O
'Close' statements, array Erase methods or the AddNew method of ADO
recordsets. There are plenty of things that don't have an RB
counterpart that you will have to code yourself, or find in projects
such as Aaron Ballman's Windows Functionality Suite (WFS).
Remember!...If
you are planning on using your newly converted project
on Linux or Mac OS X, the majority of the WFS, as well as other Win32
API
calls aren't going to work on those non-Windows platforms. You'll
either have to
create platform-specific API calls using #If..#EndIf, #If Targetplatform or just
don't use them at all.
Q. When I open my converted project in REALbasic, there are errors and my project won't compile. What's happening?
A. Unless your VB 6 project was extremely simple, most converted projects need cleanup work before they will compile in REALbasic. Set your options to display multiple build errors, then you should do a 'Check Project for Errors' right after you save your converted project to the '.rbp' project format to see everything that needs work. While the converter does convert as much as possible, there are just some VB 6 concepts that won't convert over without a little extra help from you. This is not so much a fault of the converter, it's just the big differences that a converter just can't do.
Q. When I check my project for errors or attempt to compile, I get failed assertions or REALbasic just disappears. Why?
A. Some unconverted code can and will trip up REALbasic when you try to debug, compile or check the project for errors. If you think VB Convert! messed up or didn't convert your code correctly, post a message on the forums with as much detail as possible. At any rate, the majority of the blame lies on RB because REALbasic needs to fail more gracefully, regardless of what quality of code your project has. Try to find the offending code in your converted project and file a feedback report with REAL so that they can fix this problem in RB. If you have a hard time finding the offending code, look for problems with menu-bars, duplicate window or control events (such as two or more window Open events in the same window) or methods with incomplete or invalid parameters. Remember, RB requires that you fully declare every parameter, and don't forget the type, such as "As Integer" or "As Boolean".
Q. When I go to select, move or edit controls that are within a tab panel, groupbox or other container control, I can't select them. When I move the container control, only a few of the child controls move with it and the rest stay behind. Why is this happening?
A. VB 6 and REALbasic have very different concepts about control order and the 'z-level' of controls. Because they are so different, REALbasic sometimes assumes things about the parent-child relationships of controls, and sometimes it assumes incorrectly. When RB does get it wrong, child controls can't be selected because they end up 'behind' or 'below' the parent control. When this happens, you need to select the parent control, and usually keep clicking the 'Backward' or 'Back' buttons
until
the children controls can be selected individually and they are
'claimed' by their parent control. Correct use of these
buttons, as well as the 'Forward' and 'Front' buttons, can get a
container control to properly 'claim' its children controls.Q. Why does the converter leave non-compatible VB 6 statements that can't be converted un-commented, wouldn't it be better to comment this stuff out so I have less errors?
A. The converter leaves these non-compatible statements uncommented so you can find them and fix them. If these statements were commented out, they wouldn't show up on a project error-check or build-error list and this could introduce unwanted or unpredictable behavior when your converted project is being debugged or run. Because these statements weren't converted, it's probably because there's no RB equivalent, so you'll have to do a bit of manual conversion or redesign.
Q. When I'm checking my project for errors, fixing the errors then rechecking, why does the number of errors sometimes jump higher instead of getting lower?
A. I don't have a solid answer for this question, but I'm guessing this happens because some errors prevent the error checker from 'seeing' other errors. When you fix some errors, this allows the error checker to parse other parts of your code and there may be a lot more errors there. This is my best guess, but you should contact REAL for the definitive answer.
Q. When I open my converted project in Linux or Mac OS X, controls and the layout of my forms don't look right. Why?
A. Keep in mind that controls often look much different on different operating systems. A good example is the TabPanel. In Windows and Linux, the TabPanel usually looks fairly normal, and the tabs usually wrap when you have many tabs. On OS X, however, if you have many tabs, they don't wrap and the converted TabPanel looks much too wide. This is NOT an issue with VB Convert!, it is simply a situation where OS X's TabPanel cannot handle so many tabs. The same issue may be apparent for other controls, as well. Each operating system has different default fonts, so some StaticTexts may overflow or look incorrect, PopupMenu or ListBox items may be too long for the control, etc. While cross-platform development is a big advantage with REALbasic, getting everything to look good on all three platforms often requires much work and frequent testing.
Q. I use a lot of toolbars in my VB 6 project and have them at different positions on my form. After converting, my toolbars don't seem to be in the right spot, are on the wrong TabPanel and look wrong when I run my app. ¿Porqué?
A. From how it appears, Toolbars in REALbasic (version 2007r4) can only be displayed at the very top of the parent window, unlike VB 6 where you can put them anywhere. I have seen users put toolbars on TabPanels and other container-type controls in VB 6 and after conversion and running in RB, the toolbars actually display at the top of those controls, but it usually displays incorrectly, and there is still a space left open at the top of the window for the toolbar. This issue is more prevalent in VB Convert! Pro because Pro converts VB 6 Toolbars to native RB toolbars, where in VB Convert! Standard, VB 6 Toolbars are converted to a non-native facsimile which can be placed anywhere on the window. This is due to the fact that at the time VB Convert! Standard was first designed, Toolbars in REALbasic were a new feature and were not yet stable.
Q. When I look at my forms/windows after converting, a lot of the controls are black and things aren't in the right color. What's up with that?
A. Due to some quirks with REALbasic parsing the .rbvcp file, controls do get converted with the right color, but aren't displayed properly right after conversion. What you need to do (as mentioned in the section above) is save the converted project as a .rbp file, close the converted project, then open the .rbp file you just saved. (Be sure to change the .rbvcp extension to .rbp when saving as a .rbp file...the Save As...dialog doesn't do this automatically). When you open the .rbp file, your controls should look close to how they did in VB 6. ALSO understand that RB may still not display everything in the custom color until you actually run or compile your project. (Some of these color issues have been resolved in VB Convert! Pro after some workarounds were developed for RB's quirky parsing of RBVCP projects)
 |
 |
| Colors missing right after conversion | Colors are there after saving as .rbp and re-opening |
Q. Some of the controls in my converted project are in the wrong place on the window. Why?
A. In 90 percent cases where your controls aren't showing up in the right position it's because REALbasic isn't parsing the RBVCP project correctly. The other 10 percent is due to vast differences between VB 6 and REALbasic that make exact placement difficult if not impossible. As mentioned earlier, opening your converted project in REALbasic 2007r1 is highly recommended, simply because 2007r2 and higher seem to have issues parsing RBVCP projects. If your project does not have complex window layouts, as of this writing, 2007r4 is the last recent RB version that seems to parse converted projects decently.
Q. I have images in my VB 6 project that used the Stretch property, but they don't appear stretched after conversion. Why is this?
A. If your images had their 'Stretched' property enabled in VB 6, VB Convert! will add code to their Paint events in REALbasic, so at runtime they will appear stretched. They will NOT appear stretched during design-time in REALbasic, however. NOTE: If you choose the 'Convert forms only, don't transfer or convert code' conversion option, this stretching code will NOT be automatically added; it will need to be added by you manually.
Q. When I open my project and look at some of the converted windows, I see a lot of controls that appear to be doubled or blurry. Explain!
A. If some of your controls look doubled or blurry (as seen in the image below), it's due to a bug in REALbasic and is usually NOT a problem with VB Convert! This usually happens with controls inside of GroupBoxes, though it can happen in TabPanels and other places. If it bothers you a lot, you can select all controls, then move them up or down one pixel (with the up or down arrow keys on the keyboard) and the doubling will be fixed...temporarily. Newer versions of REALbasic might have already fixed this, but it's still an issue with 2007r4. (The image below actually is NOT from a converted project but from a fresh, start-from-scratch RB project...showing that it's not just a VB Convert! issue)
Q. Why do I keep getting "There are several items with this name and its not clear which one the call refers to" when checking my project for errors?
A. This error comes up if there is more than one method with the same name but with different parameter signatures. Unlike VB 6, REALbasic allows you to 'overload' methods, so, for example, you could make a special version of the built-in Val method that does something the built-in one doesn't do. As long as each one of these overloaded methods has different parameter signatures, there shouldn't be too much trouble. If you had two overloaded methods and they have somewhat similar parameter signatures, you may get the 'several items' error. So if you had made a special Val function that accepts the Currency datatype, and then made another that accepts the Double datatype, this may be too confusing to RB, and it then throws this error. Another situation where this happens is if you're using a database field as a parameter for a method. VB 6 database fields usually all end with '.Value'. Just by glancing at it quickly we don't know what datatype the database field is, but VB 6 figures it out automatically. REALbasic, on the other hand, needs to have its hand held (constantly), so you'll need to figure out what data-type the database field is and use one of the specific database field types, such as '.StringValue', '.BooleanValue', '.IntegerValue', etc.
Q. I have a lot of database code in my VB 6 project, but REALbasic doesn't appear to have the 'AddNew' method. What can I do?
A. Yes, one of the unfortunate things about REALbasic is the missing AddNew method for RecordSets. There is another way, however. REALbasic provides us with the DatabaseRecord class. Let me explain it with code:
In the following code, assume 'db' is a Database, 'rs' is a RecordSet and the table we're working with is called 'Names'.
VB 6 code:
rs.AddNew
rs.Fields("ID").Value = intID
rs.Fields("Name") = "Johnson"
rs.Update
RB code (using DatabaseRecord):
Dim dr As New DatabaseRecord
dr.IntegerColumn("ID") = intID
dr.Column("Name") = "Johnson"
db.InsertRecord("Names", dr)
db.Commit
rs.AddNew
rs.Fields("ID").Value = intID
rs.Fields("Name") = "Johnson"
rs.Update
RB code (using DatabaseRecord):
Dim dr As New DatabaseRecord
dr.IntegerColumn("ID") = intID
dr.Column("Name") = "Johnson"
db.InsertRecord("Names", dr)
db.Commit
Again, the DatabaseRecord class is not as easy to use as AddNew, but it's not that hard. VB Convert! can actually convert AddNew blocks into DatabaseRecord blocks, but it doesn't do this automatically. You must select the 'Substitute
'DatabaseRecord' code to replace VB 6 'AddNew' ' checkbox.
Also, since VB Convert! Standard can't readily determine what
database or table you're working with, it will put a place-holder in
the database and table names within the InsertRecord method.
You'll have to use search/replace to put the right values there.Q. What's this "You must use the value returned by this function" I keep seeing?
A. VB 6 didn't force us to do a lot of sensible things, and forcing us to use the returned value of functions was one of them. As you know, functions return values, even if the value is zero or Nil. In REALbasic, you must put the Call statement in front of a function if you don't care about the returned value, otherwise, you can just set up a global variable to 'use' the function's returned value. So, if one line of your VB 6 code was like this: MySpiffyFunction(a, b) ... you must now do this: Call MySpiffyFunction(a, b) or create a variable to handle the returned value like this: intReturn = MySpiffyFunction(a, b). Note that VB Convert! Pro will fix most of these non-used return value issues automatically.
Q. In VB 6, I could add or subtract from Dates, but that same code doesn't work in REALbasic. Why not?
A. In VB 6, a Date could be used for addition or subtraction, such as:
intDays =
Now - dtLastService
RB's Date is different. You must
use one of the RB Date's properties, such as TotalSeconds, to perform
such calculations. Also, when you create and instantiate a Date
object in REALbasic, its value is set to the current date and time, so
it's no longer necessary to use something like VB 6's Now function.Q. Does the converter support VBG (group) files?
A. Not currently, though this is planned for an upcoming version
Q. My VB 6 project uses one or more StatusBars. After conversion, they don't look right in my RB project. Why?
A. As of version 2007r4, REALbasic does not have a native StatusBar control. VB Convert! Standard will not attempt to convert StatusBars at all, while VB Convert! Pro creates a non-native facsimile of your StatusBar. If this facsimile does not meet your needs, there are alternatives available from third-party RB control makers.
Q. Does the converter support projects with data environments?
A. Nope, not currently. This feature is also planned for an upcoming version. If you are trying to convert a project that has a data environment, it may convert okay, but the data environment will obviously not convert as there's no direct REALbasic equivalent.
Last updated 28 July 2008
VB Convert! is not a product of REAL Software.
AYB Technical Services is in no way associated with REAL Software.