Ir al contenido


Foto

Mostrar en un mismo form dos ABM


  • Por favor identifícate para responder
6 respuestas en este tema

#1 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 24 agosto 2016 - 07:27

Hola Muchachos, vengo a ustedes para que me ayuden a decidirme...

Verán, no logro convencerme de que forma podría diseñar un form que forma parte de un sistema.

 

Mi intención es administrar usuarios, y agenda de contactos/clientela en un mismo form. ¿Porqué? Porque quisiera ahorrar en pantallas y porque la data es bastante básica.

 

Para el usuario solamente se necesita tener Nombre y una Clave que se genera de forma automática que no se puede modificar manualmente.

Para los contactos es lo típico: Nombre, Apellido, Dirección, Teléfono fijo y móvil.

 

Usuarios se espera un bajo número (es más, mayormente será uno, pero se necesita dejarlo abierto). La Agenda, que será compartida, irá creciendo a medida que llega clientela. Puede que sean 20, 50, 1000... no hay límite.

 

Tanto la modificación como eliminación ya sea de usuarios como de contactos son sucesos infrecuentes, (y contraproducentes... si no tienen los recaudos necesarios ya que se usan los usuarios y la agenda en buena parte del sistema).

Básicamente el usuario se limita mayormente a entradas... el resto el sistema trabaja prácticamente solo.

Encima, o afortunamente, estas entradas también pueden ser infrecuentes... no es un form que demande mucho uso. Puede que la parte de contactos se mueva más seguido. Aunque también cabe la posibilidad de que por ejemplo el usuario final arme su agenda con un listado de 20 personas de una y luego pasen semanas sin que necesite volver a "tocar". Además mi sistema tiene una vía automática de llenar algunos "tipos" de contactos, lo que le reduce el trabajo.

Como he dicho, es un sistema que casi se mantiene solo. Lo que más usará son otras cosas y que ya estuve viendo como encarar.

 

Lo de Bajas y Modificaciones me hace pensar en opciones que permitan ahorrar algo de espacio, y no mostrar tan "visualmente" o de forma llamativa esto. Una posibilidad que me tienta es la de diseñar una lista en la que se van a insertar frames a modo de items con la info.

Cada frame tendrá los edits necesarios y debajo de estos dos labels a modo de sencillos botones que diga "eliminar" y "modificar". Al presionar eliminar se marcará o resaltará el item de alguna forma que sugiera que está por eliminar, y en modificar habilita la edición y quedará marcado/resaltado en "modo edición". ¿Porqué lo pienso así? Pues, para dejarle una última posibilidad para deshacer o confirmar todos los cambios. Una manera bastante "ingeniosa" y algo llamativa para trabajar "en lote".

 

Las clases que trabajan por debajo de todo esto ya las tengo hechas, más es cosa de "presentación" lo que me no me termina de convencer.

 

Pensé inicialmente "separar" ambas cosas mediante un TPageControl... pero como que hoy ya es medio "mal visto" y al menos para el caso de los usuarios es como queda un buen espacio vacio.

La otra en que pienso es que pudiera aprovechar el form para pedir al usuario que seleccione con que desea trabajar y en base a eso habilitar edits para sus entradas (altas) y reaprovechar el espacio donde se presentará la lista para mostrar el listado de contactos o de usuarios según lo que se requiera.

Otra alternativa que he considerado es divir el form en 2: a la izquierda se trabaja con usuarios, y a la derecha con los contactos.

 

¿Que dicen ustedes? ¿Creen que para un usuario final se movería fácilmente en un form así? ¿O es mejor que cada cosa estuviera en su propio form? ¿Que les dice su experiencia?

 

Saludos,


  • 0

#2 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 26 agosto 2016 - 04:10

yo no perderia tiempo, hace uno general con los botones basicos y hereda otro form, ademas de las clases que utilizas para los datos.


  • 0

#3 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 26 agosto 2016 - 04:59

yo no perderia tiempo, hace uno general con los botones basicos y hereda otro form, ademas de las clases que utilizas para los datos.

 

Hola Nikolas,

Por el momento estoy haciendo una prueba de concepto, que toma un poco de cada cosa de mis ideas anteriores.

Mi idea consiste en un tener un frame abstracto que hará de item para la lista. Este frame ofrece unos labels a modo de botones para modificar y eliminar. Estos dos botones lo que hacen es cambiar el estado del item en cuestión. Como frame abstracto ofrece unos métodos virtuales y/o abstractos para que los frames que heredan de este lo aprovechen.

Esto permite por ejemplo que cuando se presione en "Eliminar", frame concreto aplique lo necesario.

Cada frame heredado, necesita ajustar el aspecto de diseño y me parece un concepto elegante.

 

Luego en el form tengo simplemente esto: se elije con que se desea trabajar y en base a ello, se habilitan cierta cantidad de controles para trabajar. Estos controles permiten agregar item a la lista.

Un poco más abajo, se deja otros controles que sirven para implementar un "Buscar", luego se tiene un TPanel+TScrollBox en el que se muestran los frames/items. El usuario puede ir agregando, borrando, modificando... Para finalizar simplemente Acepta o Cancela. El esquema del producto final sería algo así:

 

[Opcion 1 | Opcion 2]

[controles de entrada] [Agregar]

[cuadro de busqueda/filtro]

[listado]

[Aceptar][cancelar]

 

