Lockup in skin framework

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   I saw somewhere a comment to report any class that causes an issue in the skinning framework. Well today we found one. The window class name is "DDEMLEvent" and we are running a DEBUG build where an assert is being thrown in IsImplementedInSystemWindowModule. That assert locks up our app due to calls in threads to WaitForSingleObject.

We assert and then lockup because the skinning system cannot find a window proc for this  class.

I asked my copilot why CJ could not find it. It examined the code in XTPSkinManager.cpp wheere SetHook tries to call AttachHook which eventually ends up in IsImplementedInSystemWindowModule where lpProc is nullptr. Then it said this:

1.    Ownership and Lifecycle:
The DDEMLEvent window is created and managed by the operating system, specifically for DDEML's internal event handling. Its window procedure is private to the system DLLs (such as user32.dll), and not exposed for external use or modification.

2.    No Public API:
Microsoft does not provide any documented API to retrieve, replace, or subclass the window procedure for DDEMLEvent. The class is not registered by application code, and its window proc is not accessible via standard Win32 APIs.

3.    Isolation for Stability:
By keeping the window procedure internal, Windows ensures that DDEML's event handling remains stable and secure. Allowing external frameworks to hook or replace the window proc could introduce instability or security risks.

4.    Framework Design:
Codejock and similar frameworks are designed to skin, subclass, or hook windows that are created by the application or by standard controls (e.g., buttons, edit controls, etc.). They rely on being able to access and replace the window procedure, which is not possible for system-managed classes like DDEMLEvent.

Summary:
Codejock cannot use or subclass the window proc for the DDEMLEvent class because it is a system-internal window class with a private window procedure, not exposed or intended for use by application frameworks. This is by design in Windows to protect internal event handling mechanisms.

I added the class name to the filtering system to avoid the lockup. This seems like a case where CJ just wants to avoid touching that class.

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 954	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: Lockup in skin framework Posted: 11 hours 6 minutes ago at 3:44pm
	I saw somewhere a comment to report any class that causes an issue in the skinning framework. Well today we found one. The window class name is "DDEMLEvent" and we are running a DEBUG build where an assert is being thrown in IsImplementedInSystemWindowModule. That assert locks up our app due to calls in threads to WaitForSingleObject. We assert and then lockup because the skinning system cannot find a window proc for this class. I asked my copilot why CJ could not find it. It examined the code in XTPSkinManager.cpp wheere SetHook tries to call AttachHook which eventually ends up in IsImplementedInSystemWindowModule where lpProc is nullptr. Then it said this: 1. Ownership and Lifecycle: The DDEMLEvent window is created and managed by the operating system, specifically for DDEML's internal event handling. Its window procedure is private to the system DLLs (such as user32.dll), and not exposed for external use or modification. 2. No Public API: Microsoft does not provide any documented API to retrieve, replace, or subclass the window procedure for DDEMLEvent. The class is not registered by application code, and its window proc is not accessible via standard Win32 APIs. 3. Isolation for Stability: By keeping the window procedure internal, Windows ensures that DDEML's event handling remains stable and secure. Allowing external frameworks to hook or replace the window proc could introduce instability or security risks. 4. Framework Design: Codejock and similar frameworks are designed to skin, subclass, or hook windows that are created by the application or by standard controls (e.g., buttons, edit controls, etc.). They rely on being able to access and replace the window procedure, which is not possible for system-managed classes like DDEMLEvent. Summary: Codejock cannot use or subclass the window proc for the DDEMLEvent class because it is a system-internal window class with a private window procedure, not exposed or intended for use by application frameworks. This is by design in Windows to protect internal event handling mechanisms. I added the class name to the filtering system to avoid the lockup. This seems like a case where CJ just wants to avoid touching that class.