Integrate DxPdfViewer and remove custom zoom controls

Replaced custom zoom controls in `EnvelopeReceiverPage.razor` with the built-in zoom functionality of the `DevExpress.Blazor.PdfViewer` component (`DxPdfViewer`).

- Removed custom zoom buttons, slider, and JavaScript zoom logic.
- Introduced `_viewerZoomLevel` to align with `DxPdfViewer.ZoomLevel`.
- Synchronized zoom state using `ZoomLevelChanged` to update `_currentZoom`.
- Updated overlay redraw logic to react to viewer zoom changes.
- Modified `FitToWidth` and `SetZoom` methods to work with `DxPdfViewer`.
- Updated documentation to reflect integration decisions and findings.

These changes simplify zoom handling, reduce UI redundancy, and ensure proper synchronization between the viewer and overlay logic.
This commit is contained in:
2026-06-29 14:08:51 +02:00
parent 1ac7188466
commit 03367ebc4a
3 changed files with 109 additions and 47 deletions

View File

@@ -939,6 +939,77 @@ That is the safest first vertical slice because:
- it reduces uncertainty in overlay scaling
- it does not yet require full signature flow completion
### 9. Verified DevExpress API findings and current progress
The following points are now verified from DevExpress documentation for `DxPdfViewer`:
- `ZoomLevel` is a real component parameter
- positive `ZoomLevel` values are interpreted as percentages
- `ZoomLevelChanged` is supported and should be used to synchronize viewer zoom with page state
- `CustomizeToolbar` can clear all built-in toolbar items through `ToolbarModel.AllItems.Clear()`
- `ActivePageIndex` is read-only information and is not a page-navigation parameter
### 10. Recovery progress update
The first functional recovery step is zoom restoration.
Implemented direction:
- bind custom receiver toolbar zoom controls to `DxPdfViewer.ZoomLevel`
- synchronize zoom changes back into `_currentZoom` through `ZoomLevelChanged`
- remove competing custom JS ctrl+wheel zoom logic
- keep overlay redraw pipeline after confirmed zoom changes
Expected outcome after this step:
- toolbar zoom buttons visibly affect the DevExpress viewer
- zoom slider visibly affects the DevExpress viewer
- overlay refresh is triggered from real viewer zoom state instead of guessed zoom state
### 11. Additional findings after first zoom integration attempt
After the first live integration attempt against the installed `DevExpress.Blazor.PdfViewer` package version `25.2.3`, one important runtime behavior was confirmed:
- the `DxPdfViewer.ZoomLevel` value must be treated as a zoom factor for normal positive values in the live UI flow used here
- in practice, `1.5` corresponds to `150%`
- using `150` as the bound value causes the DevExpress viewer UI to display `15000%`
This means the receiver page must keep two different zoom representations:
- `_currentZoom` = receiver custom workflow percentage view, for example `150`
- `_viewerZoomLevel` = DevExpress viewer value, for example `1.5`
### 12. Current UI decision for zoom controls
The custom toolbar zoom section in `pdf-toolbar__zoom-section` is no longer considered desirable.
Current decision:
- remove the custom zoom buttons and slider from the receiver toolbar
- rely on the built-in DevExpress PDF Viewer zoom UI instead
- keep `ZoomLevelChanged` synchronization so overlay redraw logic can still react to viewer zoom changes
Reason:
- DevExpress already provides zoom UX
- duplicate zoom controls create confusing UX and unit mismatch risks
- the built-in viewer zoom UI is a better source of truth for the current zoom state
### 13. Current UI decision for thumbnails
The custom thumbnail sidebar is still kept for now.
Reason:
- current receiver workflow depends on custom thumbnail shell behavior
- width persistence and resizable splitter are already implemented in the custom sidebar
- no verified built-in `DxPdfViewer` thumbnail sidebar integration surface has yet been confirmed from the currently inspected API surface
So the current decision is:
- keep custom thumbnail sidebar for now
- revisit possible DevExpress-native thumbnail navigation later only if it supports the required receiver workflow behavior
---
## Files Most Likely Relevant For Future Work