Buen dia a todos...

Se me ocurrió y de alguna manera sé que no soy el primero en pensar en algo similar.

Utilizar la clase gb.settings para instanciar una nueva clase, ....   quizás errores

Public ruta as String = Application.Path & "/.hidden/errores.settings"
Public errores as Settings(ruta)

Hasta ahí todo marcha bien...

luego se podría crear la lista de mensajes de error siguiendo la estructura del archivo settings, tipo...

[Errores]
1 ="Mensaje"
   .
   .
   .
4="Otro mensaje"

Luego se puede llamar a una función o sub que pasándole el código del error, devuelva el mensaje

Esa es la teoría, pero en la práctica no me está funcionando, estoy seguro es una tontería, si se puede llegar a ejecutar correctamente
puede ahorrar mucho tiempo de escribir mensajes, como " Debe indicar un valor para..." o cosas similares.

Yo tengo la sub escrita de esta forma

Public Sub LeeErrores( k as String ) as String
   Dim t as String

  If Not Exist(errores.Path) Then
    Return "El Archivo de errores no existe"
  Endif
    
  Return errores["Errores/" & e, "Error no tipificado aún"]
  
End
  
Había un problema con el Path del archivo pero una vez solucionado, funciona como la seda...
Se me ocurre que para evitar la desaparición forzada del archivo cambiarle a este el atributo de escritura.

A ver que les parece la idea.

Saludos y feliz domingo

Buenas tardes,
yo desconociendo el sistema de programación gambas, a nivel de clases y componentes específicos para el tema que comentas haría una clases normal estilo (.NET) MsgErrores.cs en la cual declares
PUBLIC STATIC STRING MsgError1
PUBLIC STATIC STRING MsgErrorN

y luego los llamaría en mi código según el error.

Es una simple idea, al no trabajar con archivos evitas el bloqueo del mismo (Lectura - Escritura)

Saludos

calcena escribió: [Ver mensaje]

... una clases normal estilo (.NET)

  

vuott escribió: [Ver mensaje]

calcena escribió: [Ver mensaje]

... una clases normal estilo (.NET)

  

Perdón si estoy constantemente comparando con otro sistema, pero la costumbre de las personas a veces es comprar con algo para poder explicarse.

Para futuras entradas intentaré no comprar con otro sistema.
Saludos.

Hola que tal, ramon_661.

la idea de usar un archivo/modulo/clase como repositorio para los mensajes y así reutilizarlos, en lo personal me genera ruido producto de que si deseas cambiar el mensaje a algo un poco mas especifico, seguramente en mas de alguna de las partes donde lo pusiste dejara de ser clarificador, incluso puede ser absolutamente erroneo.

lo mejor es adjuntarle algún tipo de numero ya sea con [] {} u otro símbolo. Es sabido que los usuario cuando te llaman para solucionar su problema te dan muy poca o nada de información. Y te aseguro que con un mensaje genérico no llegas ni a palos al lugar del error.

pero como premio de consuelo dejarlo en un modulo con el formato para detectarlo rapido es mejor para temas de mantenimiento

mensaje1001 = ("mensaje de error [1001]")


saludos.

Yo no entiendo muy bien la propuesta de ramon_661.

¿Qué tipo de errores hablamos? ¿Errores del programa?¿Errores del Entorno?¿O errores del Usuario?
Los segundos y terceros deben estar previstos en nuestro programa. Si son errores del programa... ¿Por qué no usar la clase Error de gambas?

Al usuario común, (al menos a los míos) en cuestión de errores inesperados, les da lo mismo lo que les pongas en el mensaje: sea lo que sea te llaman y se quejan como si los hubieses ofendido. Al final me cansé y en errores inesperados les envío siempre el mensaje:

Message ("Se produjo un error. Avise al administrador y comuníquele este código: " & Error.Text & " - " & Error.where)

Me llaman igual que antes, pero ahora me dan pistas de lo que pasa.

===================
No podemos regresar

Buenas a todos...


Voy a tratar de aclarar el tema, ya que por error hablé de clase cuando debí mencionar componente, ya que eso es.

