mover controles entre paginas de un multipaginas

hola, Ivan !

como podria mover controles entre diferentes contenedores en tiempo de ejecucion?
pej: de una pagina a otra de un multipagina, o del propio userform a una pagina concreta o a un frame.
no se si sera posible. El metodo move no parece incluir un argumento para cambiar de contenedor [...]

si requieres 'andar moviendo' controles de un contenedor a otro [p.e. en controles multipage]...
prueba cambiando el tipo de control contenedor... de multipage... -> a un control 'TabStrip'
[funcionan y 'se ven' de manera similar, solo que 'comparten' los mismos controles] ;)
podrias administrar 'mejor' las propiedades de los controles 'contenidos' [visible, left, top, etc.]
[ademas de que ahorras 'significativamente' en el numero de controles del formulario] :D

otra alternativa [creo ya la usas] es crear controles 'al vuelo' [algo asi como controles 'dinamicos' en los formularios]

[hasta donde se]... mover controles de un contenedor a otro [cut de un contenedor y paste en el otro]...
no es 'amigable' en tiempo de ejecucion [como en tiempo de dise#o] :-((

a menos que la 'necesidad' [realmente] sea moverlos en tiempo de ejecucion
comentas algunos otros detalles ?
saludos,
hector.

hola Hector Miguel, muchas gracias de nuevo por tu ayuda

aunque me temo que me va a salir otra perorata de las mias, te comento
el nuevo fregado en el que ando.

lo 1º --> 'prueba cambiando el tipo de control contenedor... de
multipage... -> a un control 'TabStrip''

creo que es posible que me haga el apaño (parcial, por lo que despues
te comento). La verdad es que nunca he usado ninguno, y no se muy bien
por que. Voy a probarlo

y ahora a ver si me se explicar. Se trata de dar la posibilidad al
usuario de configurar sus propias fichas (fichas de 'libros, con los
tipicos campos de titulo, autor, etc ) y que pueda trabajar sobre estas
fichas personalizadas si lo prefiere (verlas, modificar datos,
imprimir,..) en vez de sobre las predeterminadas

la base serian una serie de campos y controles asociados a ellos, que
serian los predeterminados de el archivo, y que actualmente van en unos
multipage de 3 paginas, pues son 26 campos (+ sus respectivos
enunciados/labels en la mayoria de los casos)

para ello, la opcion que estaba barajando cuando envie el mensaje,
(tambien te comento despues las nuevas opciones que estoy tanteando),
era/es un formulario con un multipage (posiblemente tabstrip a partir
de ahora) que contendria todos los controles ocultos para hacerlos
visibles al seleccionarlos de un listbox y poder modificar posicion y
tamaño mediante unos spinbutton. Mas o menos todo esto parece
realizarse sin problemas ( a falta de correr mas pruebas)

aqui es cuando surge la duda, que en realidad seria para dos problemas
diferentes; ->

el 1º, y que por lo que creo entender en tu respuesta podria resolver
el tabstrip, era que, al no poder mover entre paginas los controles,
una de dos, o mujltiplicaba por 3 el nº de controles para incluir
todos en cada pagina, o limitaba las posibilidades de eleccion del
usuario a solo manipular los controles predeterminados por pagina.
Ninguna de las opciones me hace gracia

y el 2º, y quizas mas importante, seria el 'conservar' lo 'construido'
para posteriores usos. Con el problema añadido de que hay al menos
tres formularios diferentes que utilizan las fichas (uno para
impresion, ajustado estrictamente al multipage para reflejar lo mas
fidedignamente esta, otro para modificacion y un 3º para solo
visualizacion y busqueda <se que podria tener uno solo y jugar con
resice, pero es de los pocos frentes que no me he animado a abrir de
momento>). Aqui, como imaginaras el problema era traspasarlos entre
formularios (y conservarlos)

bueno, hasta aqui el 1er capitulo de este 'tomo/rollo' que te estoy
soltando. Si todavia te quedan ganas, para este 2º capitulo, he estado
tanteando otras dos opciones:->

la 1ª, y tras buscar por la web, requeriria de tirar de las APIs. He
encontrado una funcion que podria hacer parte del trabajo, pero que no
consigo hacer funcionar:->

Public Declare Function SetParent Lib "USER32" _
(ByVal hWndChild As Long, _
ByVal hWndParent As Long) As Long

la he encontrado en la web de Harvey Triana con unos ejs. que no he
conseguido adaptar ->

http://tinyurl.com/2lpn54

parece ser que permite mover controles entre formularios.

y como esta solucion no me ha cundido he tirado de otra (la 2ª), que
quizas no sea muy 'purista' , pero que puede suplir en parte mi falta
de conocimientos->

otra alternativa [creo ya la usas] es crear controles 'al vuelo' [algo asi como controles 'dinamicos' en los formularios]

en realidad, aunque hace tiempo hice una 1ª aproximacion, no habia
empezado con ello hasta hoy, y creo que he encontrado una solucion que
quizas me pueda valer (acabo de empezar con ella) conbinando
Controls.Add y mi vicio por lo que llamo 'matrices de/en hoja'

con el metodo Add he conseguido hacer mas o menos lo mismo que
'conteniendo lo controles', a falta de asignarle los controles
predeterminados a cada campo (estoy en ello si consigo acabar este
volumen) pero me quedaba el tema de la conservacion de los controles
creados en tiempo de ejecucion ( por mis pruebas me da la impresion de
que se eliminan al descargar el formulario. No se si habra una forma de
conservarlos), y aqui es donde he pensado me pueden ayudar las matrices
de hoja

como posiblemente ya sabras, actualmente trabajo con una (varias
todavia) hojas ocultas en las que tengo diversas listas que utilizo a
modo de matrices para diversas cosas (cargar controles, asignar claves,
...). En una de ellas tengo los controles de las fichas. He pensado
añadir los valores predeterminados (alto, ancho, posicion,..) y a su
vez, conservar los del usuario, para reasignarlos al abrir el
formulario correspondiente. Esto, aunque no he empezado, no creo que
tenga problemas.

lo que ya no estoy tan seguro es si puede conllevar riesgos para la
integridad del archivo. Si puede pasar algo como con las 'formas' en
hoja, que un añadir/eliminarse controles excesivo conlleve un riesgo
de corrupcion, o cualquier otro inconveniente que tu creas puede
afectar al buen uso o mantenimiento del archivo. Teniendo en cuenta que
este si seria un proceso bastante continuo, pues uno de los principales
atractivos del archivo seria la consulta / trabajo de las fichas.

bueno, disculpa el rollo de nuevo, pero te agradeceria cualquier
sugerencia/idea/problema que se te ocurra

un saludo y hasta pronto
Ivan

hola, Ivan !

... Se trata de dar la posibilidad al usuario de configurar sus propias
... y que pueda trabajar sobre estas fichas personalizadas si lo prefiere (verlas, modificar datos, imprimir,..)
... la base serian una serie de campos y controles asociados [...]
... aqui es cuando surge la duda, que en realidad seria para dos problemas diferentes; ->
el 1º, y que por lo que creo entender en tu respuesta podria resolver el tabstrip, era que
al no poder mover entre paginas los controles... o mujltiplicaba por 3 el nº de controles
... o limitaba las posibilidades de eleccion del usuario a... Ninguna de las opciones me hace gracia
y el 2º, y quizas mas importante, seria el 'conservar' lo 'construido' para posteriores usos
... problema... hay al menos tres formularios... (uno para impresion... otro para modificacion y un 3º... visualizacion y busqueda
<se que podria tener uno solo y jugar con resice, pero es de los pocos frentes que no me he animado a abrir de momento>).
Aqui, como imaginaras el problema era traspasarlos entre formularios (y conservarlos)

1) [como que]... te preguntas... y te respondes :)) [o no te apetece... o no le has entrado... o te la estas 'complicando'] :))
a) si consideras que el usuario NO podra ejercer 3 opciones 'al mismo tiempo' [o imprime... o modifica... o busca]
-> cual seria el sentido/objetivo/utilidad/... de mantener 3 formularios abiertos/parkeados/en uso/... 'al mismo tiempo' -?-
b) 'mover' controles... 'entre formularios'... y [ademas] 'conservar lo construido'... [uuhhmmmm !]
b.1) mover controles [y seguramente sus codigos asociados] entre formularios ?...
-> [probablemente] saldria mas caro el caldo que las albondigas [API's y demas 'chucherias'] :))
b.2) conservar lo construido ?...
-> prueba a traves de matrices/variables/colecciones/... de tipo publico [declaradas como tal en modulos estandar]
o [incluso] 'bajarlas'/conservarlas/... en rangos 'especificos' ;)

