DIMcImageEvents_ImageChangedEventHandler Delegate

Public Delegate Sub DIMcImageEvents_ImageChangedEventHandler ( 
	Image As McImage,
	Frame As McFrame
)

When image pixel data is changed by an operation such as McImage.PutPixel, McImage.PutLine, McImage.PutArea, McRegionAccess.PutPixel, McRegionAccess.SetToConstant, etcetera, the bounding rectangle of the changed pixels is noted and this event is fired. But firing and especially servicing this event is costly, and pixel data can be changed frequently (e.g., in a loop that does an McRegionAccess.PutLine on each line ofa an image). Thus, to avoid severe performance degradation, image processing alogorithms are (or should be) surrounded by calls to McImage.BeginEndUpdateBlock. When BeginEndUpdateBlock(True) is called to enter an update block, then subsequent changes to pixel data are just accumulated. If writes occur to multiple frames during the update block, then the written-to rectangle for each frame is kept. Finally, when an outermost BeginEndUpdateBlock(False) call is made, thereby leaving the update block, a single accumulated ImageChanged event is fired. In the case where only one frame was modified the Frame argument holds the McFrame object that was modified. The event handler can determine the rectangle that was written to by getting the McFrame.LastModifiedRect property, and the frame index of the modified frame is given by the McFrame.FrameIndex property. In the case where multiple frames were modified during the update block, then only one ImageChanged event is fired, but this event will be preceeded by a MultipleFramesChanged event that identifies all frames that were changed. The Frame argument passed with the single ImageChanged event will be the active frame (the default McImage.Frame) if it was among those modified, otherwise it will be a random frame from among those modified. Most ImageChanged event handlers only care that the image has changed, not which frames have done so. Event handlers that do care about which frame has changed will usually only be checking to see if the active frame was the one that changed. In both of these cases, there is no need to handle the MultipleFramesChanged event. Note that this event may be blocked by setting the McObject.UserFlags mcobjUserFlagMinimizeProcessing bit in the firing McImage operator's backing McObject (see McEngine.McObject).