Pues eso que soy un torpe.

Tengo varias instancias de un mismo formulario y se me ocurrió enviar a una función el handle que identifica a una instancia concreta para poder hacer algo y devolver el resultado al formulario apropiado y no a otro.

El caso es que estoy en una función con un resultado obtenido y una variable con el handle de un form y no veo como llegar a ese formulario concreto para ponerle ese resultado.

¿se os ocurre como hacerlo?

Una forma muy sencilla es guardar una referencia a cada instancia de un formulario en una colección (o en un array si lo prefieres), de modo que puedas referenciar el formulario.

Ayudaría que expusieras algo de código para ver cómo estás trantando el asunto.

===================
Cómo programar con Gambas

Speed Books: informática libre.

No puse código porque lo que tengo es tan simple como parece, pero lo pongo:

Yo tengo un formulario en el que hay un textbox que debe ser rellenado con una determinada cantidad. Como esa cantidad es el resultado de una serie de operaciones, si el usuario conoce la cantidad la puede escribir, pero si no la conoce la tiene que calcular, razón por la que junto al textbox hay un pequeño botón  que le abre otro formulario donde rellena unos datos y se calcula la cantidad. Al terminar el textbox inicial aparece con la cantidad calculada.

El código del botón es


Y en el formulario CalcularCantidad hay un botón de calcular que lo que hace es calcular la cantidad adecuada, actualizar el textbox del formulario anterior y cerrarse. Para ello tengo puesto que los controles en el proyecto son públicos y lo que hago (entre otras cosas) es

Pero el problema es que puedo tener varias instancias de FormularioInicial por lo que no se como saber a cual de ellos tengo que actualizar. Entiendo que para eso está el handle. Pensé en enviar el handle al formulario de calcular de esta forma
Dim CC as new CalcularCantidad
load CC 'cargar el formulario en memoria
CC.tag=me.handle 'poner el handle del formulario en el tag del formulario de calcular
y así cuando llega el momento de guardar el cálculo y cerrar hacer lo siguiente


Por mas pruebas que hago no consigo encontrar la forma ¿Para que sirve el handle si no puedo saber a que formulario corresponde ni puedo operar directamente con él como hacíamos en las apis de windows en VB?

Soplo aquí el problema más importante es que estás tratando de forzar una solución. Creo que deberías tomarte un poco de tiempo para evaluar alternativas de diseño para luego elegir la mejor, porque si no al final terminas perdiendo mucho más tiempo haciendo prueba y error: más diseño = menos problemas.

• En primer lugar, la solución que imaginaste está restringida por el interfaz gráfico (usar un cuadro de diálogo). Esto no es necesario en absoluto para el caso que planteas.
  
  Podrías usar un control expander (o tal vez algún otro) para mostrar/ocultar las cajas que el usuario debe completar y el botón que desencadena el cálculo. Así todas las variables y funciones que tienes en el cuadro de diálogo (CalcularCantidad) pasar a ser parte del formulario INicial. Así se eliminan todos los problemas con los que estás lidiando.
  
  
• En segundo lugar, tomando la solución que planteas no necesitas referenciar el formulario. No más explicaciones, el código es más descriptivo:
  

Citar:

¿Para que sirve el handle si no puedo saber a que formulario corresponde ni puedo operar directamente con él como hacíamos en las apis de windows en VB?

Para pasarlo a métodos que requieren un handle XWindow. El problema es que quieres diseñar una solución usando elementos que no fueron pensados para usarse del modo que tú quieres.

===================
Cómo programar con Gambas

Speed Books: informática libre.

No utilizo espanders ni nada de eso porque solo sirven para que la programación no esté bien estructurada. Cada formulario debe servir para una cosa no para siete.

Yo suelo tener un formulario que sirve a la vez para altas, modificaciones y bajas. Lo único que hace es mostrar los datos pedidos (en blanco si es un alta) y ofrecer un botón donde grabar grabar (o borrar) los datos mostrados. La función de ese formulario es la que es y no debe ser otra. Si hay que calcular una cantidad y hay que pedir datos por pantalla ese es problema de otro formulario.

El problema se plantea cuando llamo a otro formulario para obtener una cantidad y este no sabe a cual de las instancias que le pudieron haber llamado tiene que devolver el dato. Yo pensé que para esas cosas estaba el handle que al fin y al cabo es un identificador de form pero se ve que no y no consigo resolverlo. Estoy haciendo chapuzas por medio de variables públicas y tal porque no encuentro la forma correcta de hacerlo.

Soplo, hay varias cosas que me llaman la atención sobre lo que dices.

Primero, estás incurriendo en una contradicción:

Citar:

Cada formulario debe servir para una cosa ...

Yo suelo tener un formulario que sirve a la vez para altas, modificaciones y bajas.