Si todavia te quedan ganas, para este 2º capitulo, he estado tanteando otras dos opciones:->
la 1ª, y tras buscar por la web, requeriria de tirar de las APIs. He encontrado una funcion que podria hacer parte del trabajo
pero que no consigo hacer funcionar:->
Public Declare Function SetParent Lib "USER32" _
(ByVal hWndChild As Long, _
ByVal hWndParent As Long) As Long
la he encontrado en la web de Harvey Triana con unos ejs. que no he conseguido adaptar -> http://tinyurl.com/2lpn54
parece ser que permite mover controles entre formularios.

2) no logras 'hacerla funcionar' [supongo] porque es codigo para VB [stand-alone]... NO para VBA :-((
los controles en vba no tienen una propiedad '.Container' para referirse a su objeto 'Parent' ;)

y como esta solucion no me ha cundido he tirado de otra... (acabo de empezar con ella)
conbinando Controls.Add y mi vicio por lo que llamo 'matrices de/en hoja'
... he conseguido hacer mas o menos lo mismo que 'conteniendo lo controles'
a falta de asignarle los controles predeterminados a cada campo (estoy en ello si consigo acabar este volumen)
pero me quedaba el tema de la conservacion de los controles creados en tiempo de ejecucion
(por mis pruebas me da la impresion de que se eliminan al descargar el formulario.
No se si habra una forma de conservarlos), y aqui es donde he pensado me pueden ayudar las matrices de hoja [...]

3) [creo que]... 'volvemos' a los comentarios y 'sugerencias' del punto 1 b.2 ;)

