Remove Statement Summary

Remove is a terminal, refactoring statement that occurs only with a Refactor statement. It prevents a component from being authored. For components other than subprograms, removing them involves simply not declaring them in the target code. For subprograms, they can either not be declared or they can be stubbed out --.i.e., declared but no procedural code authored. The problem with not declaring components is that their references in the procedural code must be dealt with as well. The bulk of the attributes associated with this statement deal with the issue of replacing references to the undeclared components.

The attributes of the Remove statement are as follows:

Attribute	Description
Identifier	This required identifier attributes specifies the component to be removed. If the containing Refactor statement had a FileFilter specified then this identifier should be specified relative to it; else, it should be specified relative to the root of the symbol table.
MigPattern	This string attribute contains a pattern string that will be used as a substitute for a reference to the component. Any arguments that reference might require have to be accounted for in the pattern string. See the Patterns page for details.
MigStatus	This attribute is one of the entries -- Notimplemented, Delete, Stubout, Conditional, or a code event string.

The script errors associated with the Remove statement are as follows:

Error	Description
1098	The identifier [%1d] could not be found.

The migStatus entries are used to control how remove declared components from the translation without causing build problems caused by references to those components. To demonstrate how these change the translations consider the demonstration code fmstocks\vb6\FMStocks_DB\FMStocks_DB.vbp from which a subprogram DBHelper.collectParams and a declare Helpers.RegisterEventSource will be removed with various migStatus settings. In the source, these are, showing a typical reference and the declaration

collectParams cmd, params
  ...
Private Sub collectParams(ByRef cmd As ADODB.Command, ByVal argparams As Variant)
  Dim params As Variant, v As Variant
  Dim i As Integer, l As Integer, u As Integer
    ...
End Sub

hEventLog = RegisterEventSource("", sEventTitle)
  ...
Declare Function RegisterEventSource Lib "advapi32.dll" Alias _
  "RegisterEventSourceA" (ByVal lpUNCServerName As String, _
  ByVal lpSourceName As String) As Long

Note that the subprogram has a body that needs to be dealt with in the removal as well; while the declare does not. Looking at the default translations for these

collectParams(ref cmd,params_migname);
   ...
private void collectParams(ref ADODB.Command cmd,object argparams)
{
  object[][] params_migname = null;
  object v = null;
    ...
}

hEventLog = RegisterEventSource("",sEventTitle);
  ...
[DllImport("advapi32.dll",EntryPoint="RegisterEventSourceA")]
public static extern int RegisterEventSource(string lpUNCServerName,string lpSourceName);

Using Remove with no migStatus

Using the remove without any migStatus specification removes the indicated component from the translation without effecting any of the references to that component. Using this Remove

<Compile Project="C:\gmSrc\fmstocks\vb6\FMStocks_DB\FMStocks_DB.vbp" >
   <Refactor>
      <Remove Identifier="FMStocks_DB.DBHelper.collectParams" />
      <Remove Identifier="FMStocks_DB.Helpers.RegisterEventSource" />
   </Refactor>
 </Compile>

causes the entire declaration for these components to be removed from the translation, but leaves statements like

collectParams(ref cmd,params_migname);
   ...
hEventLog = RegisterEventSource("",sEventTitle);

in the translation, which means that it will not build.

Using Remove with Delete migStatus

Using the remove with the delete migStatus removes both the declarations for the components and also the references. Using this Remove

 <Compile Project="C:\gmSrc\fmstocks\vb6\FMStocks_DB\FMStocks_DB.vbp" >
    <Refactor>
       <Remove Identifier="FMStocks_DB.DBHelper.collectParams" migStatus="Delete" />
       <Remove Identifier="FMStocks_DB.Helpers.RegisterEventSource" migStatus="Delete" />
    </Refactor>
 </Compile>

completely removes the named components from the translation.

Using Remove with NotImplemented migStatus

Using the remove with the NotImplemented migstatus removes the declaration but comments out the references rather that removing them completely. Using this Remove

<Compile Project="C:\gmSrc\fmstocks\vb6\FMStocks_DB\FMStocks_DB.vbp" >
   <Refactor>
      <Remove Identifier="FMStocks_DB.DBHelper.collectParams" migStatus="NotImplemented" />
      <Remove Identifier="FMStocks_DB.Helpers.RegisterEventSource" migStatus="NotImplemented" />
   </Refactor>
</Compile>

removes the declarations as before but authors the references as can be see here

// collectParams
// collectParams(ref cmd,params_migname);
  ...
// RegisterEventSource
// hEventLog = Convert.ToString(RegisterEventSource("",sEventTitle));

Notice that each reference line is preceded by a comment documenting which component is causing the commenting out.

Using Remove with StubOut migStatus

As an alternative to removing the declaration, a stubbed version of that declaration can be authored instead. This has the advantage that this approach does not require that any references to the components be changed. Using this Remove

<Compile Project="C:\gmSrc\fmstocks\vb6\FMStocks_DB\FMStocks_DB.vbp" >
   <Refactor>
      <Remove Identifier="FMStocks_DB.DBHelper.collectParams" migStatus="StubOut" />
      <Remove Identifier="FMStocks_DB.Helpers.RegisterEventSource" migStatus="StubOut" />
   </Refactor>
</Compile>

the only difference between the original translation and the migrated one is

 public void collectParams(ref ADODB.Command cmd,object argparams)
 {
 }

Notice that the Declared component does not change at all since it has no body to be stubbed. The Remove statement accepts the specification, but it has no effect.

Using Remove with Conditional migStatus

From time to time we come across a subroutine that we plan to reauthor during the migration phase of the project. Frequently the subroutine is not translating well, perhaps because it depends on a lot of win32 APIS and the most productive approach is a reauthor. However, we want to defer the reauthoring task. Also Reauthoring almost always begins with the latest good translation of the code. Being able to get a current translation but also defer finishing it and changing it to a reauthor are somewhat at odds. Using the Conditional migstatus is a way to get a current translation of a routine, but have the .NET compiler treat the resulting routine as a stub. Using this Remove

<Compile Project="C:\gmSrc\fmstocks\vb6\FMStocks_DB\FMStocks_DB.vbp" >
   <Refactor>
      <Remove Identifier="FMStocks_DB.DBHelper.collectParams" migStatus="Conditional" />
      <Remove Identifier="FMStocks_DB.Helpers.RegisterEventSource" migStatus="Conditional" />
   </Refactor>
</Compile>

causes the following simple change in the translation

*** Refactored start of connectParams
 {
 // UPGRADE_INFO: conditional stub FMStocks_DB.DBHelper.collectParams
 #if mig_conditional_stub
    object[][] params_migname = null;
*** Original start of connectParams
 {
    object[][] params_migname = null;


*** Refactored end of connectParams
 #endif
 }
*** Original start of connectParams
 }

The actual text associated with the start and end entries are in the AuthorText.StartConditional and AuthorText.EndConditional methods in the language file, where they may be overridden on replaced. As in the StubOut, notice that the Declared component does not change at all since it has no body. The Remove statement accepts the specification, but it has no effect.

Table of Contents

gmplRemoveStatement