private
function GetRulerPanel: Hose.WinForm.RulerPanel;
protected
procedure InitControlData; override;
procedure HookNetEvents(AControl: System.Windows.Forms.Control); override;
procedure UnhookNetEvents(AControl: System.Windows.Forms.Control); override;

public
property RulerPanel: Hose.WinForm.RulerPanel read GetRulerPanel;

（我删除了不必要的部分）

在.net中调用过ActiveX控件的朋友一定知道，在.Net调用ActiveX控件时，DotNet会自动生成一个包装类，就像上面TImpRulerPanel一样，只不过Com对象的包装类是从AxHost继承的，这里的包装是从TNetControlWrapper继承的，手法很相像。AxHose通过GetOcx或得Com控件，这里直接可以获得，都是“一家”，自然要方便一些。我想将来，将Vcl控件包装到.Net中使用也不是什么难事。

但是在转换其他一些复杂一点的控件，比如包含自定义事件时，就会有一些问题，甚至产生莫名奇妙的错误，我会加强研究，在后来文章中的给大家介绍及其解决的方法。

现在用.Net IDE开发的同志我不推荐使用Delphi for .net，但现在使用老版本Delphi的同志，我强烈推荐。既可以保留Delphi的一些工程、编程习惯，又可以逐步过渡到.Net，使用.Net类库的强大功能，真是鱼和熊掌可以兼得阿，只是目前的界面控件的兼容上稍差一点。

另外Delphi8也比老版本的Delphi有一些其他方面的小进步，比如以前在编译时无法检验含有虚方法的类，现在则可以等。

总的来说，Delphi8还是非常值得使用.Net开发工具。只看了一小会儿，有什么谬论，希望大家指出和原谅，我也会不断地学习进步！

acai 评论:
不用再指望VCL还能在.Net上再现辉煌了，Borland清楚，你我也应该清楚，就象李维说的，“把Delphi7好好保存起来吧，这是最后一个Win32版本了”（好像据说还会有更新，如7.1等等，但是大版本更新不会有了，仅仅处于维护阶段了），还在开发win32程序的兄弟，就买本老李的《Inside VCL》，没事研究下VCL做做纪念吧。而想快速地进入.Net的天地，那就轻装上阵，暂时忘记Delphi吧。千万要记住：只要ms不倒，.Net的FCL就是.Net下最大最流行最根本的类库，你不要再指望borland把什么都包起来象个婴儿似地喂着delphi的程序员——如果你还是认为学了VCL就可以不理会Win32的api，学了VCL.Net就可以不理会FCL的话，那就当我没说吧。

完全没有必要用所谓的“vcl Form”程序来过渡到.Net的上，“winform application”是标准的.Net类库程序，而所谓的“VCL Form Application”仅仅是borland用来进行所谓“升级维护”的幌子而已，李维都认为现在的vcl.net仅仅是个过渡方案，而Danny Thrope也直言不讳说.Net类库由MS来开发那Borland可以把以前分散在类库设计上的力量集中起来设计“真正威力的Delphi”（不知道IDE重要了还是类库重要了），大家都知道这个版本的delphi开发时间仅仅只有6个月，所以现在的“VCL Form Application”的控件少的可怜，那是因为开发组来不及做，以后也很难说，再说，学习.Net，首要的是学习.Net FrameWork，而不是VCL.Net！！
即使从工具的角度来讲，现在的Delphi.Net也是个鸡肋，就这种bug不断的半成品，真的能来做项目吗？？从学习的角度来讲，那更不应该来用，.Net FrameWork已经不象以前的Win32api，学习的难度已经大大降低了，更不可想像从事.Net的开发而不熟悉.Net的FCL，因此，还是学习C#吧！VS.Net要稳定的多，足以用来做真实的项目开发了，反观现在的C# Builder和Delphi.Net，有几个人真的敢来做项目？？
所以，如果你真的还是所谓的“Delphi”扇子，那尽量还是选择“Windows Form”程序学习吧，否则，还是老老实实地去学习Framework去吧。