For Win32 desktop applications, use IInkDesktopHost and other related APIs for inking

[yuconglin2023]

According to the following picture information referenced on the InkPresenter.ActivateCustomDrying method page in Microsoft Learn, it states that for Win32 desktop apps use IInkPresenterDesktop as the desktop host for InkPresenter and connect to the DirectComposition visual tree for ink input. I've done this step correctly so far. But then I have a question, because the picture says "This requires an IInkD2DRenderer object to manage ink input", I borrowed from the "Complex Ink Example" and successfully drove InkD2DRenderer in a Win32 desktop app. However, the problem arises when I try to call the InkPresenter.ActivateCustomDrying method as in the example. Even if I call the ActivateCustomDrying method as per the requested timing (before the InkCanvas loads, e.g. immediately after calling the IInkDesktopHost::CreateInkPresenter method and getting WinRT's InkPresenter object, complete the custom ink drying method call before SetRootVisual) attempts to activate the custom ink drying and returns a valid InkSynchronizer object, But in the end the ink is still automatically drawn by the InkPresenter into the default DirectComposition visual tree instead of the expected VirtualSurfaceImageSource surface initialized with the D2D device context (I've made sure that the VSIS surface has been created correctly and properly bound to render to the Background content of the Grid control in XAML, and the custom ink drying process is complete and effective like the example).

When I press the pointer the ink is drawn into the DirectComposition visual tree, an error is thrown the moment the pointer is released. The error that occurred (the exception thrown at 0x00007FFAB1C87F9A (KernelBase.dll): WinRT originate error - 0x8000FFFF : 'catastrophic failure') is in the process where InkSynchronizer is called. The location of the BeginDry method. I think it's the InkPresenter whose desktop host is still drying ink in the DirectComposition visual tree after calling the ActivateCustomDrying method, so when the flow executes to call the InkSynchronizer.BeginDry method, an error is thrown because there is no wet ink available.

So I'm confused about how the desktop host of IInkPresenterDesktop, the InkPresenter, should properly activate the custom drying mode and prevent it from automatically drying the ink into the DirectComposition visual tree. Did I miss some technical details or was there a limitation to an inking API like Win32 desktop? Please give answers and effective solutions! Thanks for your answer!