Ahora bien. El asunto es simple, seguramente todos hemos escrito muchas veces el mismo mensaje de "Debe escribir algo en el campo" o luego de atrapar (capturar) un error de división por 0.....    No se trata de nada extremadamente novedoso, tampoco de reinventar la rueda.

Habiendo usado el componente gb.Settings, saben que cada elemento o valor guardado en ella debe incluir una etiqueta como poco.
es decir  etiqueta="tal o cual cosa".  

etiqueta puede ser un nro, para toda causa y efecto será un identificador que estaría relacionado directamente con determinado mensaje de error.

Solo habría que ser cuidadoso a la hora de establecer cual será el error a presentar traerlo desde este archivo y presentarlo en cualquiera de las diferentes formas de presentación de mensajes de las que dispone gambas.

He probado un par de veces y funciona bien, solo hay que ser cuidadoso a la hora de recuperar el mensaje para no presentar un error por otro, pero no es nada que una hoja de papel impresa con el listado de errores no te solucione.

A lo mejor muchos son los usuarios que hablan inglés y no le presenta inconveniente alguno comunicar por teléfono  el texto del mensaje en inglés proporcionado por Error.text.

Y salvo aquellos que debemos prever nosotros todos los errores se reflejan con numeros negativos, si no me equivoco, ya que es bastante práctico.

Inicialmente se me había ocurrido para aquellos que devemos prever nosotros, pero haciendo eso que comentaste shordi me dí cuenta que los mensaje venían en inglés y en particular mis clientes no hablan inglés....  lo mastican y luego lo escupen, así que yo llegaría con exactamente la misma información que si no hubiesen dicho nada.

Por otro lado en el mensaje inicial incluí el hecho de relacionar el mensaje con un numero, al que llamo  etiqueta porque eso es.

Lo que resulta interesante de todo esto, es que varias veces he visto que los archivos de configuración, se re-escriben cuando guardas algo en ellos pero este no es el caso, así que funciona de maravilla hasta que no se pone cuidado y presentas por ejemplo: un mensaje de advertencia sobre un campo de fecha vacío, en lugar de el que debería ir ahí, pero eso no es otra cosa que error del programador. Por eso insisto en ser ordenado y cuidadoso.
 
La idea surge de evitar escribir muchas veces el mismo mensaje, pero como dije lo extendí hasta los mensajes de error, que aunque menos frecuentes, también tienen su corazoncito. Además si acaso puede ser incómodo el tema de a donde almacenarlo, pues se crea una carpeta oculta y para la mayoría de la gente resultaría invisible.

Espero haber aclarado el tema. Y gracias por los comentarios.

Perdón olvidaba algo importante.


Siempre que fuese necesario ser muy especifico respecto de un error particular solo hay que crear uno nuevo, asunto arreglado.  

Aunque ir al detalle especifico en cada caso suele llevar a engordar el código, me explico;  " Ud. ha ingresado un caracter no válido en el campo fecha de inicio", dá hasta flojera leerlo, sin contar con el hecho de que digamos que se está usando la instrucción message.

Message("Ud. ha ingresado un caracter no válido en el campo fecha de inicio", "Ok")

Y si es tienes 5 campos de fecha....   mientras que de la otra forma resulta en 2 lineas, si acaso, pero ninguna tan larga, si bien es cierto que los píxeles no se desgastan, esta es una forma mas sencilla de manejar los errores y otros mensajes

Saludos

bueno, con la explicación que das, al menos yo entiendo lo que quieres hacer. y creo que es válida la propuesta.

Sin embargo, me genera ruido el hecho que tengas en un archivo fuera de la aplicación, por lo mismo que explicas que ocurrió por utilizar mal el path de donde queda el archivo. Cambiarle los atributos al archivo, es como ponerle mas pelos a la sopa y enredarlo aún más.

La idea es utilizar KISS, "Keep it simple, smart". o ZEN por decirlo de otra manera "menos, es mas"

Ahora como dicen, para gustos, colores  

Citar:

Keep it simple, smart

Muy educado, sí señor      

===================
No podemos regresar