Richedit study 05-animation controls

There are no updates in the near future. Let's talk less and go straight to the topic.

 

Microsoft's idea of any technology: when implementing a standard, a general extension mechanism is often reserved. Er, this seems to be the case for many large companies. Developers are bound with themselves through extensions. For example, Microsoft's ie can be embedded with ActiveX controls and BHO extensions. richedit supports OLE extensions. This extension mechanism is mainly based on its OLE framework, which is also the cornerstone of the Microsoft operating system framework. The current development trend is to reduce OLE's emphasis. NET, there is a kind of helplessness called the tiger ride, there is a kind of mistake called separation from the masses, In the development platform, technology is blooming, development resources are extremely rich today, developers are not so strong dependency on Microsoft, so that the current Windows developers are a little hard-pressed, especially C ++ developers have a sense of being abandoned.

 

Talk about the relationship between OLE/COM/ACTIVEX. It is vague. There are some unclear reasons, historical reasons, and popularity. Hou Jie said there are three levels of playing templates: The standard library will be used, the source code of the standard library will be read, and the template will be used for design. I think the same is true for COM. It is usually easy to use COM components. In my understanding, OLE is a technical standard, COM is a language standard, and ACTIVEX is the title of a component that can be taken using these two things. The support for OLE is mainly in the MFC library, while the ATL library is a more pure OLE/COM framework. MFC is closely related to OFFICE. The OFFICE application framework promotes the development of MFC (in the early days, but the UI has long been separated). The OFFICE application model is the application development model of MFC.

 

The reason why we mention MFC and OFFICE is that the general extension mechanism is not so many rules, even ACTIVEX framework. Microsoft is the most enthusiastic about OLE practices. The Windows operating system and OFFICE software are the most typical, while the others are far-fetched. Only a few standard interfaces of OLE technology must be implemented, while most interfaces are optional or partially implemented, especially richedit. OLE regulates the behavior of both the server and the client. If one party (usually the server) decides how to implement the behavior, the other party only needs to implement the behavior.

 

Er, I have said so much, just to explain my sinister intentions, maybe no one understands. The ATL Framework defines four standard export functions for standard registration, anti-Registration, loading, and uninstallation. These functions are irrelevant to the actual OLE functions, especially in richedit extensions. Maybe you can see in many examples on the internet how to use the ATL template to create a control, and then how to simply insert a bitmap to master the core technology, so I will leave it easy, these things are irrelevant. Since Windows can use OLE to build a framework and MFC can practice OLE, we can also use pure C ++ code to play with OLE. I mean there is no need to follow ATL, there is no need to register one thing. The core of the problem is not these things. At present, we just want to insert an animation.

 

RichEdit is an incomplete Ole practice. As mentioned above, there are not many frameworks that fully implement Ole. RichEdit is popular in the IM field because it implements text-and-text mixing, especially in the early stages (the current expansion based on chromium may change the status quo ). RichEdit is a container that can accommodate Ole controls. A typical extension is an animation control. Developed based on the ATL framework, You can implement a standard control, but when you are faced with a non-standard container, those boxes are not that important, this is why it is not easy to make animation controls.

 

According to my investigation (ER, through practice, through QueryInterface observation), I found that to implement an animation control in RichEdit, only two interfaces are required: ioleobject and iviewobject2, the former is integrated into the RichEdit environment, and the latter is used for rendering and display. RichEdit only prefers window-free mode by default. Therefore, it is of little significance to implement ioleinplacesitewindowless, because containers do not recognize you, and of course there are ipersist series interfaces, it is useful for standard environments (such as IDE), but it is not very necessary here, so recognizing the core issues can reduce a lot of confusion. Obviously, my control does not use the ATL framework, because it is of little significance to survive from the RichEdit environment. What's more, I don't have to make it a standard (or possibly ), it is only for better display in RichEdit of a system. The fewer interfaces to be implemented, the less troublesome the introduction, so that you can focus on the main issues.

 

To sum up, my control is a C ++ class and only implements two interfaces:

 

X_begin_interface_map (imrichpicture, objectrootbase)
X_interface_part (imrichpicture, iid_ioleobject, oleobject)
X_interface_part (imrichpicture, iid_iviewobject, viewobject)
X_interface_part (imrichpicture, iid_iviewobject2, viewobject)
X_end_interface_map ()

 

 

Most of the interfaces can be ignored, because we only need this control to be able to hold a space (long width) in RichEdit and display it (key to efficiency ), other programmable, In-Place activation, and object recognition are not important. I have observed QQ's animation controls. Er, they are much more popular than today on the Internet (online content is not keeping pace with the times ). The current 'qq animation control is very simple (how to find it later). It looks like it is just a placeholder tool, and how to trigger the animation is controlled by the host. View its interface:

 

Interface irichframeobj: idispatch {
};
Interface irichpicobj: idispatch {
[ID (0x00000001), propput, helpstring ("Property SRC")]
Hresult SRC ([in] BSTR RHs );
[ID (0x00000002), propput, helpstring ("Property static")]
Hresult Na ([in] Long RHs );
[ID (0x00000003), propput, helpstring ("Property autoheight")]
Hresult autoheight ([in] Long RHs );
[ID (0x00000004), propput, helpstring ("Property autowidth")]
Hresult autowidth ([in] Long RHs );
[ID (0x00000005), propput, helpstring ("Property maxautowidth")]
Hresult maxautowidth ([in] int RHs );
[ID (0x00000006), propput, helpstring ("Property onerror")]
HRESULT onerror ([in] BSTR rhs );
[Id (0x00000007), propput, helpstring ("property objid")]
HRESULT objid ([in] BSTR rhs );
};

 

I don't quite understand the role of IrichFrameObj. I don't even have an interface, but the latter can understand it in a fuzzy way: src is probably an Animated Image path, and auto series is used for Dynamic Scaling. Currently, QQ only allows one Custom Animation. According to the old man's guess, because the Custom Animation is usually large, it will jump to the image when a row is prone to clicks. Other attributes are used for identification and cannot be inferred.

 

Er, it seems that things are not so complicated. Indeed, I only implement two interfaces, and most of them also return E_NOTIMPL, because richedit is not that standard, the standards you implement will not help. Of course, richeit is also being updated. The win8 sdk has made the most significant changes to it, but the win7 sdk also exposes some earlier functions, which may be the biggest highlight of the current implementation (technical content, high risk and high return, incredible ).

 

Many people may be disappointed with the definition of an animation control, but this is also true, because it has nothing to do with it, especially after you understand it, so here you may be very disappointed, but there is so much real content that I don't know how to fill it up.

 

The last suggestion is to respect all playing technologies:

1. The Chinese official standard thought is very serious, and the technology is doing well (Maybe luck ).

2. Simple text

3. Capital Operation and system operation, with little technical effect

4. full stomach, hard to maintain the ideal

 

The greatest truths are invisible, and many of the technologies are clever, and the real industry is the fearless R & D. We are just opportunistic.