Opendocument full mode - #17
Merged
Merged
Conversation
Office applications driven via OLE Automation default to msoAutomationSecurityLow, so a full-mode preview of a macro-carrying document ran its AutoOpen/Document_Open VBA without any prompt: automation opens bypass both Protected View and the "Enable Content" notification bar. The host now sets Application.AutomationSecurity = msoAutomationSecurityForceDisable on every Word / Excel / PowerPoint instance it creates, right after CoCreateInstance and before any Open call, so previews never execute document code in either render mode. In practice the hole affected XLSB and the legacy DOC / XLS / PPT formats, where macro capability is invisible in the extension. The explicitly macro-enabled formats (DOCM, DOTM, XLSM, XLTM, PPTM, PPSM, POTM) never reach the host at all: Office deliberately registers no preview handler for them, so the plugin DLL's registry probe declines the file and Total Commander falls through to its next viewer - the same behaviour as Explorer's Alt+P pane. Document the macro guarantees and the no-handler caveat in README.md (Supported Formats table no longer lists the macro-enabled extensions), CHANGELOG.md (Security section) and CLAUDE.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Even borderless, the Office window floated over the Lister pane could be dragged away by the free space of its in-app title bar or resized by its edges - modern Office hit-tests HTCAPTION and the edge grips in the client area, so stripping WS_CAPTION|WS_THICKFRAME does not remove them. An accidental grab (usually while aiming for the Lister's edge) left the overlay displaced until the pane itself changed. The overlay tracker now owns the window geometry outright: - When GetGUIThreadInfo on the Office UI thread reports GUI_INMOVESIZE with hwndMoveSize equal to the overlay, the modal move/size loop is aborted with WM_CANCELMODE (sent via SendNotifyMessage so the STA never blocks on the Office thread). The loop ends as if Esc was pressed and the window snaps back to its pre-drag geometry, so the grab never takes effect. Drags of the app's own dialogs on the same thread are left alone. - Outside the loop, any mismatch between the overlay's actual rect and the pane rect is corrected with the same SetWindowPos the tracker already uses, covering drags completed between ticks and programmatic self-moves by Office. If Office refuses the rect (minimum-size clamp), the failed pane rect is remembered and retried only after the pane changes, to avoid fighting Office at the timer frequency. Also refresh release-date in pluginst.inf. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.