Converting TrueGrid 2.1 to TrueDBGrid 5.0
Does anyone know if there is a utility to help convert from TrueGrid 2.1 to TrueDBGrid 5.0? Apex didn't write one, so it looks like it will be a manual process.
I'd be happy with a utility that just placed the new ocx grid in the same location as the vbx grid. It seems like this would have been possible using VB4-16 to load the vbx grids, and then convert them to the newer ocx control.
I'd be happy with a utility that just placed the new ocx grid in the same location as the vbx grid. It seems like this would have been possible using VB4-16 to load the vbx grids, and then convert them to the newer ocx control.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
By the way, control names always follow the "begin" keyword.
Unfortunately, for truegrid, this won't work. This is usually a good technique, but since the truegrid tool has changed a LOT since version 2.1, it is going to take a lot more work.
Truegrid 2.1 is about 5 versions behind v5.0. Truegrid 4.0 came with a utility that converted 2.x grid projects to 4.0. From there, 4.0 -> 5.0 is supposed to be easy (I dont have 5.0, but Apex says it will be easy)
Truegrid 2.1 is about 5 versions behind v5.0. Truegrid 4.0 came with a utility that converted 2.x grid projects to 4.0. From there, 4.0 -> 5.0 is supposed to be easy (I dont have 5.0, but Apex says it will be easy)
anthonyc, this will work, J_Schroeder states "I'd be happy with a utility that just placed the new ocx grid in the same location as the vbx grid.".
J_Schroeder, I think anthonyc's concern is about possible property differences. Generally, New versions of controls support an older versions properties for compatibility reasons.
Only properties that are different from the control’s default value are stored in the form module. Properties that are of the default value are not. The remaining properties are container properties (which is usually most of them) and can be left as is. You should remove any properties not by the new control that exist in the form module as well.
I'd just do as I suggested the first time, and then load your project. If a form contains a property that is unsupported, an error will occur and you can review the log created to find out what caused it. Then you can search for that property and remove it when it exists in your utility.
J_Schroeder, I think anthonyc's concern is about possible property differences. Generally, New versions of controls support an older versions properties for compatibility reasons.
Only properties that are different from the control’s default value are stored in the form module. Properties that are of the default value are not. The remaining properties are container properties (which is usually most of them) and can be left as is. You should remove any properties not by the new control that exist in the form module as well.
I'd just do as I suggested the first time, and then load your project. If a form contains a property that is unsupported, an error will occur and you can review the log created to find out what caused it. Then you can search for that property and remove it when it exists in your utility.
I don't know off hand. The best thing you can do is create dummy forms. One for each control. Draw on one form the old control, and on the other form the new control. On both, set every property you can think of to a value other than the default value. Then load them in notepad and you'll be able to see the differences necessary to programmatically make the changes. It's really not that tuff.
I'd recommend that when you're you have your utility program make a backup copy each form it resolves needs to be changed. maybe with an "OLD" extension, for example "Form1.OLD". When your utility starts, it first checks for the OLD version, if it exists, it creates a new "Form1.FRM" from the backup.
I'd recommend that when you're you have your utility program make a backup copy each form it resolves needs to be changed. maybe with an "OLD" extension, for example "Form1.OLD". When your utility starts, it first checks for the OLD version, if it exists, it creates a new "Form1.FRM" from the backup.
whoa, I was typing too fast - sorry about the terrible grammar. If the form exists with the OLD extension, it is the original.
J_Schroeder, if you're going to write a utility to do it, it probably doesn't matter. If not, I can't see how it would hurt since it may perform some of the tasks for you. The URL for Apex is:
http://www.apexsc.com
J_Schroeder, if you're going to write a utility to do it, it probably doesn't matter. If not, I can't see how it would hurt since it may perform some of the tasks for you. The URL for Apex is:
http://www.apexsc.com