Repository navigation
Take the WinForms shell from PlatformHeads.WindowsForms - #966
Merged
Merged
Conversation
ViewerForm and BuildMonitor's MonitorForm each did what a form pumped by the app's own loop has to, and each had fixes the other lacked. PlatformHeads 0.3.0 has one copy, HeadForm, made from both, which BuildMonitor took in SimonCropp/BuildMonitor#61, and this takes it: - ViewerForm derives from HeadForm. Its placement and its rules, the first size scaled to the display, closing as a request, Raise, Parked and the modal frame timer go to the base. Frame keeps its name and hands the base its ModalFrame; the scroll bar still enters and leaves the modal loop itself. The tests that held those rules call WindowFit. - FormsViewerWindow copies through FormsClipboard, and ViewerApp hands its setup to FormsApp. And the loop idles. FormsViewerWindow waited a fixed frame after every present, so a viewer left open woke sixty times a second with nothing to do, and ten hidden or minimised. It now implements Wait with HeadForm's WaitForFrame, which idles on the message queue and the loop's wake together, and ViewerProgram calls it after each present with a LoopWake. Every change of state sets the wake, and so does every window command, which changes none: MessageHandler's directly, OwnerLink's through Commanded. The idle is a frame at most while a spinner is up, since it turns only as the canvas repaints, and while a copy waits to be offered the clipboard again. The native heads wait inside their present and answer Wait at once, so they pace themselves as before. The five pins name 0.3.0. The package pins already did; the workflow's and the CMake module's were still at 0.2.0. The packages carry PlatformHeads.WindowsForms.dll beside each Windows head, the one change to the entries Packaging.Tests has on record.
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
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.
ViewerFormand BuildMonitor'sMonitorFormeach did what a form pumped by the app's own loop has to, and each had fixes the other lacked. PlatformHeads 0.3.0 has one copy,HeadForminPlatformHeads.WindowsForms, made from both, which BuildMonitor took in SimonCropp/BuildMonitor#61. This is layer 3, after the kernel in #959.What changes
ViewerFormderives fromHeadForm. Its placement and its rules, the first size scaled to the display, closing as a request,Raise,Parkedand the modal frame timer go to the base, about 340 lines.Framekeeps its name and hands the base itsModalFrame; the scroll bar still enters and leaves the modal loop itself. The tests that held those rules callWindowFit.FormsViewerWindowcopies throughFormsClipboard, andViewerApphands its setup toFormsApp.uses:and the CMake module'sGIT_TAGwere still at 0.2.0.The loop idles
FormsViewerWindowwaited a fixed frame after every present, so a viewer left open woke sixty times a second with nothing to do, and ten times hidden or minimised. It now implementsWaitwithHeadForm.WaitForFrame, which idles on the message queue and the loop's wake together, andViewerProgramcalls it after each present with aLoopWake:MessageHandler's directly,OwnerLink's through the newCommanded. So an arrival, or a focus from the tray, is drawn at once.Waitat once, so they pace themselves as before.FrameWaitTestsgoes with the wait it tested.Checked
HeadForm's.Packaging.Tests20/20. The one change on record isPlatformHeads.WindowsForms.dllbeside each Windows head: two in the bundle, two in the tray, one in the Windows tool package.The idling has not been tried by hand, only by the tests.