change - ¿Diagrama de ciclo de vida de control personalizado de WPF?
title bar color wpf (2)
- Inicializado se llama solo una vez y primero
- OnApplyTemplate se llama segundo, y siempre que la plantilla cambie
- Se llama a Loaded cuando el control está listo para ser mostrado y cada vez que ciertos contenedores vuelven a cargar su contenido (especialmente el intercambio entre TabItems)
- Se llama a IsVisibleChanged cada vez que cambia la visibilidad y después de cargarse
Unloaded normalmente no se llama a menos que esté en un elemento de tabla y cambie a otro.
Los eventos cargados / descargados no se llaman cuando lo esperaría desafortunadamente, y esto hace que sea difícil saber cuándo su control debe disponer de sus recursos. Además, nunca he logrado encontrar una lista de los contenedores que descargan y vuelven a cargar su contenido.
Estoy buscando un diagrama que sirva como referencia para mostrar el orden de los eventos y las anulaciones que se reciben para los controles personalizados de WPF que se derivan de clases comunes como FrameworkElement, UIElement, Control, ContentControl, Decorator, etc.
Estoy particularmente interesado en los eventos y anulaciones que tienen que ver con el proceso de control que se hace visible y listo para interactuar. En otras palabras, no estoy tan interesado en este diagrama que muestra los eventos que podrían tener que ver con que el usuario interactúe con el control después de que esté listo para interactuar, como cosas como MouseLeftButtonDown.
Lo que estoy buscando es algo como este diagrama (diagramas como estos explican el ciclo de vida de una ventana o aplicación de WPF) pero para controles personalizados.
También he visto esta página , que, en mi opinión, la hace parecer demasiado simplista. Esa página parece decir básicamente que solo hay eventos Initialized
, Loaded
y Unloaded
. Para ilustrar, algunos de los eventos / anulaciones generales que he necesitado utilizar en controles personalizados incluyen:
- Constructor
-
Loaded
-
UnLoaded
-
IsVisibleChanged
-
OnApplyTemplate
Junto con anulaciones un poco más especializadas como OnOpened
de Popup y OnOpened
Expander, etc.
El problema que tengo es que olvido cuándo puedo hacer cosas como VisualStateManager.GoToState(...)
( OnApplyTemplate
es la primera oportunidad real que creo). Y también sigo descubriendo eventos que necesito usar, como IsVisibleChanged (este evento resultó necesario cuando necesitaba un control para hacer un cambio de estado de "recarga / actualización" cuando el usuario regresa a la pestaña que contiene mi control) . Entonces me pregunto si hay otros eventos / anulaciones similares a los que realmente debería prestar atención para un control personalizado. Aquí es donde un diagrama que muestra estas cosas en relación entre sí ayudará.
Teniendo en cuenta este tipo de eventos / anulaciones, este gráfico de Silverlight está bastante cerca de lo que estoy buscando, pero para WPF . Algunos de los comentaristas en esa publicación dicen que los eventos / anulaciones de WPF son diferentes a los de Silverlight. Si es así, ¿podría indicarme un diagrama similar?
Para ilustrar mejor la necesidad de un diagrama de este tipo, considere la siguiente secuencia de eventos que acabo de presenciar en un control personalizado que se deriva de ContentControl:
- La aplicación se inició. (Mi control personalizado está en una pestaña diferente a la pestaña inicial).
- Llamada
Initialized
evento llamada -
Loaded
llamada de eventoLoaded
llamada - (Hago clic en la pestaña que contiene mi control personalizado)
-
IsVisibleChanged
ha llamado a la devolución de llamada del evento IsVisibleChanged -
OnApplyTemplate
anulación llamada -
Loaded
llamada de eventoLoaded
llamada -
Loaded
devolución de llamada del eventoLoaded
volvió a llamar -
Loaded
devolución de llamada del eventoLoaded
se llama tercera vez consecutiva - (El control ahora es totalmente visible y está listo para interactuar con)
Dudo que exista un diagrama tan completo. ¿Qué tal si lo haces tú mismo? Sobrescriba todos los métodos y / o eventos en los que esté interesado y coloque un Trace.WriteLine(new StackFrame(1).GetMethod().Name);
en cada anulación. Su salida le dirá en qué orden fueron llamados.