Saludos al foro.
Les cuento mi problema, estoy montando una ayuda contextual basada en una idea de Shordi publicada en el foro antiguo. Básicamente cuando un usuario pulsa F1 en un formulario, este llama a una clase que busca el componente que tiene el foco y muestra un mensaje. La premisa básica es que el par "Form.Name-Control.Name" es único. Todo iba bien hasta que cambié de GTK3 a QT5.
La rutina para recorrer los controles dentro del Form no solo devuelve los controles definidos, también devuelve sus controles internos. Por ejemplo, para un ButtonBox devuelve el ButtonBox, un TextBox, un DrawingArea y dos ToolButton. Mi problema es que necesito saber el nombre del control que tiene el foco, por ejemplo en el caso del ButtonBox en GTK3 lo hace correctamente pero en QT5 me da el foco en el TextBox del ButtonBox.
Como una imagen vale más que mil palabras les dejo un programa para visualizar el problema. Basta con poner el foco en cualquier control y pulsar F1. Se carga un Listbox con el nombre de cada control, su tipo y el contenedor. También dos etiquetas, una con el componente gráfico que se usa y otra con el control que tiene el foco.
Cambiando el componente gráfico en el menú "Depuración - Componente GUI" del IDE se ve la diferencia de funcionamiento.
Ando un poco despistado con esto, se agradece cualquier idea.
Un saludo, Harpo.
Se me olvida, uso Gambas 3.16.1 en un Xubuntu 20.04.2.
Les cuento mi problema, estoy montando una ayuda contextual basada en una idea de Shordi publicada en el foro antiguo. Básicamente cuando un usuario pulsa F1 en un formulario, este llama a una clase que busca el componente que tiene el foco y muestra un mensaje. La premisa básica es que el par "Form.Name-Control.Name" es único. Todo iba bien hasta que cambié de GTK3 a QT5.
La rutina para recorrer los controles dentro del Form no solo devuelve los controles definidos, también devuelve sus controles internos. Por ejemplo, para un ButtonBox devuelve el ButtonBox, un TextBox, un DrawingArea y dos ToolButton. Mi problema es que necesito saber el nombre del control que tiene el foco, por ejemplo en el caso del ButtonBox en GTK3 lo hace correctamente pero en QT5 me da el foco en el TextBox del ButtonBox.
Como una imagen vale más que mil palabras les dejo un programa para visualizar el problema. Basta con poner el foco en cualquier control y pulsar F1. Se carga un Listbox con el nombre de cada control, su tipo y el contenedor. También dos etiquetas, una con el componente gráfico que se usa y otra con el control que tiene el foco.
Cambiando el componente gráfico en el menú "Depuración - Componente GUI" del IDE se ve la diferencia de funcionamiento.
Ando un poco despistado con esto, se agradece cualquier idea.
Un saludo, Harpo.
Se me olvida, uso Gambas 3.16.1 en un Xubuntu 20.04.2.
Archivos adjuntos
Última modificación: 13-06-2021, 10:38 por Harpo.
Bueno... Por un lado me encanta eso de que mis viejas ideas inspiren a cerebros nuevos... Me coloco una pegatina de estrellita en toda la matayota.
Sobre el problema:
a) Los eventos de teclado son eventos que se "propagan hacia abajo". Quiere eso decir que primero se inspeccionan por el más alto nivel (Form) y luego por los controles que se contenga.
b) La propiedad "Group" de la clase control lo que permite es que varios controles compartan el mismo evento.
c) La función Last nos devuelve el nombre del último control que ha levantado un evento.
Con estas tres cosas en cuenta: El nombre de quién tiene el foco lo da Last() pero no podemos usarlo con form_Keypress, porque solo obtendremos el nombre del formulario.
Agrupemos los controles susceptibles de tener ayuda en un grupo con la propiedad group. Por ejemplo group = WithHelp (en el ide, que esa propiedad es sólo para el ide) y luego busquemos la ayuda o lo que sea con el evento WithHelp_Keyrelease(). (Evitas repeticiones si el usuario tiene la tecla pulsada).
Te adjunto el ejemplo corregido.
Saludos
Otra cosita: La búsqueda en una base de datos de ayudas o donde sea que las ubiques necesita la clave única de nombre del form-nombre del control... pero eso puede ser un problema, porque atas la consecución de la ayuda (elemento de la capa de datos) a un elemento del diseño (capa de software programa) y la independencia de esas capas siempre es aconsejable.
Puede ser interesante que, además de lo que arriba te sugiero, añadas una "Clave de ayuda" en la propiedad Tag de los controles. Así, independizas el sistema de búsqueda con sus propias claves y todo te será más sencillo de mantener de cara al futuro.
Saludos
Sobre el problema:
a) Los eventos de teclado son eventos que se "propagan hacia abajo". Quiere eso decir que primero se inspeccionan por el más alto nivel (Form) y luego por los controles que se contenga.
b) La propiedad "Group" de la clase control lo que permite es que varios controles compartan el mismo evento.
c) La función Last nos devuelve el nombre del último control que ha levantado un evento.
Con estas tres cosas en cuenta: El nombre de quién tiene el foco lo da Last() pero no podemos usarlo con form_Keypress, porque solo obtendremos el nombre del formulario.
Agrupemos los controles susceptibles de tener ayuda en un grupo con la propiedad group. Por ejemplo group = WithHelp (en el ide, que esa propiedad es sólo para el ide) y luego busquemos la ayuda o lo que sea con el evento WithHelp_Keyrelease(). (Evitas repeticiones si el usuario tiene la tecla pulsada).
Te adjunto el ejemplo corregido.
Saludos
Otra cosita: La búsqueda en una base de datos de ayudas o donde sea que las ubiques necesita la clave única de nombre del form-nombre del control... pero eso puede ser un problema, porque atas la consecución de la ayuda (elemento de la capa de datos) a un elemento del diseño (capa de software programa) y la independencia de esas capas siempre es aconsejable.
Puede ser interesante que, además de lo que arriba te sugiero, añadas una "Clave de ayuda" en la propiedad Tag de los controles. Así, independizas el sistema de búsqueda con sus propias claves y todo te será más sencillo de mantener de cara al futuro.
Saludos
Archivos adjuntos
Última modificación: 13-06-2021, 11:13 por Shordi.
No podemos regresar
Grande Shordi!!!
Las buenas ideas siempre inspiran. Gracias por la ayuda, tiene usted unas cervezas pagadas. Una solución elegante y sencilla.
La ayuda se almacena en XML y se gestiona desde una clase únicamente. Había pensado añadir una "clave de ayuda" como dices, pero suelo utilizar nombres explícitos en los controles y formularios y en principio no lo he visto necesario.
Gracias una vez más, un saludo.
Las buenas ideas siempre inspiran. Gracias por la ayuda, tiene usted unas cervezas pagadas. Una solución elegante y sencilla.
La ayuda se almacena en XML y se gestiona desde una clase únicamente. Había pensado añadir una "clave de ayuda" como dices, pero suelo utilizar nombres explícitos en los controles y formularios y en principio no lo he visto necesario.
Gracias una vez más, un saludo.
Harpo, estoy exlorando otrp camino diferente con el evento mouse move y xy de los controles hijos pero tengo que dejar el tema por una hora y luego vuelvo.
Pero te dejo algo para experimentar pero no se si servira.
Saludos.
Pero te dejo algo para experimentar pero no se si servira.
Código:
Public Sub Form_MouseMove()
Dim obj As Variant
For Each obj In Me.Children
Select Object.Type(obj.Parent)
Case "Panel", "Frame"
If Me.FindChild(obj.x, obj.y) Then
Print Me.FindChild(obj.x, obj.y).Name
Endif
End Select
Next
End1 Saludo.
Cita:La ayuda se almacena en XML y se gestiona desde una clase únicamente. Había pensado añadir una "clave de ayuda" como dices, pero suelo utilizar nombres explícitos en los controles y formularios y en principio no lo he visto necesario.La ventaja de poner una clave es que puedes compartir la misma ayuda por varios controles que tengan funciones similares en distintos formularios, etc.
No podemos regresar
Shordi, finalmente he resuelto el problema con los Tag. Usar Group me ha resultado complicado, unifica los eventos de todos controles que usan la propiedad.
Me ha resultado más práctico poner "H" en el Tag de los controles que necesitan ayuda y modificar el proceso de lectura.
[/code]
Gracias Tincho, le había dado una vuelta a usar el ratón pero para eso están los Tooltips. No le vi salida.
Shordi, aunque no uso clave la ayuda es compartida entre controles. La clase que lo gestiona lee Form->Controls pero trabaja con Control->Forms. Al introducir el texto de ayuda busca si tiene el control identificado en otro formulario y da la opción de nueva ayuda o ya existente. Lo óptimo sería la clave pero de esta forma vamos construyendo la ayuda a medida que probamos, y parece que cuesta menos.
Gracias por las respuestas, un saludo.
Me ha resultado más práctico poner "H" en el Tag de los controles que necesitan ayuda y modificar el proceso de lectura.
Código:
[code]Private Sub SearchHelpTag(oControl As Control) As String
'Busqueda TAG = "H" en parent del control
Dim sName As String = ""
If oControl.Tag = "H" Then
sName = oControl.Name
Else
While oControl.Parent
oControl = oControl.Parent
If oControl.Tag = "H" Then
sName = oControl.Name
Break
Endif
Wend
Endif
Return sName
EndGracias Tincho, le había dado una vuelta a usar el ratón pero para eso están los Tooltips. No le vi salida.
Shordi, aunque no uso clave la ayuda es compartida entre controles. La clase que lo gestiona lee Form->Controls pero trabaja con Control->Forms. Al introducir el texto de ayuda busca si tiene el control identificado en otro formulario y da la opción de nueva ayuda o ya existente. Lo óptimo sería la clave pero de esta forma vamos construyendo la ayuda a medida que probamos, y parece que cuesta menos.
Gracias por las respuestas, un saludo.
Última modificación: 13-06-2021, 22:17 por Harpo.
Cita:Lo óptimo sería la clave pero de esta forma vamos construyendo la ayuda a medida que probamos, y parece que cuesta menos.Esa fue mi idea inicial cuando ideé el sistema, unida a que en las diferentes categorías de permisos de usuarios (que también se automatizaban vía .tag de los controles de acción (botones y demás)) había una categoría de "Colaborador del programa" que tenía permisos para rellenar ayudas. Así los propios usuarios podían generar una especie de Wiki con las ayudas...
... Ni qué decir tiene que fue un fracaso absoluto: Nunca encontré un usuario que quisiese colaborar.
Última modificación: 13-06-2021, 21:27 por Shordi.
No podemos regresar
(13-06-2021, 21:22)Shordi escribió:
Cita:Lo óptimo sería la clave pero de esta forma vamos construyendo la ayuda a medida que probamos, y parece que cuesta menos.Esa fue mi idea inicial cuando ideé el sistema, unida a que en las diferentes categorías de permisos de usuarios (que también se automatizaban vía .tag de los controles de acción (botones y demás)) había una categoría de "Colaborador del programa" que tenía permisos para rellenar ayudas. Así los propios usuarios podían generar una especie de Wiki con las ayudas...
... Ni qué decir tiene que fue un fracaso absoluto: Nunca encontré un usuario que quisiese colaborar.
Solo hay dos constantes en el universo, la velocidad de la luz y los usuarios....
En GauchoCAD tenemos muchos problemas con GTK2 vs GTK3 vs QT5 ; los formularios reaccionan de manera diferente segun el componente GUI utilizado. A medida que avance la cantidad de controles y todo, va a ser aun peor. En mi modesta opinion, a Benoit se le va a hacer imposible mantener todo libe de bugs. Deberia focalizarse en un componente y que funcione todo , GTK o QT.
"Es mejor saber todo de muy poco que muy poco de todo" - anonimo