SoloCodigo

Hola.

Yo no veo muy elegante exigir que te responda un experto en un foro donde todo el mundo aporta libremente sus ideas empeñando en ello su tiempo libre. Para poder exigir un experto, creo que lo adecuado es que contrates servicios técnicos, los pagues y ahí exige lo que te dé la gana. Si acudes vía gratuita, no te veo en ningún derecho de exigir otra cosa que sea el que se te trate con respeto. Si las respuestas que la gente te dé no te sirven simplemente la ignoras y listo.

Bueno yendo al tema.
Tu crees que el error está en 'm_background.RunWorkerAsync'  y yo digo que el error está (servido) antes, pero para salir de dudas, cacemos el momento... con un código como este...

' modifica el código como se ilustra.

Cuando tengamos claro si el objeto se ha creado o no, veremos si con posterioridad tienes algún otro problema...

Aparte de todo esto, puedo preguntarte (y esperar respuesta) a la cuestión: si eres hispanoparlante y el objeto com lo has creado tú, y el usuario final pareces ser tu mismo (no una audiencia angloparlante) podrías decirme por qué usas términos en inglés ?.. de repente has olvidado el español ?. Sólo es curiosidad, si te importuna y no quieres responder no hay menoscabo por ello.

Puedes ser más explícito ?...

Te sigue marcando el error 91  o te sale el msgbox  o... ?

Si el objeto m_background está creado correctamente (no sale el mensaje) entonces lo que falla es el parámetro 'elargumento'. Dado que es un variant, puede contener cualquier cosa, si el error 91 se produce en base a él entonces queda claro que es un objeto, caza dicho parámetro del mismo modo que hemos probado el objeto...
Ten en cuenta que "estadistica" en vb 6.0 es un string, un tipo de variable estandar y en NET un string es un objeto.
Yo cuando utilizo un variant y éste ha de contener indistintamente un variable o un objeto utilizo una propiedad para hacer la asignación adecuada (ahora bien esto funciona perfectamente en VB 6.0, nunca lo he probado con tipos de datos  sobre NET) , de la sigiuente manera:

Ahora tu llamada deberá pasar por esa propiedad.... y la adjudicación deberá hacerse de acuerdo al tipo de datos que espera el objeto  netfx20wrapper.BackgroundWorkerWrapper



Ten en cuenta que si espera un objeto (para él el  'backgroundworker' una cadena es un objeto) no puedes pasarle otro tipo de datos si lo haces por referencia. Piensa que NET por defecto recibe parámetros por valor y VB 6.0 lo hace por referencia, asi tu función StartBackground  podría ser llamada directamente como lo tienes 'StartBackground background, "Estadistica"', si en ambas partes recibieras el parámetro por valor.

También como haces un addressof el error podría estar en´el método que hace de colector, 'BackGroundWork' del que no has expuesto nada, y del que suponemos que su firma será similar a:
sub BackGroundWork(byref Parametro as string) .

No obstante recibes un error del tipo ' se espera un objeto... y tu me estás pasando otra cosa...', por lo que se supone que uno de los 2 parámetros que recibe tu función 'StartBackground' es lo que de momento falla (una vez se arregle esto no significa que no se produzca otro error, pero al menos ya habríamos pasado del error 91). Como dices que en el entorno de programación paso a paso funcionaba hemos de suponer que hacía una conversión implícita de la que se ve desprovisto (Just In time) después...


En fin como no especificas nada, la situación se ramifica. Si no aportas detalles en tu respuestas, el diálogo es probable que termine sin apenas haberse establecido.

. . . pero no hubo una respuesta a mi pregunta . . .  

¿Te refieres a esta pregunta ?:

..en ese momento manda el error '91'

Ya está contestada. Un objeto sólo se puede utilizar después que ha sido creado, no antes. Se te ha hecho saber que cualquiera de los parámetros puede producir el error, pero sólo un adivino puede saber cuál y cuando si el interesado no da ningún detalle de las pruebas que se le indican.

Si te refieres a esta pregunta:

Espero algun experto me diga como resolver este problema

, Hay dos respuestas, la 1ª básicamente es consulta al brujo con su bola de cristal. La 2ª requiere utilizar fórmulas, primero determinando cual aplicar y luego utilizando los datos para rellenar la fórmula, pero como el interesado no aporta datos, sólo llora como un niño, (doctor, me duele, que tengo?... si no nos dejas auscultarte como podremos estar seguro...) no se puede ni rellenar una fórmula, ni lo previo siquiera, elegir la fórmula adecuada.

Si te refieres a otra pregunta, yo no veo ninguna pregunta concreta.

La programación es ante todo datos, un caudal de datos, si el niño sólo llora y el doctor no puede auscultarle, si el niño sólo llora y no responde a las preguntas del doctor, si el niño sólo llora y el niño no se somete a las pruebas que el médico estima, entonces el niño debe irse a casa, para evitarnos dolores de cabeza con tantos lloros. Es probable que se muera ( el proyecto lo tube que abandonar ), pero también es probable que el niño, prepotente él, sólo quiera hacerse notar, de eso nos daremos cuenta, cuando tiempo más tarde el niño anuncie que se ha curado y no ha sido gracias a ningún doctor, entonces, si esto ocurre, reconoceremos en ello a un troll. No hay bosque sin duende ni foro sin troll.

La programación es ante todo datos, un caudal de datos lo demás es palabrería para entendernos. Si te dedicas a esto eres un caudal seco. Desde tu exposición inicial, en las otras 2 intervenciones, no has aportado ni un sólo dato de lo requerido, pero quejas y lloros... bastantes. No nos vengas con historias de otros foros ni leches, eso no son datos del problema, sobra.

Tu problema primero es tu actitud. Con prepotencia, planteas tus quejas, lloras, pero cuando se te piden síntomas respondes con más quejas y más lloros. Cuando se te indican pruebas responde con más quejas y más lloros. Como a fin de cuentas, a mi me importa un güevo, tus problemas, como además no soporto a los llorones y sobretodo porque no soy adivino, sin datos no puedo establecer qué le duele al niño. Has perdido tu crédito, al menos yo no voy a perder más tiempo contigo.

Bueno . . .  nunca faltan tipos como este . . .