A ver, una consulta rápida
Tengo un formulario que edita los campos de una tabla x. La tabla tiene tantos campos que a duras penas caben todos en el formulario de manera que implementé 2 formularios auxiliares para editar algunos campos que solo se usan ocasionalmente.
Lo que hago es abrir la tabla, ponerla en modo edición o inserción según el caso, y luego abro el formulario, el cual esta ligado mediante Datasources con sus campos correspondientes. Los formularios auxiliares tienen sus campos (dbedits) también ligados a la misma tabla de manera que mediante unos botones en el formulario principal abro el auxiliar que se requiera segun el caso y ahi edito los campos. Hasta aquí no hay problema, pero ahorita revisando, se supone que los formularios auxiliares tendrán 2 botones: "cancelar" y "aceptar". En el caso de aceptar no hay problema con simplemente cerrar el formulario los datos ya están "guardados" en el registro que se está editando o insertando, sin embargo en el caso de "cancelar" no se me ocurre una idea "elegante" de borrar todos los cambios hechos a los campos (recordemos que el registro aún no ha sido posteado ya que el Post lo hace el formulario principal) que no sea la de recorrer los databindings de los controles de estos formularios y limpiar manualmente sus valores. Un simple "for cada control en el formulario limpia los datos del campo que tenga ligado". Igual y me estoy complicando mucho...pero a lo mejor a a alguien se le ocurre una solución mas elegante. Saludos... |
Si he entendido bien, son componentes asociados a un datasource, entonces para "limpiarlos" será suficiente un cancel, no?
|
Yo te recomendaria usar un ScrollBox, asi en un solo formulario tendrias todos los campos que necesitas.
Adicional al ScrollBox, tambien he usado GroupBox 's para agrupar los TEdit |
Si Casimiro, pero si hago un cancel elimino el total de los campos lo cual no es lo que quiero. Sino digamos que un formulario "principal" edita los 50 principales campos y un auxiliar edita unos 5 o 7 ocasionales (que casi siempre quedan vacios), si hago un cancel en el auxiliar voy a eliminar el contenido de los 50 campos que si deben llevar datos. La solución del scrollbox no funciona porque los campos adicionales a editar no todos son tedits, sino hay memos y otras cosas. Como ya les comenté tengo ya una solución solo quiero explorar alguna otra alternativa.
|
No había entendido bien la pregunta. Creo que no te queda más que recorrerlos. Puede que te venga bien añadirle un valor en la propiedad 'tag (por ejemplo), para diferenciar los que están en cada form.
|
1 Archivos Adjunto(s)
Cita:
Te dejo un ejemplo, si te sirve............. |
Cita:
Con un ADOTable sería así:
Te adjunto las 2 funciones que aparecen; ExistProp y GetPropAsString; Sólo te queda añadir al USES la unit TypInfo.
|
Estimado AzidRain, te recomiendo darle una repasada a la guía de estilo, en particular, lo correspondiente al título de los mensajes.
// Saludos |
Gracias por el jalón de orejas Román, al final esto fue lo más compacto que pude hacer:
|
Hola AzidRain
Yo cuando tengo casos de formularios que tienen muchos datos, hago 2 cosas: 1era: Organizar todos los campos en TPageControls, y creo tantas paginas como necesite en el formulario, una sola barra de herramientas, puesto que se trabaja en la misma tabla. 2do: Deje de utilizar dbedits, y los sustitui por edits normales o currency edtis para campos floats e intedits para enteros, datetimepickers para fechas, pero bueno que logro con esto, es que mando a guardar los datos a traves de un tquery, con el cual no tengo la tabla cargada en memoria si no que solo consulto el registro que quiero editar y le hago el update o insert en caso de registros nuevos. No se si logras entenderme, la dificultad que esto me provocaba era continuos deadlocks por trabajar directamente en la tabla, sobre todo cuando mas de un usuario estaba trabajando en el sistema, con las querys puedo usar transacciones y controlar el grabado de los datos. Tambien me provocaba un error que no se podian actualizar los datos porque otro usuario habia modificado el registro, eso lo resolvi con lo que te he comentado Saludos |
La elección natural es usar los tabpages pero en verdad, estoy hablando de un megaformulario que casi ocupa el total vertical de la pantalla. Mientras que los campos que hacen falta son unos 5 a lo mucho, la pega es que esos campos son Memos que como te decia, rara vez se llegan a ocupar, asi como lo resolvi me funciona y pues es para una "adición" de emergencia de mi cliente (la cual no pretende pagar..jijiji) así que para otra ocasión le echo mas crema a mis tacos.
|
Cita:
Pues al trabajar con la propiedad ControlCount solo estamos iterando con todos los controles(componentes que son Controles) de nuestro formulario, en cambio si trabajamos con ComponentCount tambien estamos trabajando con todos los componentes del formulario ya sean controles o no, sean visuales en tiempo de ejecucion o no. He ahí la diferencia.;). Saludos...:) |
La franja horaria es GMT +2. Ahora son las 04:52:58. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi