Pedir Ingreso de Datos en TEdit Flotante

[[BlueSteel]]

Hola Amigos

Tengo una consulta y/o duda... realmente no se si se puede realizar, necesito seleccionar un item para anular, pero cuando lo selecciono, debo ingresar la observacion de por que se esta anulando, por lo cual se me ocurrio que podia poner un componente como el Tedit o Tmemo pero algo asi como flotante, es decir, como si fuera otro formulario, pero en realidad no lo quiero como otro formulario...

Esto se puede hacer pero sin formulario adicional...

o tendre que hacerlo en un formulario distinto y a ese formulario cambiar los atributos de borde para que no se vean???

Espero que me hallan entendido...

Salu2

[roman]

Empezado por BlueSteel

Espero que me hallan entendido...

No mucho eh? ¿Dónde seleccionas el registro? ¿Qué significa anularlo? ¿Dónde se guarda la razón para anularlo? ¿Es un campo del registro? De ser así, ¿por qué no lo pones como campo de la rejilla, si es que tienes una rejilla? Y, ¿por qué no quieres una ventana aparte?

// Saludos

[[Caral]]

Hola
No seria algo como un componente en ejecucion?.
Aqui tienes un ejemplo, tal vez te sirva.
Saludos

[oesqueda]

No es tan sencillo como ocultar un TPanel

Código Delphi [-]
panel.visible := false;

y cuando cambien lo que necesitas

Código Delphi [-]
panel.visible := true;
  self.height := 300; //Alta del formulario.

Digo, facil y elegante jejeje

[[BlueSteel]]

Paso a explicar lo solicitado:

- Tengo una JvDBGrid, donde muestro varios registros Habiles
- Tengo 1 boton que al pinchar cambia el estado de un registro de Habil a Anulado
- Tengo otro JvDBGrid, donde muestro los registros que estan Anulados

Bueno, al presionar el boton para cambiar el estado de Habil a Anulado, debe pedir que ingrese alguna observacion o motivo por que se esta anulando..

lo que yo queria hacer es solicitar esa información por medio de un Tmemo, pero que apareciera centrado en la pantalla (facil) pero como flotante... y bueno, se me ocurrieron 2 formas de solucionarlo...

Una solucion fue poner dicho componente en otro Form al que le cambie el BordeStyle a bsSingle. Entonces cuando me pide ingresar la información llamo al Form e ingreso el dato requerido... me bloquea todas las otras pantallas para que lo oblique a ingresar información... y eso me resulta bien.

Otra solucion fue poner el Tmemo en un TPanel que este oculto...entonces cuando anulo, muestro el TPanel para ingresar la información y tambien bloqueo los demas componentes para que no ingrese nada en otro lado y forzarlo a ingresar el motivo de la anulacion...

Asi lo solucione.. ambos metodos me funcionaron...

igual, gracias...

Salu2

[[Chris]]

Bueno, muchos ya habrán notado que yo siempre ando pensado en la usabilidad y diseño de las interfaces.

Creo que más bien tu duda va por ahí, por la usabilidad e intuitividad de la interfaz. Existen aplicaciones que te pueden dar una idea del cómo hacer lo que tú buscas. Talvez lo mejor sería que muestres una ventana con forma de balloontip por debajo del botón anular. En ese formulario puedes pedir la información extra y colocar un botón para que el usuario confirme la operación. De esta manera, estarías matando dos pájaros del mismo tiro. Solucionaría el problema de diseño y te evitarías perturbar el flujo mental del usuario mostrándole la típica ventana de dialogo "¿Realmente desea ...?" pues ya la misma información ingresada en el Balloontip es en sí una confirmación.

Saludos,
Chris

[[Chris]]

Empezado por BlueSteel

Una solucion fue poner dicho componente en otro Form al que le cambie el BordeStyle a bsSingle. Entonces cuando me pide ingresar la información llamo al Form e ingreso el dato requerido... me bloquea todas las otras pantallas para que lo oblique a ingresar información... y eso me resulta bien.

Otra solucion fue poner el Tmemo en un TPanel que este oculto...entonces cuando anulo, muestro el TPanel para ingresar la información y tambien bloqueo los demas componentes para que no ingrese nada en otro lado y forzarlo a ingresar el motivo de la anulacion...

