PowerBuilder
Listas que piensan: validación DDDW y DDLB en PowerBuilder 2025 R2
0 visualizaciones
Una lista desplegable no valida por sí sola el significado del dato. La interfaz puede mostrar un texto correcto mientras el valor almacenado es nulo, inexistente, inactivo o incompatible con otra selección.
Qué demuestra el laboratorio
Demo_validacion_dddw enfrenta dos mecanismos clásicos de PowerBuilder bajo las mismas condiciones. El DropDownDataWindow (DDDW) presenta datos provenientes de otro DataWindow, separa la columna visible de la columna almacenada y admite filtros dinámicos. El DropDownListBox (DDLB) mantiene una relación directa entre etiquetas y códigos definida en la propia columna.
La ventana w_laboratorio_validacion carga todos los catálogos en memoria, aplica siete escenarios reproducibles, inspecciona el valor interno de cada control y actualiza un monitor con el resultado de la validación. Esto permite estudiar el comportamiento sin SQLCA, servidor ni datos externos.
La pantalla real reúne casos de prueba, formulario, monitor, inspector del valor, tubería de validación e inyección controlada de datos incorrectos.
DDDW
Ideal para catálogos con varias columnas, valor mostrado distinto del almacenado, filtros y relaciones dependientes.
DDLB
Más ligera para listas pequeñas y estables, con pares de etiqueta y código configurados directamente en la columna.
Validación explícita
Comprueba obligatoriedad, pertenencia al catálogo, estado activo y coherencia entre controles dependientes.
Los objetos que sostienen la demostración
Del cambio del usuario al diagnóstico
El evento itemchanged utiliza el nombre de la columna para decidir si debe recalcular la DDDW dependiente. Después delega en funciones breves: registra el cambio, ejecuta la tubería completa y refresca la información visible. El botón Ejecutar validación agrega una llamada a AcceptText() antes de repetir el mismo proceso.
Script clave 1: una DDDW realmente dependiente
La función obtiene el DataWindowChild de ciudades, elimina el filtro anterior, aplica el departamento seleccionado y registra cuántas opciones continúan disponibles.
GetChild("ciudad_id", ldwc_ciudades) entrega acceso al DataWindow que alimenta la columna. La función comienza restaurando todas las filas con SetFilter("") y Filter(); así evita encadenar un filtro nuevo sobre uno anterior. Luego crea una de dos expresiones:
• departamento_id = n conserva únicamente las ciudades relacionadas con la selección actual.
• ciudad_id = -1 simula deliberadamente una lista vacía para probar ese caso límite.
Script clave 2: una tubería que explica el error
La tubería no se limita a verdadero o falso: conserva el resultado de cada regla y lo traduce en un estado comprensible para el usuario.
of_validar_formulario consulta por separado departamento, ciudad, categoría y prioridad. Solo considera válido el formulario cuando los tres campos obligatorios son válidos y la prioridad es válida o nula. Después aplica un orden deliberado de diagnóstico:
• Valor inactivo del departamento.
• DDDW de ciudades sin filas.
• Ciudad ajena al departamento seleccionado.
• Ausencia de un valor obligatorio.
• Cualquier código no encontrado.
Este orden evita mensajes genéricos. El monitor puede mostrar Advertencia · lista vacía o Error de dependencia en lugar de ocultar todas las causas detrás de un simple “dato inválido”.
Siete casos que rompen las suposiciones
Por qué el valor mostrado no basta
En una DDDW, dddw.displaycolumn controla lo que ve la persona y dddw.datacolumn determina lo que realmente se guarda. En el formulario, el departamento muestra Tecnologías de la Información, pero almacena el identificador 10. El inspector pone ambos valores lado a lado para hacer visible esa diferencia.
Las DDLB siguen el mismo principio mediante pares como Prémium / PRE o Alta / A. El NVO no valida las etiquetas; valida los códigos almacenados. Esta decisión mantiene las reglas estables aunque cambie el texto presentado al usuario.
La corrección visual que también es arquitectura
El DataWindow principal está diseñado como formulario libre, con controles distribuidos verticalmente. Por eso d_formulario_validacion utiliza processing=0. Con una presentación tabular, las mismas coordenadas se interpretan de otra forma, los campos se extienden horizontalmente y varias opciones quedan fuera del área visible.
Cómo recorrer el demo
• Abra el laboratorio y observe la selección válida inicial.
• Cambie el departamento y confirme que la lista de ciudades se recalcula.
• Recorra los siete casos con Anterior y Siguiente.
• Seleccione una columna en Romper validación, escriba un valor interno y pulse Inyectar valor de prueba.
• Compare el valor almacenado, el valor mostrado, las filas de la lista y el diagnóstico.
• Revise la bitácora inferior para reconstruir cada cambio y validación.
Conclusión
Este laboratorio convierte un tema que suele permanecer oculto dentro del DataWindow en una experiencia observable. DDDW y DDLB no compiten: resuelven necesidades distintas. La primera destaca en catálogos ricos y dependientes; la segunda, en conjuntos pequeños y previsibles. En ambos casos, la confiabilidad aparece cuando el código valida el valor almacenado, la relación con su catálogo y el contexto que le da significado.
El patrón es reutilizable: funciones cortas, catálogos aislados, estados de error específicos y un monitor que muestra lo que realmente sucede. Ese enfoque facilita probar reglas antes de conectarlas a una base de datos y reduce sorpresas cuando el formulario llega a producción.