Winform Control.Refresh - gegarandeerde synchrone?

De Control.Refresh methode van WinForms aanroepen wordt beschreven in MSDN als:

Forceert het besturingselement om het clientgebied ongeldig te maken en tekent zichzelf en alle onderliggende besturingselementen onmiddellijk opnieuw.

Ik ben debugging een intermitterende kwestie die lijkt te gebeuren wanneer het bijgevoegde display scan-out signalen schakelt (effectief veranderende resolutie), waarin een Control.Refresh lijkt niet te genereren de verwachte Control.OnPaint-oproep. Ik ben de applicatie aan het instrueren om meer informatie te krijgen, maar ik ben benieuwd of dit de runtime eigenlijk zou kunnen zijn om de OnPaint niet aan te roepen omdat het detecteert dat het display tijdelijk wordt weggelaten.

Dit lijkt mij onwaarschijnlijk, en ik verwacht dat ik een ander rookkanon zal vinden, maar ik heb gepost op de kans dat iemand anders dit in het wild heeft gezien en heeft een aantal aanbevelingen om dit aan te pakken.

 1
toegevoegd
Bekeken: 3
de bron

1 antwoord

Nee, het is niet gegarandeerd. Als het besturingselement geen scherm heeft om op te tekenen, wordt het lakbericht niet geactiveerd.

Maar zodra het besturingselement weer op het scherm staat, moet de verfboodschap opnieuw worden geactiveerd.

Probeer je debuginformatie te schilderen? Als het besturingselement niet op het scherm staat, wat verwacht u dan dat er gebeurt als u Vernieuwen belt?

1
toegevoegd
de bron
@holtavolt Ik heb het net geprobeerd om zeker te zijn, maar een timer doet niets anders met de verfgebeurtenis als de besturing buiten beeld is. OnMove, zeker, maar niet Paint.
toegevoegd de auteur LarsTech, de bron
@holtavolt Ja, ik doe het en het werpt OnPaint niet af. Wat je ook probeert te doen, je moet waarschijnlijk geen logica in de verf-gebeurtenis plaatsen.
toegevoegd de auteur LarsTech, de bron
@holtavolt Voor uw testdoeleinden, denk ik niet dat u het formulier "terug" naar het scherm moet verplaatsen. Dit zijn mijn wijzigingen: pastebin.com/qkw9gcvH .
toegevoegd de auteur LarsTech, de bron
Bedankt - Ik heb een aantal experimenten bedacht om te proberen dit te valideren, maar ze hebben me tegenstrijdige resultaten opgeleverd. Ik heb een eenvoudig formulier gemaakt, waarin OnMove naar console schrijft en een vernieuwing start. Terwijl je beschrijft, terwijl het formulier op het scherm staat, zie ik het Vernieuwen (en volgende OnPaint) vuren. Als ik het van het scherm verplaats (met behulp van de verplaatsingstoetsen links en links), wordt het vuren gestopt totdat een gedeelte van het formulier weer op het scherm verschijnt. Als ik echter een timer maak en laat de locatie van het formulier zodanig dat het naar links van mijn scherm scrolt, ontvang ik do OnMove/OnPaint-gebeurtenissen.
toegevoegd de auteur holtavolt, de bron
Heeft u een OnMove die een Refresh() uitvoert? Dat doe ik, waardoor de OnPaint schiet, zelfs als het besturingselement buiten beeld is.
toegevoegd de auteur holtavolt, de bron
Wat doen we anders? Dit is altijd bezig met het opstarten van de OnPaint: pastebin.com/Jc6hnVef - Ik ben het eens met de loggeologie van de verfgebeurtenis.
toegevoegd de auteur holtavolt, de bron
De oorzaak van de wortels bleek een diepere kaderkwestie te zijn met onze implementatie van opdrachtpatronen. Uw eerste antwoord dat de verf niet gegarandeerd is, is correct, markering als zodanig.
toegevoegd de auteur holtavolt, de bron