none
Anular mensaje de error RRS feed

  • Pregunta

  • Hola a todos:

    Ayer hice una pregunta sobre un mensaje que me sale "no siempre" de Capa Lógica    False      Aceptar, en false con el icono de error cuando instalo el programa en otro ordenador. No puedo reproducir ese mensaje en mi ordenador ya que no me sale el mismo, me indicaron hacer una compilación desde el ordenador donde se instala el ejecutable (es en ese ordenador donde sale el mensaje) y tampoco lo he podido solucionar.

    La pregunta es si hay posibilidad de anular dicho mensaje para que no lo muestre al usuario, he de decir que le doy a aceptar al mensaje y todo funciona perfectamente, pero es una lata que salga cuando le parece, indicando simplemente lo que he escrito mas arriba. No sale ningún mensaje de error, solo eso y de vez en cuando una o varias veces, el mismo solo sale cuando estoy cargando varios backgroundsworkers que tiran de muchas fórmulas.

    Tengo un manejador global de errores y tampoco me muestra nada en el archivo log. es decir, entiendo que no es ningún error sino puede ser otro problema que no se cual puede ser pero que tengo claro que no afecta al funcionamiento del programa, he repasado si había algún procedimiento demasiado largo, he lanzado las métricas del código y todo correcto, no se que mas puedo hacer o mirar.

    Si alguien tiene idea de porqué pasa o bien que me ayude a anular dicho mensaje, ya que no puedo entregar la aplicación con el mismo.

    Un cordial saludo a todos.

    Gemma


    domingo, 24 de julio de 2016 9:28

