tincho escribió:  

Hay que comprobar si hay error (si no es null) antes de poder ver si es > 0.

Código: [Descargar] [Ocultar] [Seleccionar]

Código: [Descargar] [Mostrar]

Public Sub btCargar_Click()

  With TreeView1
    .Add("*", "Nodo Root")
    .Add("Child1", "Hijo 1",, "*")
    .Add("Child1-1", "Sub Hijo 1-1",, "Child1")
    .Add("Child1-2", "Sub Hijo 1-2",, "Child1")
    .Add("Child1-3", "Sub Hijo 1-3",, "Child1")
    .Add("Child1-4", "Sub Hijo 1-4",, "Child1")

    .Add("Child2", "Hijo 2",, "*")
    .Add("Child2-1", "Sub Hijo 2-1",, "Child2")
    .Add("Child2-2", "Sub Hijo 2-2",, "Child2")
    .Add("Child2-3", "Sub Hijo 2-3",, "Child2")
    .Add("Child2-4", "Sub Hijo 2-4",, "Child2")
  End With

Finally
  If Error Then ' Agregue esto a tu código
    If Error.Code > 0 Then
      Message.Info("Error: " & Error.Text & gb.CrLf & "Módulo: " & Error.Where)
    Endif
  Endif ' Agregue esto a tu código

Catch
  Message.Error("Errorx: " & Error.Text & gb.CrLf & "Módulo: " & Error.Where)

End

Public Sub btSalir_Click()

  Me.Close()

End
 

Saludos.

Gracias por el apunte.
Lo que intento es encontrar una manera de evitar que errores internos gestionados con "Try" en el control TreeView, y pasa lo mismo con ColumnView y GridView, afecten a funciones de carga de datos que funcionan correctamente en nuestros programas.
La cláusula Finally se ejecuta antes que Catch en caso de error, si hay un Return en Finally no se ejecuta Catch y no muestra el error, por eso la idea de usar la sentencia: If Error.Code <= 0 Then Return True.
En caso de error de programación dentro de la función de carga no ejecutaría el Return y continuaría con Catch mostrando el error.
El problema es que Error.Code es mayor que 0 por el funcionamiento interno del TreeView, no por error de la función de carga, y me lo descoloca todo.

Y yo solo veo dos alternativas:
- Parchear los controles estándar (no me gusta).
- Justo antes de la cláusula Finally poner una sentencia Error.Clear() asumiendo que si ha llegado hasta ahí la ejecución no ha habido ningún error propio.

Creo que no me explico correctamente  

Hola

Una aclaración: la cláusula Finally se ejecuta siempre. Da igual que haya error o no, pero siempre se ejecuta lo que contenga Finally. De manera que, aunque en otros lenguajes el flujo es Try...Catch...Finally, en gambas no se usa Try junto con Catch y/o Finally. Cuando se usa Try, se "oculta" el error que puede ser gestionado mediante la sentencia If error then...

Por lógica, en el caso de Catch y Finally, éste último contendrá el código que deba ejecutarse haya o no un error. Catch ejecutará el código para manejar el eventual error si se produce.

Dicho esto, creo que si el control Treeview al que le pasas un objeto Result inválido genera un error, es completamente normal. Lo que en mi opinión habría que hacer es comprobar dicho objeto Result antes de pasarlo al control (por ejemplo comprobando si tiene registros o son válidos esos registros).

El control Treeview tiene ciertas particularidades que lo hacen bastante engorroso de manejar, pero al igual que el resto de controles para datos, sólo pueden mostrar datos que les lleguen de la forma adecuada, de manera que insisto en que ahí radica el problema y no en el control.

Saludos

jguardon escribió:  

Hola

Una aclaración: la cláusula Finally se ejecuta siempre. Da igual que haya error o no, pero siempre se ejecuta lo que contenga Finally. De manera que, aunque en otros lenguajes el flujo es Try...Catch...Finally, en gambas no se usa Try junto con Catch y/o Finally. Cuando se usa Try, se "oculta" el error que puede ser gestionado mediante la sentencia If error then...

Por lógica, en el caso de Catch y Finally, éste último contendrá el código que deba ejecutarse haya o no un error. Catch ejecutará el código para manejar el eventual error si se produce.

Gracias por la información. Totalmente de acuerdo, Finally se ejecuta siempre, por eso creo que es el sitio adecuado para realizar acciones como cerrar conexiones de base de datos y liberar objetos. Pero si dentro de Finally se incluye un Return ya no ejecuta Catch. De ahí la idea de que si incluyo un Return esté condicionado a que Error.Code sea cero y el error esté controlado.

jguardon escribió:  

Hola

Dicho esto, creo que si el control Treeview al que le pasas un objeto Result inválido genera un error, es completamente normal. Lo que en mi opinión habría que hacer es comprobar dicho objeto Result antes de pasarlo al control (por ejemplo comprobando si tiene registros o son válidos esos registros).

El control Treeview tiene ciertas particularidades que lo hacen bastante engorroso de manejar, pero al igual que el resto de controles para datos, sólo pueden mostrar datos que les lleguen de la forma adecuada, de manera que insisto en que ahí radica el problema y no en el control.

En este punto, con su permiso, discrepo. En el segundo ejemplo que he subido se hace una carga simple y directa mediante TreeView.Add() de forma adecuada y aun así cuando en Finally se hace un Debug Error.Code el resultado no es cero. Hay un Try interno en el control que provoca un error que se "hereda". No tiene mayor transcendencia, es el funcionamiento estándar del control, tendrá su razón de ser, pero Error.Code ya no es cero.
Y me tira por tierra mi planteamiento...  

Pues tienes toda la razón. Debería haber empezado por probar tu ejemplo, que evidentemente arroja los resultados que mencionas.

La idea de filtrar por el código de error no es del todo mala, siendo un número positivo alto (13). Cualquier otro error de programación te va a dar un número inferior a 0, generalmente un -1, con lo cual la expresión If Error.Code < 0 debería bastar, aunque no es equiparable a True o False, siempre sería True porque nunca vas a obtener 0 en la salida.

No veo otra solución a menos que se modifique el código fuente del control. También puedes abrir un reporte de error en el bugtracker de gambas ( https://gambaswiki.org/bugtracker ).

Saludos y disculpa por hablar sin probar