Skip to content

Use MFC-native property sheets and dynamic layout instead of CTreePropSheet / ResizableLib

Summary

The project already builds with the current locally installed MFC toolset (v143, VS 2022, MFC 14.x), but it still uses older UI host infrastructure:

  • CPreferencesDlg derives from CTreePropSheet
  • the tree contains zero uses of CMFCPropertySheet, CMFCTabCtrl, or CMFCDynamicLayout
  • many dialogs still depend on ResizableLib

This item is about using the MFC version we already ship more effectively, not about changing GUI frameworks.

Current State (revalidated 2026-04-20)

Local main has partial progress on this surface now:

  • b4206dc simplified the preferences dialog host scaffolding
  • e78ab5a baked larger options-page resources into the app
  • 3f6994b, 092b88e, and 0fcfade removed dead Tweaks resize/static-page plumbing

But the core modernization target is still not finished:

  • PreferencesDlg.h:23 - class CPreferencesDlg : public CTreePropSheet
  • TreePropSheet.h:65 - CTreePropSheet still derives from CPropertySheet
  • PreferencesDlg.cpp still routes page icons and dialog startup through CTreePropSheet
  • live srchybrid still has many ResizableLib consumers
  • live srchybrid still has 0 hits for CMFCPropertySheet, CMFCTabCtrl, or CMFCDynamicLayout

So this item is no longer truly Open, but it is also not close enough to complete to mark Done. The correct status is In Progress.

First Slice

  1. Replace CPreferencesDlg / CTreePropSheet with CMFCPropertySheet configured for tree-style navigation
  2. Use CMFCDynamicLayout on migrated high-value dialogs instead of third-party ResizableLib anchoring
  3. Reduce ResizableLib usage incrementally as each dialog host is modernized

Constraints

  • Preserve the existing dialog resources and navigation model
  • Preserve page icons, apply/ok/cancel behavior, keyboard handling, and settings persistence
  • Coordinate with FEAT-017 and REF-026 because DPI/layout/manifest work interact directly
  • Coordinate with REF-016: do not both inline and replace the same ResizableLib surface at the same time; choose one ownership path per dialog area

Acceptance Criteria

  • [ ] PreferencesDlg uses CMFCPropertySheet or an equivalent MFC-native host
  • [ ] TreePropSheet.* is retired or reduced to dead code with no active consumers
  • [ ] Migrated dialogs use MFC-native layout support (CMFCDynamicLayout) instead of ResizableLib
  • [ ] No regression in page selection, page icons, dialog resizing, or keyboard behavior
  • [ ] DPI behavior is no worse than current main

Notes

  • This is separate from any larger STL / threading / networking modernization
  • This item does not require moving away from CString, CDialog, or MFC generally
  • There is no exact experimental-branch port for this item today; it is a current-main cleanup/improvement opportunity

eMuleAI/ResizableLib Evidence

The eMuleAI tree carries a third-party patch for ResizableLib leak/anchor cleanup:

Do not inline that vendor patch into app code as a first response. It is useful evidence that the old layout dependency has real maintenance cost, but the preferred eMuleBB direction remains MFC-native property sheets and dynamic layout. If a specific leak is reproduced before the full replacement lands, patch the dependency fork or the smallest owning dialog rather than scattering ResizableLib workarounds through the app.