Respuestas

  • "gemma_campillo" preguntó:

    > La pregunta es si hay posibilidad de anular dicho mensaje para que no lo muestre al usuario, ...
    >
    > Tengo un manejador global de errores y tampoco me muestra nada en el archivo log.
    >
    > Si alguien tiene idea de porqué pasa o bien que me ayude a anular dicho mensaje, ya que no
    > puedo entregar la aplicación con el mismo.

    ¡Vamos a ver! Si en la clase FinancialSystem.Submain tienes instalados los siguientes manejadores globales de error, tal cual indico:

           Private Shared Sub Application_ThreadException(ByVal sender As Object, ByVal e As ThreadExceptionEventArgs)
                MessageBox.Show(e.Exception.Message)
            End Sub
    
           Private Shared Sub UnhandledExceptionEventRaised(ByVal sender As Object, ByVal e As UnhandledExceptionEventArgs)
                If e.IsTerminating Then
                    MessageBox.Show(RuntimeHelpers.GetObjectValue(e.ExceptionObject).ToString)
                End If
           End Sub

    Yo no veo que ahí se escriba en algún archivo *.log, más bien le estás indicando que se muestre un MessageBox.Show con la excepción producida, por tanto, si no deseas que al usuario se le muestre un cuadro de mensaje con el error que se ha producido, tan solo tienes que comentar el método MessageBox.Show.

    Te comento que, a mi entender, los controladores de error globales son para FINALIZAR LA APLICACIÓN, digamos que de una manera "elegante", pero no para mostrar un cuadro de diálogo y continuar con la ejecución del programa sin que no hubiera pasado nada, porque si no depuras el error producido, ¿para qué quieres continuar con la ejecución del programa? Piensa que ese error puede tener consecuencias más tarde, aunque tu digas que no pasa nada. Si es así, pues con no ejecutar el método MessageBox.Show es suficiente, aunque en este caso, poco te vas a enterar de lo que realmente ha sucedido en aquellos errores que no hayas controlado explícitamente mediante el correspondiente bloque Try ... Catch ... End Try. ;-)


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.




    domingo, 24 de julio de 2016 11:18
    Moderador
  • "gemma_campillo" preguntó:

    > El archivo log, lo he añadido posteriormente a lo que tu has visto, ...

    El archivo *.log debería de servir para saber exactamente el error que se ha producido.

    > ... pero bueno, no me sirve de nada. Lo he quitado y solo dejo las dos tuyas.

    NO. Las "dos mías" no las dejes si tu intención es que no aparezca el cuadro de diálogo de error ante una excepción no controlada que se haya producido. Tan solo tienes que eliminar de ambas la llamada al método MessageBox.Show, pero que, insisto, que si no hay archivo *.log y tampoco un cuadro de diálogo, en este caso no te vas a enterar de lo que realmente está sucediendo.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.

    • Marcado como respuesta gemma_campillo domingo, 24 de julio de 2016 12:57
    domingo, 24 de julio de 2016 12:01
    Moderador
  • "gemma_campillo" escribió:

    > el error ya creo que se cual es: Al pasar por los cálculos de las fórmulas, se para
    > en alguna de ellas y al ejecutar el executeNonQuery salta la excepción de
    > "Elemento bloqueado", y es entonces cuando aparece el mensaje de Capa Logica  False   Aceptar.
    > El problema es que no siempre pasa y si pasa puede pasa en cualquier otra fórmula,
    > las cuales voy ejecutando una detrás de otra.

    En primer lugar, quisiera saber si eres consciente de lo que sucede cuando en el procedimiento Sub Main (que se comprende es el objeto de inicio de tu aplicación), instalas los siguientes controladores:

            Friend Shared Sub Main()
    
                AddHandler Application.ThreadException, New ThreadExceptionEventHandler(AddressOf Submain.Application_ThreadException)
                 AddHandler AppDomain.CurrentDomain.UnhandledException, New UnhandledExceptionEventHandler(AddressOf Submain.UnhandledExceptionEventRaised)
       
             End Sub

    Application.ThreadException es para instalar un controlador global de excepciones para las aplicaciones de Windows Form, y AppDomain.UnhandledException más o menos es lo mismo pero para las aplicaciones que no son de Windows Forms, como por ejemplo, para una aplicación de biblioteca de clases.

    Pero ambos controladores se desencadenarán únicamente si la excepción que se haya producido no ha sido previamente controlada mediante un bloque Catch dentro del famoso bloque Try ... Catch ... Finally ... End Try.

    Por ejemplo, si en algún método tenemos:

        Try
             ' Código de ejecución que provoca una excepción.
             Throw New ArgumentNullException()
    
        Catch ex As Exception
             MessageBox.Show(ex.Message)
    
        End Try

    En el bloque Catch podrás obtener la información sobre la excepción que se ha producido. En cambio, si el error se ha producido en una línea de código que NO ESTÁ dentro del bloque Try:

       
        Throw New ArgumentNullException()

    Entonces se desencadenará el evento Application.ThreadException (si el error se ha producido en un proyecto de Windows Forms) o AppDomain.UnhandledException (si se ha producido en otro proyecto que no es de Windows Forms).

    > Antes lo tenía como metodoDatos.contador = "33" o el que sea, pero cuando
    > detectaba el error no me indicaba ese número ya que al estar en un proceso
    > de varios backgroundWorker me cogía el de la fórmula que en ese momento
    > estaba haciendo uno de ellos ...

    Porque seguramente "contador" sería un campo o variable que tendrías definido en algún módulo de tu aplicación como compartido (Shared), por lo tanto te tomaría el valor de la última fórmula que ese momento se estaba ejecutando.

    Desde luego va a ser complicado que puedas depurar bien el error utilizando controles BackgroundWorker, ya que estos normalmente se ejecutarán en otro subproceso diferente del subproceso principal de tu aplicación, y si encima tienes declarados "miles" de bloques Try ... Cath ... End Try, y si con ello no fuera suficiente, también tienes declarados los controladores de los eventos Application.ThreadException y AppDomain.UnhandledException para detectar las excepciones no controladas, pues a ver cómo depuramos el error, que por los motivos que sea, sucede, aunque no suceda siempre, y no hay cosa tan poco profesional y que más me moleste personalmente que encontrarme un MessageBox con una NullReferenceException o NullArgumentException. :-(

    A fin de que puedas depurar el error que dices que estás obteniendo, desinstala mientras tanto los dos controladores globales que instalas en el procedimiento Sub New, para ver si el código se detiene en la línea donde realmente se produce el error.

    Una vez que tengas el código bien depurado, vuelve a instalar los dos controladores si lo estimas conveniente.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.






    domingo, 24 de julio de 2016 14:22
    Moderador
  • "gemma_campillo" escribió:

    > No te quiero marear pero los temas que me has comentado los tengo claros, ...

    ¿Seguro que lo tienes claro? ;-)

    > he localizado el porqué daba el error con el menaje Capa Logica  Icono False y Aceptar,
    > y es porqué no está leyendo el catch que le puesto, pasa por e´l pero muestra el dichoso
    > mensaje sin nada de la información que yo le puesto en el Catch, es eso lo que no entiendo,
    > porqué no me dice lo que le pongo en dicho bloque, ya te digo pasa por el pero muestra esa
    > aberración de mensaje. Ahora lo tengo controlado porque je provocado un error y lo veo pasar
    > por el catch y saca el mensaje, pero no con lo que tendría que mostrar, es decir, lo que le
    > pongo en el bloque catch.
    >

    Pero, ¿dónde has colocado el siguiente Catch?

        Catch ex As Exception
                MsgBox("Error en carga de fórmulas Grupo II. - Formula: " & MetodosDatos.Contador = "1750" & vbCrLf &
                       "Contacte con su proveedor." & vbCrLf & vbCrLf & ex.Message, MsgBoxStyle.Critical)
        End Try

    ¿Por casualidad lo has colocado en los eventos Application.ThreadException o AppDomain.CurrentDomain.UnhandledException? ¿En qué método concreto lo has colocado?

    > Ese es el único problema, el porqué no lee el maldito mensaje.

    Te he comentado anteriormente que estás trabajando con subprocesos, o si lo prefieres, con "hilos", ya que estás utilizando controles BackgroundWorker, que no son ni uno ni dos, que en cierta clase he visto ¡HASTA CINCO CONTROLES BackgroundWorker! Y el orden en el que se ejecutan las operaciones puede que no sea el que tu le hayas indicado, porque un subproceso puede acabar antes que otro que haya comenzado anteriormente, y como estás accediendo a datos, lo mismo un subproceso se está encontrando la base bloqueada, por lo que no me extrañaría que puede que ahí esté el error que unas veces obtienes y otras no.

    Es muy difícil depurar una aplicación que utiliza "hilos", y a lo mejor con variables compartidas (Shared) que pueden hacer más daño que beneficio, por lo que si te aparece un MessageBox sin la descripción "Error en carga de fórmulas Grupo II ...", puede ser que ese MessageBox se corresponda con alguno de los existentes en los eventos Application.ThreadException o AppDomain.CurrentDomain.UnhandledException, de ahí que te haya indicado anteriormente que DESACTIVES TEMPORALMENTE los citados eventos para ver si el código se detiene en la línea donde realmente se ha producido el error, o en otra que te pueda dar una pista de lo que ha sucedido, por eso te he preguntado si realmente tienes claro el motivo de instalar/desinstalar los eventos comentados. ;-)


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.

    • Marcado como respuesta gemma_campillo domingo, 24 de julio de 2016 15:07
    domingo, 24 de julio de 2016 14:56
    Moderador
  • "gemma_campillo" escribió:

    > El MétodoDatos.Contador es un String, ...

    ¿Y está compartido, declarado como Shared?

    > ... también he tildado de momento las llamadas desde el submain y hace los mismo,
    > entra en el Catch pero cuando muestra el mensaje, no lo hace bien, muestra el otro.

    Es decir, que has desactivado los eventos Application.ThreadException y AppDomain.CurrentDomain.UnhandledException, y a pesar de ello, continuas obteniendo el misterioso MessageBox.

    > Que historia más tonta. Por eso salían los mensajes esos de Capa Logica  False   Aceptar, ...

    ¿Salían? ¿Ya no salen?

    > ... porque la aplicación no lee los catch que he puesto en cada fórmula con el fin
    > de poder averiguar si falla una saber cual es. Pero ahí los backgroundworkers no
    > tienen que ver nada, ellos hacen su papel, pero si falla la fórmula nos tiene que
    > mostrar el mensaje no lo que ella dice que es siempre lo mismo.

    Que tu crees que nada tienen que ver los BackgroundWorker, y yo sí creo que pueden tener algo que ver si son los encargados de llamar a los procedimientos tipo ValorNetoClientesEfectosDescontados.

    En tu mensaje inicial escribías lo siguiente:

    > La pregunta es si hay posibilidad de anular dicho mensaje para que no lo muestre al usuario ...

    Si tu intención es anular los MessageBox.Show, te repito que tan solo tienes que eliminarlos de los bloques Catch, aunque no creo yo que esa sea la mejor solución.

    Y para conocer el mensaje exacto del error, en lugar de ejecutar:

        MsgBox("Error en carga de fórmulas Grupo II. - Formula: " & MetodosDatos.Contador = "1750" & vbCrLf &
               "Contacte con su proveedor." & vbCrLf & vbCrLf & ex.Message, MsgBoxStyle.Critical)

    mejor será que ejecutes temporalmente:

        MessageBox.Show(ex.Message)

    Insisto que estás trabajando con subprocesos, y lo que tu no ves lógico puede que sea lo más lógico que suceda, ya que el orden de ejecución de los métodos no tienen que ser los que en un primer momento tu hayas indicado, ya que habrá subprocesos que finalicen inmediatamente su trabajo y otros que no lo hagan tan pronto.

    Repito que es muy complicado depurar una aplicación con múltiple "hilos" de ejecución y mediante mensajes de correo electrónico, porque hay que disponer del código fuente completo, establecer los correspondientes puntos de interrupción e inspeccionar los valores de las variables, campos y objetos, incluidos aquellos que se encuentren compartidos, que son los que más dolores de cabeza suelen dar en este tipo de aplicaciones si no se saben utilizar correctamente.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.



    domingo, 24 de julio de 2016 15:28
    Moderador