Segundo, estás confundiendo conceptos:

Citar:

No utilizo espanders ni nada de eso porque solo sirven para que la programación no esté bien estructurada. Cada formulario debe servir para una cosa no para siete.

Esto que vendría a ser, ¿el paradigma POFS? (Programación Orientada al Formulario de Soplo)  

Fuera de broma, el uso de controles como expander (u otros) de ningún modo te obligan a realizar una programación desestructurada. Por otra parte, un formulario suele servir en una aplicación para muchas cosas (lo que no significa sobrecargar de controles el formulario).

Citar:

La función de ese formulario es la que es y no debe ser otra. Si hay que calcular una cantidad y hay que pedir datos por pantalla ese es problema de otro formulario.

Estás confundiento los conceptos de cohesión y desacoplamiento que debes aplicarlos a las rutinas y no a los formularios.

Citar:

El problema se plantea cuando llamo a otro formulario para obtener una cantidad y este no sabe a cual de las instancias que le pudieron haber llamado tiene que devolver el dato.

Las dos opciones que te propongo tienden a solucionar precisamente ese problema.

En la seguna opción que mencioné en el post anterior, puedes reemplazar la propiedad de tipo TextBox por el tipo form, específicamente debes colocar como tipo el nombre del tu formulario principal (PROPERTY frm AS MiFormInicial) y en la llamada establecer esa propiedad mediante la palabra clave ME. Así le pasas una referencia de la instancia correcta de tu formulario Inicial. Luego para mostrar el resultado, una referencia calificada a través de la propiedad miembro (PRIVATE $frm AS MiFormInicial), algo como: $frm.TextBox1.Text = Resultado

Citar:

Yo pensé que para esas cosas estaba el handle que al fin y al cabo es un identificador de form pero se ve que no y no consigo resolverlo.

El handle de un formulario es el identificador XWindow de su ventana.

Citar:

Estoy haciendo chapuzas por medio de variables públicas y tal porque no encuentro la forma correcta de hacerlo.

Pues mira con detenimiento las opciones que te propongo en mi post anterior. Probablemente la segunda sea la que más te guste.

Una última cosa. A mi me parece que tú lo que necesitas son vacaciones, despejar un poco tu mente.

Saludos Soplo.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Citar:

Cada formulario debe servir para una cosa ...

Yo suelo tener un formulario que sirve a la vez para altas, modificaciones y bajas.

No es una contradicción. La labor de ese formulario es mostrar una información y grabarla/borrarla dependendiendo de una variable (que suele ser el tag). Osea que el código es el mismo y solo al pinchar el botón se mira si es tag un addnew, si es modificar un update y si es borrar un delete.

Citar:

Esto que vendría a ser, ¿el paradigma POFS? (Programación Orientada al Formulario de Soplo)

ja ja ja No hombre. Es que los formularios deben ser muy claros y concisos. Cuanto mas claro lo que se pregunta y la intención con que se pregunta mas amigable es la aplicación. Si por ejemplo es un formulario de clientes allí debería mostrarse la información de clientes y nada mas que la de clientes.

No digo que un espander sea malo per se. Lo que pasa es que si tienes que calcular algo y sacas un container que pregunta dos cositas y ya está pues bien, pero si tiene que preguntar varias y hay diversas opciones que el cliente tiene que elegir estas mezclando un problema inicial con el segundo problema del cálculo y eso hay que mantenerlo separado.

Citar:

Pues mira con detenimiento las opciones que te propongo en mi post anterior. Probablemente la segunda sea la que más te guste.

Eso que has puesto es muy interesante porque no caí en la posibilidad de utilizar property sobre clases ya existentes. Yo lo veía como un medio para crear componentes nuevos. Es muy interesante y tengo que explorar las implicaciones de ello pero estoy muy interesado en explorar ese camino. A veces caigo en vicios o costumbres o técnicas de vb. Lo que pasa es que no me vale en este caso porque ese cálculo depende de algunos datos que tiene que escribir y elegir el usuario. Entre otras cosas hay un treeview de donde elige la categoría apropiada y en función de ello se utilizan unos valores u otros para el cálculo.

Por tanto no puede ser una propiedad puesto que el resultado de esa propiedad depende de algunas elecciones del usuario en un formulario.

Citar:

Una última cosa. A mi me parece que tú lo que necesitas son vacaciones, despejar un poco tu mente.

seee estoy muy quemado. Llevo dos años sin vacaciones y el curro en mi caso es muy estresante. No soy un controlador de vuelo en un aeropuerto pero casi je je je. Llevo unos dias que por no pensar ni siquiera cojo un libro.

