Borland C++ 中的 Windows 子类化 建设者

发布于 2024-07-13 12:55:28 字数 737 浏览 8 评论 0原文

我们正在尝试将一段用 MFC 编写的使用 CWnd.SubclassWindow 方法的 C++ 代码转换为 Borland C++ Builder 代码。 有谁知道如何进行子类化(使用 TForm 对象进行子类化) - 我们完全陷入困境。 任何指示将不胜感激! 蒂亚!

细节:

我们有一个用 Borland C++ 编写的现有基类,它继承自 TForm,用于为所有继承自它的表单提供某种外观和感觉(例如,它处理 WM_NCPAINT 和 WM_NCHITTESTheavily)。

现在我们想使用此代码为用其他语言(确切地说是 MSVC++/MFC 和 C#)编写的表单提供相同的外观和感觉。

我们认为使用 Windows 子类化将是一个好主意,而不是重写所有代码。 然后我们可以将所有现有的和经过测试的代码填充到一个 DLL 中,然后只需使用 hWnd 调用它,该窗口就会自动获得新的外观和感觉。

确切地说,为什么这是不可能的,这真的不是我能说的——我自己不使用 Borland C++ 编写代码。 我花了几分钟在 MFC 中编写了一个存根,向 Borland C++ 开发人员展示了我想要的内容,他们花了几天时间尝试模仿 MFC CWnd::SubclassWindow 方法,但没有成功。

据我了解,问题在于,当您执行“new TForm()”时,会在您有机会停止它之前自动创建一个新窗口。 因此,替换 WindowProc 有效,但是一个不需要的 TForm 窗口漂浮在屏幕上,没有任何用处!

We're trying to convert a piece of C++ code written in MFC which uses the CWnd.SubclassWindow method, into Borland C++ Builder code. Does anyone know how to do subclassing (subclass with a TForm object) - we're completely stuck. Any pointers will be much appreciated! TIA!

Specifics:

We have an existing base class written in Borland C++ which inherits from TForm, which is used to give all forms that inherits from it a certain look and feel (it processes WM_NCPAINT and WM_NCHITTESTheavily, for example).

Now we'd like to use this code to give forms written in other languages (MSVC++/MFC and C# to be exact) the same look and feel.

Instead of rewriting all the code we thought that using windows subclassing would be a great idea. Then we could stuff all the existing and tested code into a DLL and then just call it with a hWnd and that window would automagically get the new look and feel.

Exactly why this is so impossible is really not up to me to say - I don't code in Borland C++ myself. I wrote a stub in MFC in just a few minutes to show the Borland C++ developers what I wanted and they have spent days trying to mimic the MFC CWnd::SubclassWindow method without success.

From what I understand, the problem is that when you do a "new TForm()", then a new window is automatically created before you have any chance to stop it. So replacing then WindowProc works BUT an unwanted TForm window is floating around on the screen to no use!!!!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

漫雪独思 2024-07-20 12:55:28

我假设你指的是VCL。 您可以将 TControl 对象的 WindowProc 属性设置为您自己的窗口过程或另一个控件的 WindowProc。

编辑:基于更多细节的更多答案

要防止new TForm创建一个窗口在屏幕上无用地浮动,您只需将其 Visible 属性设置为 false 即可。 或者,您可以重写 CreateParams 以从窗口中删除 WS_VISIBLE 样式:

void __fastcall TBlahForm::CreateParams(TCreateParams &Params)
{
    TForm::CreateParams(Params);
    Params.Style&=~WS_VISIBLE;
}
//---------------------------------------------------------------------------

仍然会创建一个不可见的窗口,但据我了解用例,这应该不是什么大问题。

重写 TCustomForm::CreateWnd 可能是解决同一问题的另一种方法。

我的另一个建议是将代码从 BCB 移植到 VC++。 如果它对 WM_NCPAINTWM_NCHITTEST 进行了大量的修改,那么它听起来不太可能包含大量 VCL 特定的东西 - 它可能只是直接在 Win32 上进行攻击API? 如果其中没有任何 VCL,那么在 VC++ 中编译应该会神奇地工作。

无论如何:这几乎肯定是可能的。 我有一个用 BCB5(早于 WinXP)构建的应用程序,通过巧妙地使用窗口挂钩、子类化等(其中大部分不是我自己的),它仍然非常乐意处理 XP 甚至 Aero(这不是说维护起来并不痛苦)。 如果可能的话,您的应用程序当然应该是这样。 VCL 遵循与 MFC 不同的范例,但它仍然很灵活。

I'll assume you mean VCL. You can set the WindowProc property of a TControl object to your own window procedure or another control's WindowProc.

EDIT: More answer, based on more specifics

To prevent new TForm from creating a window to float uselessly around the screen, you should just need to set its Visible property to false. Alternatively, you could override CreateParams to remove the WS_VISIBLE style from the window:

void __fastcall TBlahForm::CreateParams(TCreateParams &Params)
{
    TForm::CreateParams(Params);
    Params.Style&=~WS_VISIBLE;
}
//---------------------------------------------------------------------------

There'll still be an invisible window getting created, but as I understand the use case, this shouldn't be a big deal.

Overriding TCustomForm::CreateWnd is potentially another way of attacking the same problem.

My other suggestion would be to just port the code from BCB to VC++. If it's doing lots of mucking around with WM_NCPAINT and WM_NCHITTEST then it sounds an unlikely candidate to have lots of VCL-specific stuff in it - it's probably just banging straight on the Win32 API? If there's nothing VCL in there, compiling in VC++ should pretty much just magically work.

In any event: it's almost certainly possible. I have an app built with BCB5 (which predates WinXP) that through clever use of window hooks, subclassing and the like (most of which isn't my own) is still perfectly happy dealing with XP and even Aero (which isn't to say it isn't a pain to maintain). If that's possible, your application certainly should be. VCL follows a different paradigm to MFC, but it's nonetheless flexible.

长伴 2024-07-20 12:55:28

查看 Codegear 在线文档,它描述了WindowProc的子类化机制。

C++Builder 使用底层的 Delphi VCL,因此搜索“Delphi Window 子类化”将比尝试查找特定于 C++ 的内容更有效。 C++Builder 程序员至少必须能够阅读 Delphi 代码,即使他们不必编写任何代码!

Have a look at the Codegear Online Docs, which describes the WindowProc mechanism for subclassing.

C++Builder uses the underlying Delphi VCL, so searching for "Delphi Window subclassing" will be more fruitful than trying to find something specifically C++. C++Builder programmers have to at least be capable of reading Delphi code, even if they don't have to write any!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文