De esta forma en un mismo form se puede aprovechar el ABM para ambos... ¡o más!

 

La prueba de concepto no usa realmente las clases internas. Por ahora es para hacerme una idea, y si resulta llevo esto al programa. Adjunto una imagen de este "prototipo".

En esta prueba, para el frame 1 se usará un solo edit, para el otro se requeriere 2 (en la vida real son ligeramente diferente las cosas) En ejecución se verá la habilitación según se elija. El frame 0 es el abstracto.

El botón explorar lo que hará es recorrer la lista y analizar el estado de cada item y mostrar en un log el resultado. El estado no es más que un tipo así:


delphi
  1. TItemState = (isNew, isExist, isToDelete, isToModify);

isNew representa un item recién dado de alta

isExist representa un item ya previamente existente. No hay cambios

isToDelete representa un item que será eliminado

isToModify representa un item que será modificado

 

¿Cuál es el concepto detrás de esto?

Pues la idea es que al explorar la lista, uno puede reconocer que operaciones SQL ejecutar. Inicialmente, obviamente, la lista estará vacía por lo que cada alta y cuando se cree el frame/item su estado será isNew. Ante un Aceptar se recorre el listado y se ejecutarán tantos INSERTS como items.

En un momento posterior, cuando ya hay items, se lee desde la base de datos y al crear los items y cargarles los datos su estado no es isNew sino isExist.

 

Los botones "eliminar" y "modificar" cambiarán el estado. a sus respectivos "is".

Nuevamente, cuando se presione en Aceptar se recorre la lista y se ejecutarán las instrucciones que sean necesarias. Y naturalmente el Cancelar deshace los cambios.

 

Creo que este concepto y diseño de trabajo puede resultar incluso para llevarlo a otras etapas del programa. Tengo otras clases que también pueden ameritar un ABM así... Sobre todo para una parte que se espera una alta demanda de entrada rápida y un trabajo a lote algo pesado.

 

Si la prueba de herencia de items, marcha bien. Creo que puede ser una buena forma de trabajo.

 

Creo que se entiende la idea. ¿Que dicen?

 

Saludos,

Archivos adjuntos


  • 0

#4 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 27 agosto 2016 - 08:21

Actualizo el hilo.

Después de unos cuantos tropiezos con errores bastantes tontos y simples de corregir, he podido ejecutar la prueba de concepto y funcionando tal como lo esperaba.

Adjunto una imagen para que se hagan una idea.

 

Si me permito indicar un pequeño "truco" para que esto funcione, después de crear el frame y asignarle el Owner (necesariamente debe ser un control, no vale el nil) como el Parent, hay que sobreescribir el nombre del frame por vacio e inmediatamente reemplazarlo por un que no se haya usado. Esto es así ya que no se permite añadir un 2do objeto con un mismo nombre.

 

El truco en código de ejemplo:


delphi
  1. // Frame 1
  2. fme1 := TItemFrameConcreto1.Create(ScrollBox1);
  3. //fme1.Owner := ScrollBox1;
  4. fme1.Parent := ScrollBox1;
  5. fme1.Align := alCustom;
  6. if contador = 1
  7. then fme1.Top := 0
  8. else fme1.Top := pos;
  9. inc(pos,fme1.Height);
  10.  
  11. fme1.Name := '';
  12. fme1.Name := 'fme1' + IntToStr(contador);
  13. fme1.Campo1.Text := Edit1.Text;
  14. fme1.UpdateState(isNew);

Como prueba la considero satisfactoria. Obviamente, para la aplicación final se va a implementar un mejor código, y más seguro. También tendrá un mejor diseño estético... quizá en lugar de pintar edits ponga un borde que cambie de color... o en última otros efectos de resaltado no tan "chillones".

 

Saludos,

Archivos adjuntos


  • 1

#5 BDWONG

BDWONG

    Member

  • Miembros
  • PipPip
  • 28 mensajes

Escrito 27 agosto 2016 - 08:39

Delphius en lazarus utilizas algún componente para personalizar las interfaces gráficas en tus proyectos?


  • 0

#6 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 27 agosto 2016 - 09:22

¿Te refieres a algo como Skins?

Si es eso a lo que preguntas, mi respuesta es No.

 

Empleo los tradicionales, controles comunes. O en su defecto alguno que trae CodeTyphon que extiende sus capacidades.

Para el proyecto que tengo en mano por caso estoy empleando los de la suite BGRA Controls y el TGuiPanel de ASIO/VST GUI. Combinando y acomodando controles, apoyándome en TFlowPanel, alineaciones y/o constraint es posible darle una buena estética.

 

Por ejemplo pones un TGuiPanel, le das el borde y con estilo redondeado en las equinas y color a gusto, y pones un label en su interior con align alTop. Le configuras el mismo color al label que al borde o uno de un tono similar y ya tienes una especie de GroupBox con un "Caption" a todo color como header y/o título.

 

Y el TBGRAButton es un botón con capacidades de diseño y efectos interesantes.

 

La imaginación es el límite.

 

Saludos,


  • 1

#7 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 27 agosto 2016 - 09:58

Por cierto, y en esta imagen se ve el efecto negrita cuando se pasa el mouse sobre el "modificar" y/o "eliminar"

Bien usado, este efecto "minimalista" puede ayudar. Al menos así lo veo yo.

 

Archivos adjuntos


  • 0




IP.Board spam blocked by CleanTalk.