Para colmo llevan algún tiempo con la idea de que alguien se tiene que ir a La India y yo tengo todos los boletos porque cuando ocurrió lo mismo con Alemania alguien acabó en Alemania y era quien debía ser osea que me temo lo peor. Mira tú si me tengo que ir a Banghalore por algunos meses la gracia que va a ser. Por eso no me atrevo a sacar mi aplicación de recogida de datos en planta. Sería una irresponsabilidad poner eso y luego irme lejos. Supongo que esto suena a dar pena (no es para tanto) pero si que tengo la cabeza llena de mogollones ja ja ja

En fin ...
 

Citar:

ja ja ja No hombre. Es que los formularios deben ser muy claros y concisos. Cuanto mas claro lo que se pregunta y la intención con que se pregunta mas amigable es la aplicación. Si por ejemplo es un formulario de clientes allí debería mostrarse la información de clientes y nada mas que la de clientes.

No digo que un espander sea malo per se. Lo que pasa es que si tienes que calcular algo y sacas un container que pregunta dos cositas y ya está pues bien, pero si tiene que preguntar varias y hay diversas opciones que el cliente tiene que elegir estas mezclando un problema inicial con el segundo problema del cálculo y eso hay que mantenerlo separado.

De acuerdo, es que la complejidad de los cálculos y del formulario no eran visibles a partir de tus comentarios. Pero, ¿no podría servirte usar un control TabStrip para distribuir los controles en conjuntos lógicos por medio de pestañas? Es que de lo que cuentas, parece tratarse de un problema de diseño de interfaz, no que haya algún tipo de restricción lógica que te obligue a usar otro formulario (otra clase). Las rutinas que realizan los cálculos bien podrían ser parte de la clase de tu formulario Inicial o de otro módulo o clase y los controles que permiten la selección y carga de datos para los cálculos estar en el mismo formulario Inicial.

Ahora bien, no estoy diciendo que usar un formulario en ese caso me parezca mal: es una opción válida. Sólo digo que no estás obligado a ello y hay otras opciones de diseño que son también válidas.

Citar:

Eso que has puesto es muy interesante porque no caí en la posibilidad de utilizar property sobre clases ya existentes. Yo lo veía como un medio para crear componentes nuevos. Es muy interesante y tengo que explorar las implicaciones de ello pero estoy muy interesado en explorar ese camino. A veces caigo en vicios o costumbres o técnicas de vb. Lo que pasa es que no me vale en este caso porque ese cálculo depende de algunos datos que tiene que escribir y elegir el usuario. Entre otras cosas hay un treeview de donde elige la categoría apropiada y en función de ello se utilizan unos valores u otros para el cálculo.

Por tanto no puede ser una propiedad puesto que el resultado de esa propiedad depende de algunas elecciones del usuario en un formulario.

No comprendo esto.

De lo que explicaste inicialmente se desprende que una vez hechos los cálculos devuelves el un único valor a un control TextBox de tu formulario inicial. En la segunda propuesta que te hago, la propiedad en el formulario del cuadro de diálogo recibe justamente una referencia a ese control TextBox (desde una instancia en particular de tu formulario Inicial); finalmente el cuadro de diálogo utiliza esa referencia para escribir el resultado.

No veo por qué no te serviría.

Citar:

seee estoy muy quemado. Llevo dos años sin vacaciones y el curro en mi caso es muy estresante. No soy un controlador de vuelo en un aeropuerto pero casi je je je. Llevo unos dias que por no pensar ni siquiera cojo un libro.

Para colmo llevan algún tiempo con la idea de que alguien se tiene que ir a La India y yo tengo todos los boletos porque cuando ocurrió lo mismo con Alemania alguien acabó en Alemania y era quien debía ser osea que me temo lo peor. Mira tú si me tengo que ir a Banghalore por algunos meses la gracia que va a ser. Por eso no me atrevo a sacar mi aplicación de recogida de datos en planta. Sería una irresponsabilidad poner eso y luego irme lejos. Supongo que esto suena a dar pena (no es para tanto) pero si que tengo la cabeza llena de mogollones ja ja ja

En fin ...

Pues si aceptas un reemplazo yo estoy dispuesto a ir a Bangalore.  

===================
Cómo programar con Gambas

Speed Books: informática libre.

Bueno... ¿Algo así no te vale?
En el formulariouno del que tienes varias instancias


En el formsecundario:


No lo he probado, per creo que es lo que quieres ¿no?

Saludos

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

Shordi, no he examinado el código que propones en profundidad, pero a primera vista parece que funcionaría. Sin embargo tiene un problema en cuanto a la eficiencia: estás creando una nueva instancia del formulario secundario (el cuadro de diálogo) por cada instancia del formulario principal.

Más allá de eso y sobre cómo pasas la referencia del formulario, es muy similar a la segunda opción que le propuse a Soplo.

===================
Cómo programar con Gambas

Speed Books: informática libre.