... lo que ya no estoy tan seguro es si puede conllevar riesgos para la integridad del archivo.
Si puede pasar algo como con las 'formas' en hoja, que un a#adir/eliminarse controles excesivo conlleve un riesgo de corrupcion
o cualquier otro inconveniente que tu creas puede afectar al buen uso o mantenimiento del archivo.
Teniendo en cuenta que este si seria un proceso bastante continuo
pues uno de los principales atractivos del archivo seria la consulta / trabajo de las fichas...

4) [supongo que] el 'riesgo de corrupcion' [anque latente...] dependera de los factores 'conocidos' [y uno que otro desconocido] :))

saludos,
hector.

hola Hector Miguel, gracias de nuevo

1) [como que]... te preguntas... y te respondes :)) [o no te apetece... o no le has entrado... o te la estas 'complicando'] :))

yo diria que lo 3º

a) si consideras que el usuario NO podra ejercer 3 opciones 'al mismo tiempo' [o imprime... o modifica... o busca]
-> cual seria el sentido/objetivo/utilidad/... de mantener 3 formularios abiertos/parkeados/en uso/... 'al mismo tiempo' -?-

, Dios me libre, no era mi intencion (posiblemente no me he explicado
bien). Aunque si es posible que el de impresion se abra llamado por
alguno de los otros dos, pero simplemente como 'vista previa. Ni
siquiera lleva un solo boton accesible al usuario, y solo unas gotitas
de codigo en activate y/o en deactivate.

