...
This is moving in the right direction. Here is a re-engineering example using the "Refactor, Remove" and a "Refactor, Reauthor" statements of gmStudio.
Screen.ActiveControl is a very difficult operation to upgrade because it is weakly typed and typically used in multi-type code like the function at hand. Also the .NET Clipboard is a bit different from VB6 in a few ways. Typically this type of code is best reworked by hand. Fortunately, copy/paste is probably a tiny feature compared to the real logic in the app. I am curious to see what our translation was.
A quick thing you can do for code that you plan to rework by hand is use a Refactor/Remove-stubout command in your translation script. Its It's a "punt" but it does document the code you plan to rework, and it gets it out of the way of other build issues. Stubout is a inexpensive and reasonable technique for methods that are highly-platform specific. The stub-out I like to use here is status=conditional that wraps the tranlated translated code in #if and hides it from the compiler effectively hiding the build errors.
<Remove identifier="Panel.frmPhoenMain.mnuEditPaste_Click" migStatus="Stubout" /> |
Also, later on you can change upgrade this to a REfactorRefactor/Reauthor statement to insert the a hand-coded, unit tested, replacement function make – thus making the manual work a repeatable part of the upgrade solution. The Reauthor script would look something like this:
<Reauthor subprogram="Panel.frmPhoenMain.mnuEditPaste_Click"><![CDATA[ |
public static void
public static void mnuEditPaste_Click(object sender, EventArgs e) |
{
{
... hand written code here ... |
}
The second set of issues relate to VB.Data control and I really need a sample for that one. We have not done a lot of apps that use VB data binding so we might need to fine tune the defintion for that type in our metalang files.
The third set I am not certain of... need the sample.
If you want to push into solving the low-level upgrade issues, I need you to do the following
The process for solving low-level re-engineering and upgrade issues is as follows:
1) create a small, valid VB6 test project, say sample1.vbp, that references the COM files , and code filesin question. 2) add/remove content until it builds in VB6 3) setup a gmStudio project files for the sample VBP. Call it sample1. You can use the same workspace you are using for Panel upgrade work so that it will use the same IDFs.
4) Run the translation, deploy, and build process and verify that you are reproducing the build errors of interest.
5) Zip up the source code, project files, and logs and email to me.
Once we get a baseline sample code we can add things do it as needed; but we really should have one for troubleshooting since I cannot work with the original problem code. Ideally the sample will even be runnable, so we can take the upgrade beyond the build to functionally correct.
I attached a starter sample for you the test project bulds in VB6