Asi lo solucione.. ambos metodos me funcionaron...

Mal, Mal, Mal, Mal..... amigo Blue . Eso no es bueno hacerlo. De esa forma los usuarios verán a tu aplicación como un verdugo y no como una amiga, una asistente que le ayuda a realizar su trabajo.

[[Delphius]]

Empezado por Chris

Mal, Mal, Mal, Mal..... amigo Blue . Eso no es bueno hacerlo. De esa forma los usuarios verán a tu aplicación como un verdugo y no como una amiga, una asistente que le ayuda a realizar su trabajo.

¿Cuál es tu problema en como diseñen los otros sus aplicaciones? Cada uno es dueño... en otro hilo "criticaste" la pantalla de otra persona diciendo que así, que asa... que esto o lo otro.

Si se necesita centrar la atención al usuario, una buena manera de hacerlo es justamente inhabilitando algunas cosas y forzando a que confirme algo. Para esas cosas es que justamente existen, por ejemplo, las ventanas modales.

Si la idea es pedir cierta confirmación de lo que se está por hacer, con más razón. Y no por ello es la aplicación va a ser un verdugo. Simplemente se trata de un paso crítico que requiere de la debida atención del usuario y no de algo, necesariamente, "cool" como un ballontip que uno puede obviar, con toda razón, ni prestarle suficiente atención.

Saludos,

[oesqueda]

En realidad nadie en este hilo tenemos la razon.

Hay pautas que indican como debemos diseñar la aplicacion en Windows, yo para Windows 2000 compre un libro que explica cada control y como debe usarse, claro esta que este libro es de mi Tio Bill Gates y su equipo de Microsoft.

La teoria dice tienes dos opciones:

1. Una ventana modal.
2. Que el control de la explicacion este presente pero enabled := true.
si se activa debes validar antes de salir de esa ventana.

Pero como dijo Delphius, cada quien diseña como quiere.

Les paso un link interesante:

http://wiki.answers.com/Q/What_is_Mi...erface_testing

Ni digo nada de Memo puertas, ya que el me ha dado de comer jejejeje

[[Chris]]

Empezado por oesqueda

Hay pautas que indican como debemos diseñar la aplicacion en Windows, yo para Windows 2000 compre un libro que explica cada control y como debe usarse, claro esta que este libro es de mi Tio Bill Gates y su equipo de Microsoft.

Microsoft es el menos adecuado para hablar de diseño de interfaces, creemelo! Tampoco yo lo soy. Pero muchos expertos en la materia coinciden en lo que te acabo de decir. Que últimamente estén haciendo las cosas mejor, ya es otra cosa. Pero por lo menos, hasta Windows 7 y Ribbon sus diseños de interfaces dejaban mucho que desear.

[[Chris]]

Empezado por Delphius

¿Cuál es tu problema en como diseñen los otros sus aplicaciones? Cada uno es dueño... en otro hilo "criticaste" la pantalla de otra persona diciendo que así, que asa... que esto o lo otro.

Simplemente doy consejos amigo. Allá el que quiera seguirlos o no. En la misma manera que damos consejos de cómo escribir el código de X rutina, a mí también me gusta dar consejos de diseño de interfaces.

Empezado por Delphius

Si se necesita centrar la atención al usuario, una buena manera de hacerlo es justamente inhabilitando algunas cosas y forzando a que confirme algo. Para esas cosas es que justamente existen, por ejemplo, las ventanas modales.

Las ventanas modales no son buenas. Si has de usarlas, debe ser en la menor medida posible. Estoy seguro que el paso de anular no es tan crítico para usarlas.

Empezado por Delphius

Si la idea es pedir cierta confirmación de lo que se está por hacer, con más razón. Y no por ello es la aplicación va a ser un verdugo. Simplemente se trata de un paso crítico que requiere de la debida atención del usuario y no de algo, necesariamente, "cool" como un ballontip que uno puede obviar, con toda razón, ni prestarle suficiente atención.

Saludos,