Todas las respuestas

  • "gemma_campillo" preguntó:

    > La pregunta es si hay posibilidad de anular dicho mensaje para que no lo muestre al usuario, ...
    >
    > Tengo un manejador global de errores y tampoco me muestra nada en el archivo log.
    >
    > Si alguien tiene idea de porqué pasa o bien que me ayude a anular dicho mensaje, ya que no
    > puedo entregar la aplicación con el mismo.

    ¡Vamos a ver! Si en la clase FinancialSystem.Submain tienes instalados los siguientes manejadores globales de error, tal cual indico:

           Private Shared Sub Application_ThreadException(ByVal sender As Object, ByVal e As ThreadExceptionEventArgs)
                MessageBox.Show(e.Exception.Message)
            End Sub
    
           Private Shared Sub UnhandledExceptionEventRaised(ByVal sender As Object, ByVal e As UnhandledExceptionEventArgs)
                If e.IsTerminating Then
                    MessageBox.Show(RuntimeHelpers.GetObjectValue(e.ExceptionObject).ToString)
                End If
           End Sub

    Yo no veo que ahí se escriba en algún archivo *.log, más bien le estás indicando que se muestre un MessageBox.Show con la excepción producida, por tanto, si no deseas que al usuario se le muestre un cuadro de mensaje con el error que se ha producido, tan solo tienes que comentar el método MessageBox.Show.

    Te comento que, a mi entender, los controladores de error globales son para FINALIZAR LA APLICACIÓN, digamos que de una manera "elegante", pero no para mostrar un cuadro de diálogo y continuar con la ejecución del programa sin que no hubiera pasado nada, porque si no depuras el error producido, ¿para qué quieres continuar con la ejecución del programa? Piensa que ese error puede tener consecuencias más tarde, aunque tu digas que no pasa nada. Si es así, pues con no ejecutar el método MessageBox.Show es suficiente, aunque en este caso, poco te vas a enterar de lo que realmente ha sucedido en aquellos errores que no hayas controlado explícitamente mediante el correspondiente bloque Try ... Catch ... End Try. ;-)


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.




    domingo, 24 de julio de 2016 11:18
    Moderador
  • Hola Enrique:

    El archivo log, lo he añadido posteriormente a lo que tu has visto, pero bueno, no me sirve de nada. Lo he quitado y solo dejo las dos tuyas.

    Bueno, voy a probar a ver si se soluciona el tema. Eso es muy raro, pero bueno, ahí está.

    Enrique, gracias como siempre y vamos a seguir aguantando esta maldita calor.

    Un abrazo querido amigo.

    Gemma

    domingo, 24 de julio de 2016 11:31
  • "gemma_campillo" preguntó:

    > El archivo log, lo he añadido posteriormente a lo que tu has visto, ...

    El archivo *.log debería de servir para saber exactamente el error que se ha producido.

    > ... pero bueno, no me sirve de nada. Lo he quitado y solo dejo las dos tuyas.

    NO. Las "dos mías" no las dejes si tu intención es que no aparezca el cuadro de diálogo de error ante una excepción no controlada que se haya producido. Tan solo tienes que eliminar de ambas la llamada al método MessageBox.Show, pero que, insisto, que si no hay archivo *.log y tampoco un cuadro de diálogo, en este caso no te vas a enterar de lo que realmente está sucediendo.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.

    • Marcado como respuesta gemma_campillo domingo, 24 de julio de 2016 12:57
    domingo, 24 de julio de 2016 12:01
    Moderador
  • Hola maestro:

    De acuerdo. el error ya creo que se cual es: Al pasar por los cálculos de las fórmulas, se para en alguna de ellas y al ejecutar el executeNonQuery salta la excepción de "Elemento bloqueado", y es entonces cuando aparece el mensaje de Capa Logica  False   Aceptar. El problema es que no siempre pasa y si pasa puede pasa en cualquier otra fórmula, las cuales voy ejecutando una detrás de otra.

    Bueno, a ver como puedo solucionar eso. Voy a arreglar lo del Message box que me han indicado con "NO".

    Un abrazo Enrique y gracias.

    Gemma

    domingo, 24 de julio de 2016 12:57
  • Hola Enrique:

    Bueno, el error que da o el mensaje que da tiene su lógica. Voy a ver si te lo explico bien. En cada fórmula je puesto un bloque try catch para poder detectar si falla la fórmula, saber que número tiene de fórmula para así saber cual es la que da error. Antes lo tenía como metodoDatos.contador = "33" o el que sea, pero cuando detectaba el error no me indicaba ese número ya que al estar en un proceso de varios backgroundWorker me cogía el de la fórmula que en ese momento estaba haciendo uno de ellos. Entonces y se que no eres amigo de esto, dije, pues le pondo un tri Ctah en cada fórmula y si algún día casca pues ya sabré que fórmula es y así lo hice. Ahora resulta que he provocado un error (he sacado un parámetro) y efectivamente entra en el Catch pero el mensaje que sale no es el del Catch es el famoso mensaje que estamos dándole vueltas.

    Yo los he definido en el Catch así:

       Catch ex As Exception
                MsgBox("Error en carga de fórmulas Grupo II. - " & "Formula: " & MetodosDatos.Contador = "1750" & vbCrLf &
                           "Contacte con su proveedor.", MsgBoxStyle.Critical)
            End Try
     

    Pero creo que hay es donde tengo el error ya que antes de poner los Catch, ese error nunca me había salido así. Por ello, entiendo los Catch los tengo mal y que he de poner algo más, lo cual voy a probar ahora. con el error provocado.

    Bueno te digo algo en cuanto pueda.

    Un abrazo.

    Gemma

    domingo, 24 de julio de 2016 13:34
  • Hola maestro:

    Bueno creo que todo el jaleo lo están dando los Catch, ya que el mensaje que pongo dentro se lo pasa por el forro y

    emite el mensaje de siempre que no dice nada. Solamente tengo que solucionar que lea bien el catch porque hay está el problema y debe haber alguna fórmula o bien la excepción del "Elemento Bloqueado" que ese no se como solucionarlo, ya que no siempre es el mismo o bien lo hace todo correctamente. Esa excepción es la que me cuesta cogerla ya que no se ha vuelto a parar en el ExecuteNonQuery. Bueno, aver si me centro y voy a ir primero a ver porque no lee el catch y después solucionaré lo otro.

    Te digo algo en cuanto pueda.

    Un abrazo.

    Gemma

    domingo, 24 de julio de 2016 13:53
  • "gemma_campillo" escribió:

    > el error ya creo que se cual es: Al pasar por los cálculos de las fórmulas, se para
    > en alguna de ellas y al ejecutar el executeNonQuery salta la excepción de
    > "Elemento bloqueado", y es entonces cuando aparece el mensaje de Capa Logica  False   Aceptar.
    > El problema es que no siempre pasa y si pasa puede pasa en cualquier otra fórmula,
    > las cuales voy ejecutando una detrás de otra.

    En primer lugar, quisiera saber si eres consciente de lo que sucede cuando en el procedimiento Sub Main (que se comprende es el objeto de inicio de tu aplicación), instalas los siguientes controladores:

            Friend Shared Sub Main()
    
                AddHandler Application.ThreadException, New ThreadExceptionEventHandler(AddressOf Submain.Application_ThreadException)
                 AddHandler AppDomain.CurrentDomain.UnhandledException, New UnhandledExceptionEventHandler(AddressOf Submain.UnhandledExceptionEventRaised)
       
             End Sub

    Application.ThreadException es para instalar un controlador global de excepciones para las aplicaciones de Windows Form, y AppDomain.UnhandledException más o menos es lo mismo pero para las aplicaciones que no son de Windows Forms, como por ejemplo, para una aplicación de biblioteca de clases.

    Pero ambos controladores se desencadenarán únicamente si la excepción que se haya producido no ha sido previamente controlada mediante un bloque Catch dentro del famoso bloque Try ... Catch ... Finally ... End Try.

    Por ejemplo, si en algún método tenemos:

        Try
             ' Código de ejecución que provoca una excepción.
             Throw New ArgumentNullException()
    
        Catch ex As Exception
             MessageBox.Show(ex.Message)
    
        End Try

    En el bloque Catch podrás obtener la información sobre la excepción que se ha producido. En cambio, si el error se ha producido en una línea de código que NO ESTÁ dentro del bloque Try:

       
        Throw New ArgumentNullException()

    Entonces se desencadenará el evento Application.ThreadException (si el error se ha producido en un proyecto de Windows Forms) o AppDomain.UnhandledException (si se ha producido en otro proyecto que no es de Windows Forms).

    > Antes lo tenía como metodoDatos.contador = "33" o el que sea, pero cuando
    > detectaba el error no me indicaba ese número ya que al estar en un proceso
    > de varios backgroundWorker me cogía el de la fórmula que en ese momento
    > estaba haciendo uno de ellos ...

    Porque seguramente "contador" sería un campo o variable que tendrías definido en algún módulo de tu aplicación como compartido (Shared), por lo tanto te tomaría el valor de la última fórmula que ese momento se estaba ejecutando.

    Desde luego va a ser complicado que puedas depurar bien el error utilizando controles BackgroundWorker, ya que estos normalmente se ejecutarán en otro subproceso diferente del subproceso principal de tu aplicación, y si encima tienes declarados "miles" de bloques Try ... Cath ... End Try, y si con ello no fuera suficiente, también tienes declarados los controladores de los eventos Application.ThreadException y AppDomain.UnhandledException para detectar las excepciones no controladas, pues a ver cómo depuramos el error, que por los motivos que sea, sucede, aunque no suceda siempre, y no hay cosa tan poco profesional y que más me moleste personalmente que encontrarme un MessageBox con una NullReferenceException o NullArgumentException. :-(

    A fin de que puedas depurar el error que dices que estás obteniendo, desinstala mientras tanto los dos controladores globales que instalas en el procedimiento Sub New, para ver si el código se detiene en la línea donde realmente se produce el error.

    Una vez que tengas el código bien depurado, vuelve a instalar los dos controladores si lo estimas conveniente.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.






    domingo, 24 de julio de 2016 14:22
    Moderador
  • Hola maestro:

    No te quiero marear pero los temas que me has comentado los tengo claros, he localizado el porqué daba el error con el menaje Capa Logica  Icono False y Aceptar, y es porqué no está leyendo el catch que le puesto, pasa por e´l pero muestra el dichoso mensaje sin nada de la información que yo le puesto en el Catch, es eso lo que no entiendo, porqué no me dice lo que le pongo en dicho bloque, ya te digo pasa por el pero muestra esa aberración de mensaje. Ahora lo tengo controlado porque je provocado un error y lo veo pasar por el catch y saca el mensaje, pero no con lo que tendría que mostrar, es decir, lo que le pongo en el bloque catch.

     Catch ex As Exception
    
                MsgBox("Error en carga de fórmulas Grupo II. - Formula: " & MetodosDatos.Contador = "1750" & vbCrLf &
                       "Contacte con su proveedor." & vbCrLf & vbCrLf & ex.Message, MsgBoxStyle.Critical)
            End Try

    Ese es el único problema, el porqué no lee el maldito mensaje.

    Muchas gracias Enrique y voy a seguir probando porque no entiendo que no lo lea.

    Venga, un fuerte abrazo.

    Gemma

    domingo, 24 de julio de 2016 14:36
  • "gemma_campillo" escribió:

    > No te quiero marear pero los temas que me has comentado los tengo claros, ...

    ¿Seguro que lo tienes claro? ;-)

    > he localizado el porqué daba el error con el menaje Capa Logica  Icono False y Aceptar,
    > y es porqué no está leyendo el catch que le puesto, pasa por e´l pero muestra el dichoso
    > mensaje sin nada de la información que yo le puesto en el Catch, es eso lo que no entiendo,
    > porqué no me dice lo que le pongo en dicho bloque, ya te digo pasa por el pero muestra esa
    > aberración de mensaje. Ahora lo tengo controlado porque je provocado un error y lo veo pasar
    > por el catch y saca el mensaje, pero no con lo que tendría que mostrar, es decir, lo que le
    > pongo en el bloque catch.
    >

    Pero, ¿dónde has colocado el siguiente Catch?

        Catch ex As Exception
                MsgBox("Error en carga de fórmulas Grupo II. - Formula: " & MetodosDatos.Contador = "1750" & vbCrLf &
                       "Contacte con su proveedor." & vbCrLf & vbCrLf & ex.Message, MsgBoxStyle.Critical)
        End Try

    ¿Por casualidad lo has colocado en los eventos Application.ThreadException o AppDomain.CurrentDomain.UnhandledException? ¿En qué método concreto lo has colocado?

    > Ese es el único problema, el porqué no lee el maldito mensaje.

    Te he comentado anteriormente que estás trabajando con subprocesos, o si lo prefieres, con "hilos", ya que estás utilizando controles BackgroundWorker, que no son ni uno ni dos, que en cierta clase he visto ¡HASTA CINCO CONTROLES BackgroundWorker! Y el orden en el que se ejecutan las operaciones puede que no sea el que tu le hayas indicado, porque un subproceso puede acabar antes que otro que haya comenzado anteriormente, y como estás accediendo a datos, lo mismo un subproceso se está encontrando la base bloqueada, por lo que no me extrañaría que puede que ahí esté el error que unas veces obtienes y otras no.

    Es muy difícil depurar una aplicación que utiliza "hilos", y a lo mejor con variables compartidas (Shared) que pueden hacer más daño que beneficio, por lo que si te aparece un MessageBox sin la descripción "Error en carga de fórmulas Grupo II ...", puede ser que ese MessageBox se corresponda con alguno de los existentes en los eventos Application.ThreadException o AppDomain.CurrentDomain.UnhandledException, de ahí que te haya indicado anteriormente que DESACTIVES TEMPORALMENTE los citados eventos para ver si el código se detiene en la línea donde realmente se ha producido el error, o en otra que te pueda dar una pista de lo que ha sucedido, por eso te he preguntado si realmente tienes claro el motivo de instalar/desinstalar los eventos comentados. ;-)


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.

    • Marcado como respuesta gemma_campillo domingo, 24 de julio de 2016 15:07
    domingo, 24 de julio de 2016 14:56
    Moderador
  • Hola Enrique:

    No, en los procesos que dices ahí no van.

    Los he puesto en cada método de cálculo, por ejemplo:

    Public Shared Sub ValorNetoClientesEfectosDescontados()
    
            '//      e. Clientes. (efectos comerciales descontados)
            'Creamos el acceso a datos mediante el nombre de la cadena de conexión existente en el archivo de configuración de la aplicación.
    
            Dim da As DataAccessInvariant = DataAccessInvariant.GetDataAccessInvariant(Configuracion.CadenaConexion)
            Dim valor As Integer = AccesoLogica.ObtenerPeriodos()
    
            Try
                ' Declaramos una variable Connection
                Using cnn As DbConnection = da.CreateConnection()
    
                    ' Creamos el Commando
                    Dim cmd As DbCommand = Nothing
    
                    ValorContable = 0 : Amortizacion = 0 : Deterioro = 0
    
                    If VarGlobal.StrPlanConta = "PLAN 2007" Then
                        'Accedemos al stored procedure o bien a la fórmula del mismo según versión Base de datos.
                        cmd = MetodosCreacion.NombreProcFormulas("CreacionprocFormulasBalance_1_digitos")
    
                        With cmd.Parameters
                            .Clear()
                            .Add(Configuracion.CreateParameter(cmd, "@empresa", VarGlobal.StrCodEmpresa))
                            .Add(Configuracion.CreateParameter(cmd, "@planconta", "PLAN 2007"))
                            .Add(Configuracion.CreateParameter(cmd, "@codigo1", "4311"))
                        End With
    
                        ' Asignamos la conexión al comando
                        cmd.Connection = cnn
    
                        ' Abrimos la conexión
                        cnn.Open()
    
                        Using dr As DbDataReader = cmd.ExecuteReader()
                            While dr.Read
                                ValorContable += dr.GetDouble(0)
                            End While
                        End Using
    
    
                        cmd = MetodosCreacion.NombreProcActualizacDatos("CreacionprocActualValorNeto")
                        With cmd.Parameters
                            .Clear()
    
                            .Add(Configuracion.CreateParameter(cmd, "@ValorContable", ValorContable))
                            .Add(Configuracion.CreateParameter(cmd, "@Amortizacion", 0))
                            .Add(Configuracion.CreateParameter(cmd, "@Deterioro", 0))
                            .Add(Configuracion.CreateParameter(cmd, "@ValorNeto", ValorContable))
                            .Add(Configuracion.CreateParameter(cmd, "@orden", "092"))
                            .Add(Configuracion.CreateParameter(cmd, "@empresa", VarGlobal.StrCodEmpresa))
                            .Add(Configuracion.CreateParameter(cmd, "@planconta", VarGlobal.StrPlanConta))
                        End With
    
                        ' Asignamos la conexión al comando
                        cmd.Connection = cnn
    
                        cmd.ExecuteNonQuery()
                    End If
                End Using
    
            Catch ex As Exception
                MsgBox("Error en carga de fórmulas Grupo II. - " & "Formula: " & MetodosDatos.Contador = "1751" & vbCrLf &
                           "Contacte con su proveedor.", MsgBoxStyle.Critical)
            End Try
        End Sub

    El MétodoDatos.Contador es un String, también he tildado de momento las llamadas desde el submain y hace los mismo, entra en el Catch pero cuando muestra el mensaje, no lo hace bien, muestra el otro.

    Eso es lo que no entiendo.

    Estoy probando ahora con Message.box a ver si así lo coge.

    Bueno, te digo alguna cosa en cuanto pueda.

    Que historia más tonta. Por eso salían los mensajes esos de Capa Logica  False   Aceptar, porque la aplicación no lee los catch que he puesto en cada fórmula con el fin de poder averiguar si falla una saber cual es. Pero ahí los backgroundworkers no tienen que ver nada, ellos hacen su papel, pero si falla la fórmula nos tiene que mostrar el mensaje no lo que ella dice que es siempre lo mismo.

    Bueno maestro, muchas gracias. Te comento lo que pueda.

    n abrazo.

    Gemma

    domingo, 24 de julio de 2016 15:07
  • Hola maestro:

    No mires más cosas, descansa y ve la peli o lo que sea, porque es para colgarme.

    En realidad la variable MetodosContador = "345" por ejemplo, no existe, es un String que le pongo al MsgBox, ahora si lo muestra correctamente, he oatinado fuerte con la leche de la puñetera variable y no es nada, la he de quitar, no sirve. Ahora el catch, ya pasa correctamente y se ha ido a hacer puñetas el maldito mensaje. Ahora lo muestra perfectamente que es lo que necesitaba. Mira el catch queda así:

     Catch ex As Exception
    
                MessageBox.Show("Error en carga de Fórmula: '1750'" & vbCrLf &
                                       "Contacte con su proveedor.", "FINANCIAL SYSTEM", MessageBoxButtons.OK, MessageBoxIcon.Error)
            End Try

    Y nada más, ha saltado el error provocado y muestra correctamente el mensaje. Ya está. Solucionado. Llevo desde el viernes con esta historia, ya había preparado el ejecutable, instalado y todo perfecto, queda fantástico, me voy a la Introducción de datos contables y le doy a generar fórmulas y ale, el mensaje, me quedé blanca. No tenía ni pajolera idea de que quería decir eso. El cabreo fue monumental, más que todo porque no sabía por donde atacar el problema. Ayer Alberto Población me dio una serie de ideas pero nada, claro, el problema, era el maldito catch.

    Bueno, querido maestro te la he jugado ota vez, lo siento, pero bueno si no pasa nada mañana lo saco.

    Te quiere tu amiga del alma.

    Gemma

    domingo, 24 de julio de 2016 15:20
  • "gemma_campillo" escribió:

    > El MétodoDatos.Contador es un String, ...

    ¿Y está compartido, declarado como Shared?

    > ... también he tildado de momento las llamadas desde el submain y hace los mismo,
    > entra en el Catch pero cuando muestra el mensaje, no lo hace bien, muestra el otro.

    Es decir, que has desactivado los eventos Application.ThreadException y AppDomain.CurrentDomain.UnhandledException, y a pesar de ello, continuas obteniendo el misterioso MessageBox.

    > Que historia más tonta. Por eso salían los mensajes esos de Capa Logica  False   Aceptar, ...

    ¿Salían? ¿Ya no salen?

    > ... porque la aplicación no lee los catch que he puesto en cada fórmula con el fin
    > de poder averiguar si falla una saber cual es. Pero ahí los backgroundworkers no
    > tienen que ver nada, ellos hacen su papel, pero si falla la fórmula nos tiene que
    > mostrar el mensaje no lo que ella dice que es siempre lo mismo.

    Que tu crees que nada tienen que ver los BackgroundWorker, y yo sí creo que pueden tener algo que ver si son los encargados de llamar a los procedimientos tipo ValorNetoClientesEfectosDescontados.

    En tu mensaje inicial escribías lo siguiente:

    > La pregunta es si hay posibilidad de anular dicho mensaje para que no lo muestre al usuario ...

    Si tu intención es anular los MessageBox.Show, te repito que tan solo tienes que eliminarlos de los bloques Catch, aunque no creo yo que esa sea la mejor solución.

    Y para conocer el mensaje exacto del error, en lugar de ejecutar:

        MsgBox("Error en carga de fórmulas Grupo II. - Formula: " & MetodosDatos.Contador = "1750" & vbCrLf &
               "Contacte con su proveedor." & vbCrLf & vbCrLf & ex.Message, MsgBoxStyle.Critical)

    mejor será que ejecutes temporalmente:

        MessageBox.Show(ex.Message)

    Insisto que estás trabajando con subprocesos, y lo que tu no ves lógico puede que sea lo más lógico que suceda, ya que el orden de ejecución de los métodos no tienen que ser los que en un primer momento tu hayas indicado, ya que habrá subprocesos que finalicen inmediatamente su trabajo y otros que no lo hagan tan pronto.

    Repito que es muy complicado depurar una aplicación con múltiple "hilos" de ejecución y mediante mensajes de correo electrónico, porque hay que disponer del código fuente completo, establecer los correspondientes puntos de interrupción e inspeccionar los valores de las variables, campos y objetos, incluidos aquellos que se encuentren compartidos, que son los que más dolores de cabeza suelen dar en este tipo de aplicaciones si no se saben utilizar correctamente.


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.



    domingo, 24 de julio de 2016 15:28
    Moderador
  • Bueno, lo voy a poner todo bien, pero estate tranquilo que funciona perfectamente.

    Y tomo nota de todo lo que me has indicado.

    Bueno, maestro gracias otra vez. Mañana la tienes ahí.

    Un abrazo.

    Gemma

    domingo, 24 de julio de 2016 15:33
  • "gemma_campillo" escribió:

    > No mires más cosas, descansa y ve la peli o lo que sea, porque es para colgarme.
    >
    > En realidad la variable MetodosContador = "345" por ejemplo, no existe, es un
    >  String que le pongo al MsgBox, ...
    >
    > MsgBox("Error en carga de fórmulas Grupo II. - " & "Formula: " & MetodosDatos.Contador = "1751" & vbCrLf &
    >  "Contacte con su proveedor.", MsgBoxStyle.Critical)

    Ahí no aparece MetodosDatos.Contador como String, más bien como la asignación de un campo, variable o propiedad.

    Desde luego, mejor será que acabes cuanto antes esa aplicación porque si no, te digo yo que vas a acabar mal. :-))


    Enrique Martínez Montejo
    [MS MVP - Visual Studio y Tecnologías de Desarrollo]

    Nota informativa: La información contenida en este mensaje, así como el código fuente incluido en el mismo, se proporciona «COMO ESTÁ», sin garantías de ninguna clase, y no otorga derecho alguno. Usted asume cualquier riesgo al poner en práctica, utilizar o ejecutar lo recomendado o sugerido en el presente mensaje.

    Si esta respuesta le ha resultado útil, recuerde marcarla como satisfactoria.

    Si usas Visual Basic .NET y deseas ser productivo y feliz, se inteligente y activa la instrucción
    Option Strict.

    domingo, 24 de julio de 2016 15:40
    Moderador