Comunidad Gambas-es

Versión completa: Problema con Form.Controls - GTK3 - QT5
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Páginas: 1 2
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.
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
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.
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.
GAMBAS
  1. Public Sub Form_MouseMove()
  2.  
  3.    Dim obj As Variant
  4.  
  5.    For Each obj In Me.Children
  6.       Select Object.Type(obj.Parent)
  7.          Case "Panel", "Frame"
  8.             If Me.FindChild(obj.x, obj.y) Then
  9.                Print Me.FindChild(obj.x, obj.y).Name
  10.             Endif
  11.       End Select
  12.    Next


Saludos.
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.
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.
Código:
GAMBAS
  1. Private Sub SearchHelpTag(oControl As Control) As String
  2.    'Busqueda TAG = "H" en parent del control
  3.  
  4.    Dim sName As String = ""
  5.  
  6.    If oControl.Tag = "H" Then
  7.       sName = oControl.Name
  8.    Else
  9.       While oControl.Parent
  10.          oControl = oControl.Parent
  11.          If oControl.Tag = "H" Then
  12.             sName = oControl.Name
  13.             Break
  14.          Endif
  15.       Wend
  16.    Endif
  17.    Return sName
  18.  


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.
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. Dodgy Dodgy Sleepy
(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. Dodgy Dodgy Sleepy

Solo hay dos constantes en el universo, la velocidad de la luz y los usuarios....
(13-06-2021, 22:44)Harpo escribió: [ -> ]Solo hay dos constantes en el universo, la velocidad de la luz y los usuarios....
Buena frase.
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.
Páginas: 1 2