b) 'mover' controles... 'entre formularios'... y [ademas] 'conservar lo construido'... [uuhhmmmm !]
b.1) mover controles [y seguramente sus codigos asociados] entre formularios ?...
-> [probablemente] saldria mas caro el caldo que las albondigas [API's y demas 'chucherias'] :))

probablemente, otra vez no me he explicado: tan solo me referia a que
al cerrar el form, si lo abres en el editor, los controles (no sus
datos ni sus codigos) siguieran ahi, para no tener que volver a
crearlos cuando se vuelva a llamar al formulario.

b.2) conservar lo construido ?...
-> prueba a traves de matrices/variables/colecciones/... de tipo publico [declaradas como tal en modulos estandar]
o [incluso] 'bajarlas'/conservarlas/... en rangos 'especificos' ;)

mas o menos asi me voy apañando

2) no logras 'hacerla funcionar' [supongo] porque es codigo para VB [stand-alone]... NO para VBA :-((
los controles en vba no tienen una propiedad '.Container' para referirse a su objeto 'Parent' ;)

algo de esto me temia, aunque pensaba que las APIs eran de uso global,
al menos para VB y VBA

4) [supongo que] el 'riesgo de corrupcion' [anque latente...] dependera de los factores 'conocidos' [y uno que otro desconocido] :))

gracias de nuevo, esto me tranquiliza, pues ya he conseguido
practicamente lo que buscaba, pero me quedaba este temor

un saludo y hasta pronto
Ivan

hola ivan

estoy muy interesado en lo de que el usuario pueda mover los controles
me podias mandar un archivo
mi correo es

un saludo y muchas gracias
"Ivan" escribió en el mensaje
news:
hola Hector Miguel, gracias de nuevo

1) [como que]... te preguntas... y te respondes :)) [o no te
apetece... o no le has entrado... o te la estas 'complicando'] :))

yo diria que lo 3º

a) si consideras que el usuario NO podra ejercer 3 opciones 'al mismo
tiempo' [o imprime... o modifica... o busca]
-> cual seria el sentido/objetivo/utilidad/... de mantener 3
formularios abiertos/parkeados/en uso/... 'al mismo tiempo' -?-

, Dios me libre, no era mi intencion (posiblemente no me he explicado
bien). Aunque si es posible que el de impresion se abra llamado por
alguno de los otros dos, pero simplemente como 'vista previa. Ni
siquiera lleva un solo boton accesible al usuario, y solo unas gotitas
de codigo en activate y/o en deactivate.

b) 'mover' controles... 'entre formularios'... y [ademas] 'conservar
lo construido'... [uuhhmmmm !]
b.1) mover controles [y seguramente sus codigos asociados] entre
formularios ?...
-> [probablemente] saldria mas caro el caldo que las
albondigas [API's y demas 'chucherias'] :))

probablemente, otra vez no me he explicado: tan solo me referia a que
al cerrar el form, si lo abres en el editor, los controles (no sus
datos ni sus codigos) siguieran ahi, para no tener que volver a
crearlos cuando se vuelva a llamar al formulario.

b.2) conservar lo construido ?...
-> prueba a traves de matrices/variables/colecciones/... de
tipo publico [declaradas como tal en modulos estandar]
o [incluso] 'bajarlas'/conservarlas/... en rangos
'especificos' ;)

mas o menos asi me voy apañando

2) no logras 'hacerla funcionar' [supongo] porque es codigo para VB
[stand-alone]... NO para VBA :-((
los controles en vba no tienen una propiedad '.Container' para
referirse a su objeto 'Parent' ;)

algo de esto me temia, aunque pensaba que las APIs eran de uso global,
al menos para VB y VBA

4) [supongo que] el 'riesgo de corrupcion' [anque latente...] dependera de
los factores 'conocidos' [y uno que otro desconocido] :))

gracias de nuevo, esto me tranquiliza, pues ya he conseguido
practicamente lo que buscaba, pero me quedaba este temor

un saludo y hasta pronto
Ivan