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. 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 translated code in #if and hides it from the compiler effectively hiding the build errors.
<Compile ...>
<Fix ...>
...
</Fix>
<Refactor>
<Remove identifier="Panel.frmPhoenMain.mnuEditPaste_Click" migStatus="Stubout" />
</Refactor>
</Compile>
You can use snapshot/compare to see the before/after impact of this command on the translated code.
Also, later on you can upgrade this to a Refactor/Reauthor statement to insert a hand-coded, unit tested, replacement function – thus making the manual work a repeatable part of the upgrade solution. The Reauthor script would look something like this:
<Refactor>
<Reauthor subprogram="Panel.frmPhoenMain.mnuEditPaste_Click"><![CDATA[
public static void mnuEditPaste_Click(object sender, EventArgs e)
{
... hand written code here ...
}
]]></Reauthor>
</Refactor>
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 in question. 2) add/remove content until the test project bulds in VB6