A cómo dije anteriormente, el mismo hecho que el usuario ingrese una razón del por qué hizo la anulación, ya es en sí una confirmación de lo que desea hacer. Ergonómicamente, si quieres obviar algo es porque no lo deseas. Creeme que un Balloontip que se muestre junto al botón "Anular" llamará más la atención del usuario que una ventana modal mostrada al centro de la pantalla, que ni siquiera estará cerca de foco visual y mental del usuario a cómo lo estará el botón "anular" y el Balloontip contiguo a él.

Saludos,
Chris

[roman]

Empezado por Chris

Simplemente doy consejos amigo. Allá el que quiera seguirlos o no.

Yo también lo veo así, como consejos; no creo que deba ser motivo de querella.

Pero eso no quita que en este tópico en particular, me parece un tanto radical tu opinión.

Las aplicaciones de Windows han usado desde siempre los cuadros modales para introducir información que se requiere de forma obligatoria, y por lo que describe BlueSteel, así debe ser, obligatoria.

Seguir este estándar de facto de Windows no veo en qué forma puede perturbar el flujo mental del usuario, como sí lo haría, en mi opinión, un elemento distractor como el balloon, que más dará la idea de algo opcional y poco importante.

// Saludos

[[Delphius]]

Empezado por roman

Las aplicaciones de Windows han usado desde siempre los cuadros modales para introducir información que se requiere de forma obligatoria, y por lo que describe BlueSteel, así debe ser, obligatoria.

Seguir este estándar de facto de Windows no veo en qué forma puede perturbar el flujo mental del usuario, como sí lo haría, en mi opinión, un elemento distractor como el balloon, que más dará la idea de algo opcional y poco importante.

// Saludos

Efectivamente por eso es que yo decía que no tiene de nada de malo, erroneo, ni de verdugo hacer uso de ventanas modales. PARA ESO HAN SIDO DISEÑADAS y así es como funciona una aplicación estándar en Windows.

Poner un ballon no sólo da la idea de algo opcional y de poca importancia sino que al tercer día el usuario simplemente no lo verá, su cabeza se programará para "rechazar" ese ballon. Su ojos quizá los capten, pero su actividad será tan mecánica que el cerebro lo pasará del algo.
Si bien esto también sucede (y sucederá) con una ventana modal al menos el usuario debe verse OBLIGADO a hacer confirmar, y no hay modo de saltearse esa pantallita que nada tiene de molesta.

Saludos,

[[BlueSteel]]

Empezado por Chris

Mal, Mal, Mal, Mal..... amigo Blue . Eso no es bueno hacerlo. De esa forma los usuarios verán a tu aplicación como un verdugo y no como una amiga, una asistente que le ayuda a realizar su trabajo.

Hola Chris...

sorry pero no habia podido ingresar a responder... estaba bloqueando otros sistemas ....

bueno, lamentablemente cuando tienes cierto tipo de usuarios que lo único que hace es apretar botones y no acordarse de lo que hacen debes recurrir a ciertas medidas de seguridad, y sobre todo cuando el bloquear un registro puede producir "bloquear el acceso a un Estadio" (valga la redundancia)

Se que existen otras medidas y creeme que me pongo en el papel de todos los usuario (y por lo mismo trato de hacerlo a prueba de ellos)

Casi todos los sistemas los realizo por iniciativa y/o necesidad para agilizar los procesos, pero en donde las áreas comprometidas no te entregan los requisitos ( o te los cambian a cada rato) y tu como programador, analista e ingeniero debes decidir que hacer, como hacer y cuando hacerlo... debes tomar medidas a veces un poco drasticas y sobre todo preventivas...

[roman]

Y, ¿por qué la renuencia a usar un cuadro de diálogo?

// Saludos

[[BlueSteel]]

Empezado por roman

Y, ¿por qué la renuencia a usar un cuadro de diálogo?

// Saludos

bueno... simplemente por que hay momentos que estas bloqueado y necesitas realizar algo urgente y lo primero que se te ocurre lo aplicas...(que no siempre es la solución más optima ) y cuando decides cambiar por algo mejor te ves con otros trabajos que hacer que dices... si ya esta funcionando para que lo voy a cambiar sobre todo cuando el tiempo apremia....

Salu2