コンバートしたソースを最大限利用する方法
プロジェクトの参照で、C# WinFormsプロジェクトの基本的な参照のみを残し、削除する
これにより、コンバート時に変換された、VB6互換部品のコードが全てエラーになる。
（詳細は、後日追記する）
SharpDevelopで新たに追加された、MyApplicationなどのStatic対応も全て使わないことにする。
参考にすることはある可能性はあるので、ファイル全体をコメントアウトしておく。
Using句のネームスペース設定中、Microsoft.VisualBasic 名前空間、Microsoft.VisualBasic.Compatibility.VB6 名前空間は参照を削除したことによって赤いアンダーラインが表示されるが、残しておく。この名前空間を利用し、エラーになっている部分を拾うことになる。
一部、LenBやErr()など、上記の名前空間に属する関数などが省略された形で記述されているが、
一括変換又は、下記で記述するマイグレーションサポート用のクラスへ実装することにする。詳細は後述する。
簡単に説明すると、この関数らを含むフォームを継承したクラスを作り、全てのフォームはそれらを継承するようにする。
Class MigSupForm : Form
{
LenB(){};
Err();
}
Class FrmXXX : MigSupForm
{
}
Grid
AxMSFlexGrid
MSWinsockLib
axWinsck
ADODB
これらのOCX部品に関しても、Microsoft.VisualBasic 名前空間、Microsoft.VisualBasic.Compatibility.VB6 名前空間へ属する
関数として作ることにより、変換ソースを極力修正しないようにする。
名前空間を利用する目的としては、一行一行の手間を省くためである。これは、実際やっていただければ納得するはず。
ここまでは無難な作業である。なんでやるかは、
VB６関連ソースを一括に管理するため、
移行の土台に素早く乗らせるため、
リファクタリングを活用することで、もっと効率的な作業を進めるため。
。。。
型の曖昧さの問題は、演算子周りで起きており、キャストを施すのは、最終的に道ではあるが、全てを手作業するのは大変である。
この解決策として、演算子のオーバーロードを施す事はどうだろうか。
全ての形ではない問題が起きている型のみを作成することにする。
ジェネリックも応用できそう
https://ufcpp.net/study/csharp/sp2_generics.html
BOXING、UNBOXINGも応用できそう。
オブジェクト型には全てが入る。
using System;
class Test
{
static void Main() {
int i = 123;
object o = i; // Boxing
int j = (int)o; // Unboxing
}
}
頻発する、Form を Objectへ代入、ShortにIntを代入 は
VBSObject クラス、VBSShortクラスを作り、演算子を定義すればそうだろうか。
全体的にStaticとなっているので、最初は、SharpDevelop作成サポートクラスに似せた
静的サポートクラスを作成する。ここにMain関数も入れておく。
フォームのクラス名でそのまま利用などは、SharpDelelop作成クラスでの定義を利用するように変換されているので、
それに似せるような形をとる。
win32 C# 関数
ちょっと変換が変なので、見直しが必要。
https://www.atmarkit.co.jp/ait/articles/0305/09/news004.html
ここで結構調べられる
https://www.pinvoke.net/index.aspx
配列 コントロール C#
http://tki.main.jp/hata/indexer.html
このコンセプトのファイルは、DLLのプロジェクトにして、共通としてインポートするといいでしょう。
全体を早く見渡し、少しでも早く軌道に乗せたい。