如何在MFC中进行控制子类化。 [英] how are controls subclassed in MFC.

问题描述

我通常使用win32 API对windows进行编程。请问如何在MFC中对控件进行子类化？

I normally program windows using win32 API.Please how are controls subclassed in MFC?

推荐答案

这个问题并不像看起来那么简单。



对子分类有两种不同的理解。第一个与纯原始Windows API相关。从应用程序开发人员的角度来看，此接口不是面向对象的（有些人说基于对象）。即使对象本身基于OOP内部，从API用户的角度来看，它们只是对象，没有类。一切都在API实现中完成。如果你获得了一些对象，比如一个窗口句柄，你只能通过将它传回API来使用它。应用程序仍然不知道这些对象的性质以及由句柄处理的对象的内部结构。使用这种方法，可以使用非OOP语言进行应用程序开发，例如C，Pascal（甚至非OOP Pascal，而不是Borland或Free Pascal）或其他类似的语言。基于这种方法，API引入了所谓的windows类。从应用程序开发人员的角度来看，它们不是真正的类。相反，他们扮演元对象的角色：

http：// en.wikipedia.org/wiki/Metaobject [ ^ ]。



你可以在这里阅读这些Windows类： http://msdn.microsoft.com/en-us/library/windows/desktop/ms632596%28v=vs.85%29.aspx [ ^ ]。



除此之外，您还可以使用面向对象的语言从其他类派生类。从这个意义上说，你正在使用OOP语言理解它们的类。



对于MFC，它使用两种方法。趋势是：库本身使用两种方法，而应用程序员倾向于使用C ++ OOP。这样，大多数或所有用户类都不会创建新的Windows类，使用Windows和MFC中定义的相同，更改其基于C ++ OOP的行为。这种方法提供了足够的表达能力，因为，特别是因为用户可以覆盖处理任何事件的方法，这些方法利用所有Windows电源。



一般情况下，使用有效的MFC，用户应该对经典OOP有深入的了解：虚拟方法，覆盖，后期绑定和多态。



我的最后一点：在我看来，MFC太旧而且在道德上已经过时，代码的可维护性水平低于后来的技术。然而，比较API和技术的质量是复杂的，而且从不简单。

-SA

The question is not so trivial as it may seem.

There are two different understanding of "sub-classing". First one is related to pure raw Windows API. This interface, from the standpoint of the application developer, is not object-oriented (some say "object based"). Even though the objects themselves are based on OOP inside, from the standpoint of the API users, they are just objects, without "classes". Everything is done inside the API implementation. If you obtain some object, say a window handle, you can use it only by passing it back to the API. The application program remains agnostic about the nature of such objects and the internal structure of the object "handled" by the handles. Using this approach, it was possible to use non-OOP languages for application development, such as C, Pascal (even non-OOP Pascal, not Borland or Free Pascal) or other languages like that. Based on this approach, API introduced so called "windows classes". From the standpoint of application developers, they are not real classes. Rather, they play the role of meta-objects:
http://en.wikipedia.org/wiki/Metaobject[^].

You can read about those "Windows Classes" here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms632596%28v=vs.85%29.aspx[^].

On top of that, you can use object-oriented languages to derive classes from other classes. In this sense, you are using the classes how they are understood in the OOP language.

As to MFC, it uses both approaches. The trend is: the library itself uses both approaches, while an application programmer tends to use C++ OOP. This way, most or all user classes do not create new windows classes, use the same defined in Windows and MFC, changing its behavior based on C++ OOP. This approach provides enough expressing capabilities, just because, in particular, the user can override methods handling any events, which leverage all the Windows power.

In general, to use MFC effectively, the user should have in-depth knowledge of "classical" OOP: virtual methods, overriding, late binding and polymorphism.

My final note: in my opinion, MFC is too old and morally obsolete, the level of maintainability of code is lower then in later technologies. However, comparison of the quality of API and techniques is complicated and never straightforward.

—SA

这篇关于如何在MFC中进行控制子类化。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！