Imprimir página | Cerrar ventana

Problema con Sendkeys

Impreso de: Foro de Access y VBA
Categoría: Access y VBA
Nombre del foro: Access y VBA
Descripción del foro: Foro de programacion en Access (Con código y sin código)
URL: http://www.mvp-access.com/foro/forum_posts.asp?TID=83052
Fecha de impresión: 12/Diciembre/2017 a las 22:44


Tema: Problema con Sendkeys
Publicado por: AmadeoIsaboya
Asunto: Problema con Sendkeys
Fecha de publicación: 06/Septiembre/2017 a las 18:53
Buenas tardes,
Recientemente he cambiado de ordenador y con él también de sistema operativo (Windows 10). En cambio, sigo empecinado en usar Access 2003 y VBA porque nunca me gustaron las versiones posteriores y sobre todo porque temía 'perder' mis queridas bases de datos y la programación y automatización que tengo hecha en ellas.
Después de un sin número de vicisitudes (faltaban complementos, referencias, ocx, etc., el Visual descatalogado por Microsoft, mi versión de Access sin soporte, el Jet en el olvido) conseguí por fin hacer funcionar Access 2003 en mi nuevo ordenador, pero ahora me he encontrado con un problema hasta el momento insoluble, y es que Windows 10 por cuestiones de seguridad no acepta el comando Sendkeys y me da el error 70 de acceso denegado.
La verdad es que en mi programación hice uso y abuso de Sendkeys y no tengo prácticamente ningún formulario en el qué su código no recoja este comando varias veces.
Por internet encontré una posible solución, alguien había creado una función con ese nombre y sustituía el comando, pero a mí no me funcionó porque lo que hacía la función era escribirme directamente en el código lo que yo quería introducir en un campo o en un control de formulario. Afortunadamente había clonado la base de datos y no fue nada irreparable, excepto que perdí también la función y ahora no la encuentro.
Supongo que este problema lo habrán padecido muchos usuarios, al parecer con Windows 7 y 8 ya se producía, por lo que espero que alguien me podrá dar una solución.
Gracias de antemano.



-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)



Respuestas:
Publicado por: JuanW
Fecha de publicación: 07/Septiembre/2017 a las 10:30
Hola:

Tu mismo lo dices:"uso y abuso de Sendkeys".

Mi consejo es que lo uses lo menos posible. Hay alternativas en VBA para (casi) todo.

Saludos


Publicado por: JuLoMi
Fecha de publicación: 07/Septiembre/2017 a las 10:43
en estos casos, yo utilizo el Wscript..

Public Function ESPECIAL_SendKeys(Quines)
     Dim WshShell
     Set WshShell = CreateObject("WScript.Shell")
     WshShell.SendKeys Quines
     Set WshShell = Nothing
End Function

por ejemplo, para 'Ocultar el Panel de Exploración'
  
  ESPECIAL_SendKeys "{F11}"  


-------------
Si se puede imaginar..., SE PUEDE HACER!


Publicado por: AmadeoIsaboya
Fecha de publicación: 08/Septiembre/2017 a las 20:05
Gracias por tu ayuda, esta es con ligeras variaciones la función que había probado y que no me sirve porque en vez de escribirme en los controles de un formulario lo hace en el código de un módulo.
De todos modos he comprobado tu función y, como decía, me hace lo mismo: no envía las teclas (en este caso una cadena de texto) donde toca.
También he probado de usar el optional Wait pero en true y en false me da el mismo problema, no sé si actúa con el WshShell.
Pero como contaba cuando abrí el hilo, uso sendkeys para muchas más acciones. En el caso en que he probado el Wscript.shell podría pasar el valor por variable, pero en otros casos tendría que buscar otras soluciones individualizadas, lo que me dificulta mucho "adaptar" mis bases de datos.
Seguro que hago algo mal y que una solución debe existir, seguiré buscando...


-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: JuLoMi
Fecha de publicación: 08/Septiembre/2017 a las 20:11
lo siento, pero no "pillo" lo de "no me sirve porque en vez de escribirme en los controles de un formulario lo hace en el código de un módulo."

a mí funciona perfectamente en todos los formularios.
es de suponer que cuando ejecutas la funcion, el foco esta en el formulario/control deseado...
no llego a mas ideas.Confused


-------------
Si se puede imaginar..., SE PUEDE HACER!


Publicado por: AmadeoIsaboya
Fecha de publicación: 08/Septiembre/2017 a las 22:22
Pues yo tampoco me lo explico, de hecho con Sendkeys nunca me pasó nada parecido, siempre enviaba las pulsaciones donde correspondía. Ahora me escribe en otro procedimiento del módulo de otro formulario.
Pero tu aportación me ha hecho pensar en una cosa: solamente he probado tu solución en uno de los formularios (suele ser el primero en ser utilizado) y debería probarlo en otros escenarios, en otras condiciones, porque en el único que he hecho ensayos se cierra (aunque teóricamente después de ejecutarse tu función) para dar paso a otras instrucciones y formularios y tal vez ese sea al problema. 
Lo probaré en otro ejemplo y ya os explicaré como ha ido.
Otra vez gracias!


-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: AmadeoIsaboya
Fecha de publicación: 12/Septiembre/2017 a las 18:49
Hola de nuevo,
Ya he probado en otro formularios y persiste el problema, pero ha mejorado algo, en vez de escribirme en el código del formulario escribe en el control del formulario que ha recibido el enfoque, es decir NO donde toca.
En este caso este es mi código adaptado con la función suministrada por JuLoMi:

Private Sub IdConcepto_GotFocus() 'Este es el control que al entrar desencadena el evento
If sing2 = 12 Then Exit Sub ' Este valor hace que al recuperar el enfoque no se repita un bucle infinito
If Me.PrecioUnidad > 0 And Me.Cantidad > 0 Then ' Si el control cantidad y precio están rellenados
Dim SumParci As Double ' Variable
SumParci = Me.PrecioUnidad * Me.Cantidad 'obtener resultado suma parcial
DoCmd.GoToControl "sumaparcial" 'ir al campo correspondiente 'Quiero que escriba aquí el resultado

ESPECIAL_SendKeys SumParci
'Sendkeys SumParci, True ' devolver valor 'DESCONECTADO, substituido problema sendkeys windows10 Error 70 acceso denegado 12/09/17
End If
sing2 = 12 'evitar bucle infinito cuando el control vuelva a recibir el enfoque por 2ª vez
DoCmd.GoToControl "idconcepto" ' Vuelvo al control original
sing2 = 0 ' Vaciar variable para próxima ocasión
End Sub
----------------------------------------------------------------------------------------------------
Esto es solamente un ejemplo, tengo 490 entradas con el comando SendKeys sólo en esta BD. Con acciones muy distintas. En este caso está muy claro que puedo introducir la suma parcial de otros modos sin usar sendkeys, pero en otros supuestos la solución no será tan sencilla, hay varios formularios involucrados, instrucciones sql, etc. Debo encontrar una solución sustitutiva del Sendkeys, la función suministrada parece ser el reemplazo adecuado pero cuando consiga que la cadena que se trasmite se reciba donde se la espera.
He probado también añadir la opción Wait en los dos modos (true y false) con el mismo resultado, este optional parece no operar con WScript.Shell.
Mientras espero vuestra respuesta seguiré indagando. Gracias de antemano.


-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: Mihura
Fecha de publicación: 12/Septiembre/2017 a las 20:19
Publicado originalmente por AmadeoIsaboya AmadeoIsaboya escribió:

...., en vez de escribirme en el código del formulario escribe en el control del formulario que ha recibido el enfoque, es decir NO donde toca.

Es que eso es lo que toca .... Wink

Sendkeys envía pulsaciones de tecla al control que tiene el enfoque .... no escribe en el código del formulario.

... o yo ando más perdido que carracuca .... Ouch


Por cierto, ¿me puedes explicar que es lo que quieres que haga esa sub que has posteado?




-------------
Jesús Mansilla Castells.
Saludos desde Móstoles.

http://www.accessaplicaciones.com" rel="nofollow - Access Aplicaciones
http://www.tecsys.es" rel="nofollow - Tecsys.es


Publicado por: AmadeoIsaboya
Fecha de publicación: 12/Septiembre/2017 a las 20:51
Hola,
Esa sub en concreto pertenece a un formulario en el que introduzco compras: cada registro tiene una cantidad, un precioUnidad, un concepto, etc. El producto de la cantidad de artículos por su precio debe reflejarse en el control SumaParcial y este cálculo lo obtengo cuando el campo IdConcepto recibe el enfoque.
Observa que con DoCmd.GoToControl "sumaparcial" retiro el enfoque a "concepto" y se lo doy a sumaParcial (así funcionaba al menos SendKeys) pero por motivo que desconozco antes de que se ejecute esta instrucción WScript.shell ya escribe en el control anterior, el IdConcepto que debería haber "abandonado" previamente.
Lo de escribir en el código del formulario era con la prueba anterior, en otro caso en que uso el sustituto de SendKeys me escribe en el código no de ese formulario sino en otro en el que ejecuto una instrucción sql. Yo fui el primer sorprendido de este comportamiento y también ando muy perdido.
Y todo por la "deshabilitación" de SendKeys que hizo Microsoft y el control que hacen las últimas versiones de Windows sobre este comando, sólo que yo me entero ahora porque funcionaba con Vista hasta comprarme este ordenador nuevo. He leído (ahora) bastante sobre el tema, he visto que hay algunos que han conseguido obviar el problema desconectando el control de cuentas de usuario (UAC) o ejecutando Access con permisos de administrador, pero a mí de momento no me ha funcionado, creo que con Windows 7 y 8 se resolvía así el problema pero con Windows 10 han dado un paso más en las restricciones.
Espero haberte aclarado algo, muchas gracias por interesarte.



-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: Mihura
Fecha de publicación: 12/Septiembre/2017 a las 21:46
Eso me pareció que hacía ... pero no quería creérmelo LOL

Prueba a sustituir todo eso por ...  

me.SumaParcial = Me.PrecioUnidad * Me.Cantidad




-------------
Jesús Mansilla Castells.
Saludos desde Móstoles.

http://www.accessaplicaciones.com" rel="nofollow - Access Aplicaciones
http://www.tecsys.es" rel="nofollow - Tecsys.es


Publicado por: AmadeoIsaboya
Fecha de publicación: 13/Septiembre/2017 a las 18:32
Publicado originalmente por AmadeoIsaboya AmadeoIsaboya escribió:

Esto es solamente un ejemplo, tengo 490 entradas con el comando SendKeys sólo en esta BD. Con acciones muy distintas. En este caso está muy claro que puedo introducir la suma parcial de otros modos sin usar sendkeys, pero en otros supuestos la solución no será tan sencilla, hay varios formularios involucrados, instrucciones sql, etc. Debo encontrar una solución sustitutiva del Sendkeys, la función suministrada parece ser el reemplazo adecuado pero cuando consiga que la cadena que se trasmite se reciba donde se la espera.

 
Gracias por el aporte pero como decía la solución a este ejemplo es muy fácil, el problema es que SendKeys se repite muchas veces en mis BD y necesito una función sustitutiva pero que escriba donde lo hacía SendKeys, o "desconectar" (si es posible) el control de Windows 10 sobre el comando y no me dé el Error 70 de "acceso denegado".


-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: Mihura
Fecha de publicación: 13/Septiembre/2017 a las 19:27
Obviamente cada uno toma las decisiones que cree convenientes en los asuntos que le competen.

Dicho esto, déjame aconsejarte que elimines por completo el SendKeys de tus aplicaciones, te evitarás una continua fuente de errores y quebraderos de cabeza.

Si te decides a acometer el cambio, aquí te podremos ayudar a realizar lo que quieres sin necesidad de su uso.

Como nota, tengo que decirte que es rarísimo que alguna aplicación mía use SendKeys (cuando leí que tenías 490 usos del mismo en una sola BD se me quedaron los ojos como platos ... Confused).

Ya nos dirás. Un saludo.




-------------
Jesús Mansilla Castells.
Saludos desde Móstoles.

http://www.accessaplicaciones.com" rel="nofollow - Access Aplicaciones
http://www.tecsys.es" rel="nofollow - Tecsys.es


Publicado por: AmadeoIsaboya
Fecha de publicación: 13/Septiembre/2017 a las 19:57
Ahora mismo acabo de realizar otra prueba, he intercalado una pausa de un segundo entre el docmd.gotocontrol "sumaparcial" y la función suministrada por JuLoMi (Public Function ESPECIAL_SendKeys(Quines)), por si se trataba de un problema de "wait", de un retardo, lo que hacía que no escribiera donde quiero.
Con el increíble resultado que el cursor va al control, espera, y después se vuelve a idConcepto y ahí me escribe el resultado Confused.
Al final he hecho lo que me has dicho, meter el valor directamente: me.sumaparcial = etc., ahora sólo me queda resolver 489 casos más, y algunos serán peliagudos, por lo que recojo tu ofrecimiento de ayuda.
Nadie, nunca, en ninguna documentación, me advirtió sobre problemas o peligros del uso de SendKeys, y yo nunca tuve ningún problema. De ahí el uso-abuso del comando.
Muchas gracias y por favor, no cerréis este hilo.


-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: MexMan70
Fecha de publicación: 13/Septiembre/2017 a las 21:38
Hola AmadeoIsaboya, en la misma ayuda de Access reza asi (Al menos desde la version 2003):

Acción EnviarTeclas

Seguridad  Se recomienda evitar el uso de la instrucción SendKeys o de una macro AutoKeys con datos importantes o confidenciales. Algún usuario malintencionado podría interceptar las pulsaciones de teclas y comprometer la seguridad del equipo y sus datos.
...
...

Notas
... 

El intervalo de las pulsaciones en Access o cualquier otra aplicación puede ser muy engañoso. Por ello, se recomienda que si hay cualquier otra manera (como la acción BuscarRegistro =se refiere a parte del ejemplo que he omitido=) disponible para realizar la tarea deseada, evite el uso de la acción EnviarTeclas
< x="0" y="0" width="99999" height="99999" id="hc_extension_off">< x="0" y="0" width="99999" height="99999" id="hc_extension_highcontrast">< x="0" y="0" width="99999" height="99999" id="hc_extension_highcontrast_back">< x="0" y="0" width="99999" height="99999" id="hc_extension_grayscale">< x="0" y="0" width="99999" height="99999" id="hc_extension_grayscale_back">< x="0" y="0" width="99999" height="99999" id="hc_extension_invert">< x="0" y="0" width="99999" height="99999" id="hc_extension_invert_back">< x="0" y="0" width="99999" height="99999" id="hc_extension_invert_grayscale">< x="0" y="0" width="99999" height="99999" id="hc_extension_yellow_on_black">< x="0" y="0" width="99999" height="99999" id="hc_extension_yellow_on_black_back">

-------------
OneDrive: https://1drv.ms/f/s!AhsRUsxKwte3gVJR2a-FgxJL8H6R


Publicado por: AmadeoIsaboya
Fecha de publicación: 14/Septiembre/2017 a las 20:42
Hoy he seguido con la revisión - renovación de esta base de datos. El caso de hoy ha sido mucho más laborioso (como suponía) pero explica a la perfección el porque del uso excesivo de sendkeys.
Se trata del primer ejemplo en el que usé la función sustitutiva de SendKeys, aquel en que os conté que me escribía en el código de otro formulario.
La funcionalidad de este formulario concreto es pasar desde Excel los movimientos bancarios (son cadenas de texto). Para que me sirvan estos "asientos" debo añadirles la entidad bancaria y extraer la fecha del movimiento e insertarla en un campo.
El problema aparecía cuando pulsaba el botón para denominar la entidad bancaria (tengo un botón para cada una). Tengo un bucle que recorre todos los registros y en cada uno insertaba el nombre del banco seleccionado mediante el envío de Sendkeys.
¿Por qué Sendkeys y no me.banco = Strbanco?
Pues porque el control - campo de entidad bancaria es un cuadro combinado en el que puedes elegir manual e individualmente cada uno de ellos, desplegando y clicando o escribiendo. Si le pasas una cadena por Visual Basic te da el error de que el campo no admite ese tipo de datos (espera el IdBanco, no su nombre), cosa que NO PASABA con sendkeys porque era como si yo mismo tecleara la entidad en cada registro.
Diréis que muy fácil, como cada banco tiene su Id, cuando pulses el botón mándale este dato y no el nombre. Pero no es tan sencillo, todos los botones tienen exactamente el mismo código y remiten a una única función a la que paso por variable el título del botón. Así cuando cambio de banco, introduzco uno nuevo, etc. el proceso es sencillísimo, basta cambiarle el título a un botón o crear uno nuevo con su título. Y no quiero renunciar a esta virtualidad, los años me han demostrado que los cambios en los bancos son constantes, el que más utilizo ha cambiado 3 veces de denominación. Además, cuando creo bases de datos procuro darles un enfoque "externo", no me dedico a programar pero nunca se sabe si algún día le puedo pasar esta aplicación a otro que utilice otros bancos, otras cuentas, etc. 

Solución: Ha sido extraer el idBanco mediante un dlookup que me devuelve el ID del mismo por su nombre. Y he tenido que pasar un buen rato recordando y probando la sintaxis exacta hasta encontrar la correcta. Y es que estoy oxidado en VBA, lo reconozco.
Seguimos, sólo me quedan unos 485 casos que resolver mientras mantengo la BD operativa y procuro no inundarla con registros de prueba mientras hago los cambios. Pero tiene un lado positivo, me obliga a estudiar, repasar y ensayar en Visual Basic y aparte de quitarme el óxido me gusta, así que no hay mal que por bien no venga.



-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: Mihura
Fecha de publicación: 14/Septiembre/2017 a las 20:56
Me da que complicas muchísimo lo básico ...

- deberías tener una tabla con los bancos (id, nombre, ....)
- deberías tener un cuadro combinado (Me.CboBanco) con los id y nombres de los distintos bancos

Una vez que seleccionas el banco:
- en el valor Me.CboBanco tienes el id del mismo
- en el valor Me.CboBanco.Column(1) tienes el nombre del banco
- tu botón de proceso cogerá estos datos y hará lo que deba

Cuando el nombre del banco cambie, lo cambias en la tabla y asunto resuelto, es tan simple como eso.

Un saludo.







-------------
Jesús Mansilla Castells.
Saludos desde Móstoles.

http://www.accessaplicaciones.com" rel="nofollow - Access Aplicaciones
http://www.tecsys.es" rel="nofollow - Tecsys.es


Publicado por: AmadeoIsaboya
Fecha de publicación: 18/Septiembre/2017 a las 20:35
Tengo la tb bancos y el cuadro combinado que lee la misma, como recomiendas. pero no es tan fácil como cambiar el nombre del banco. Si lo hiciera así, cambiaría el nombre en todos los registros anteriores, de modo que en los que figuraba "Sa Nostra" ahora serían "BMN" y dentro de muy poco todos estos serían "Bankia". Lo mismo pasaría con los proveedores, por ejemplo.
De todos modos ese problema está solucionado con el Dlookup. Ahora estoy centrado en resolver el problema de SendKeys en otro formulario, ya lo había pulido todo y ahora al abrir el formulario me da un error, me pide un parámetro basado en un cuadro combinado del mismo. No tuve la precaución de cerrar y abrir este form cuando "solucionaba" cada una de las sub que contiene por lo que ahora no sé dónde pueda estar el error, pues no salta un código de error de VBA sino un mensaje de Access que no da opción a depurar el código incorrecto.
Así que vuelta a empezar, esta vez paso a paso, procedimiento por procedimiento, después probar, y no pasar al siguiente hasta que resuelvo el anterior.
Y ahora me he encontrado con un problema nuevo: utilizando el Dlookup para obtener el idProveedor, todo funcionaba de maravilla hasta que seleccioné un proveedor llamado "S'Estació". Ya me he mirado el hilo magistral en el qué se tratan los problemas de cadenas que contengan comillas pero en mi caso todavía no he podido encontrar la solución, aunque supongo que lo conseguiré.
Y con tantas tardes de VBA ha surgido otro pequeño pero molesto inconveniente. Mi VB no acepta el scroll del ratón, por lo que se dificulta navegar por tantas y largas páginas de código. He buscado en este foro y no he encontrado nada, por lo que lanzo esta cuestión. Si encontráis que se está convirtiendo demasiado en una miscélanea puedo abrir otro hilo.
Muchas gracias por vuestra ayuda.





-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: JuLoMi
Fecha de publicación: 18/Septiembre/2017 a las 21:17
yo uso el IndenterVBA, disponible aquí:

https://www.add-ins.com/macro-products-for-Microsoft-Excel/how-to-indent-vba-code/how-to-indent-vba-code.htm



-------------
Si se puede imaginar..., SE PUEDE HACER!


Publicado por: JuLoMi
Fecha de publicación: 18/Septiembre/2017 a las 21:21
perdon, me he confundido y lo que pedias es el "RuedaVBA"

No sé de donde lo saque, pero si me das un email te envio el .ZIP (1298 Kb)


-------------
Si se puede imaginar..., SE PUEDE HACER!


Publicado por: JuLoMi
Fecha de publicación: 18/Septiembre/2017 a las 21:32
encontrado!
http://www.mvp-access.com/buho/ficheros/ruedaratonVBA.zip


-------------
Si se puede imaginar..., SE PUEDE HACER!


Publicado por: AmadeoIsaboya
Fecha de publicación: 19/Septiembre/2017 a las 17:53
Perfecto! Funciona de maravilla. Muchas Gracias.

-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: lbauluz
Fecha de publicación: 19/Septiembre/2017 a las 18:04
¿Se puede cerrar el hilo?

-------------
Quod natura non dat, Salmantica non præstat


Publicado por: AmadeoIsaboya
Fecha de publicación: 19/Septiembre/2017 a las 23:36
Os podría seguir contando los avatares de modificar todos los procedimientos en que incluí SendKeys, desgraciadamente muchos, pero me temo que se va a convertir en una miscelánea de casos.
Por lo que sea, a mí no me funciona la función pasada por JuLoMi y que ya había probado con ligeras modificaciones, sacada de otro foro.
Hoy mismo, después de solucionar el problema de las dichosas comillas (1000 gracias a Patxi Sanz, a EmilioVe por su fenomenal trabajo publicado en este foro) el problema ha radicado en sustituir un Sendkeys que enviaba la pulsación %4 (alt+4) a un botón de un formulario que a la vez abría otro formulario relacionado con args. Pues bien, como no sé dónde hayan acabado esas teclas (no se ha abierto nada), he decidido sustituir el sendkeys por una llamada a la sub del botón. Poniéndole Call delante y sin ponerlo, abriendo el formulario en el que radica el botón y pasándole el enfoque antes de ejecutar la instrucción, y 100 pruebas más sin resultado, por el momento. Mañana más, pero si no llego a la solución ya buscaré en el foro o abriré otro hilo ad hoc.
Sólo para dejar constancia de que sendKeys a mí JAMAS me dió ningún problema, y puedo dar fe que la he ejecutado en miles de ocasiones, con otros programas en funcionamiento, en diferentes ordenadores, y por muchísimo tiempo. Pero por algo se habrá hecho, quiero creer.
En fin, muchas gracias. Puede cerrarse el hilo.



-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: AmadeoIsaboya
Fecha de publicación: 27/Septiembre/2017 a las 19:09
Buenas tardes,
Estas semanas he estado sustituyendo el Sendkeys en varios formularios, y salvo algunos problemillas iniciales con la sintaxis del Dlookup he podido solucionarlo todo, había podido hasta el momento. (Este post se empezó cuando no estaba solucionado, ahora ya lo está, lo cuelgo porque creo que la información puede servir a alguien).
Para los que no hayan seguido la problemática y para abreviar, sustituir la línea de Sendkeys + cadena de texto que se enviaba a un cuadro combinado implica ahora asignar valor al combo mediante visual básic, y como buen cuadro combinado que se precie, y aunque tengamos normalmente esta columna oculta, funciona con la clave Id (autonumérico) del registro, y no por la cadena string del concepto que sea, con lo cual me veo obligado a hacer previamente ese Dlookup, obtener el ID correspondiente, y así si que puedo asignar un determinado valor a un cuadro combinado. Esto está SOLUCIONADO.
El problema actual es el siguiente: 

Tengo varios formularios que contienen subformularios. Los utilizo para introducir "operaciones", normalmente compras. Tengo uno de operaciones genéricas y otro que utilizo sólo para compras en supermercados. Cada registro de los formularios principales contiene los datos generales de la compra: fecha, proveedor, medio de pago, etc. Los subformularios recogen los "detalles" de cada operación: núm. de artículos, precio unidad, CONCEPTO (artículo) y descripción.
Ese campo concepto es un cuadro combinado en el que puedes elegir un artículo, introducirlo directamente, o bien captarlo de la tabla "TiposDeAnotación" mediante un botón. Esto abre el form "Categorías", y seleccionando una de ellas se abre al lado el formulario "tiposDeAnotación" para que escojas una de ellas con un doble click.
Este envío del concepto o tipoAnotación lo hacía con Sendkeys. Para saber a que formulario tenía que enviar el valor cuando abría el frm "TiposDeAnotación" le pasaba el nombre del formulario de destino por argumentos:
Private Sub Concepto_DblClick(Cancel As Integer)
Dim datos, NameForm As String
datos = Concepto.Value 'Valor escogido
NameForm = TxtFrmOrigen 'Nombre del frm de origen pasado con Args al abrir
If NameForm <> "No consta" Then 'Valor predeterminado, el txt frm origen no habría sido rellenado al abrir
DoCmd.OpenForm NameForm 'Aunque ya está abierto, así le damos enfoque
DoCmd.GoToControl "idconcepto" 'Ir al control
Sendkeys datos 'Darle el valor
Sendkeys "{tab}" 'Validar anotación pasando al campo siguiente
DoCmd.Close acForm, "categorías" 'Cerrar este frm y por código el frm auxiliar de tipos anotación
Else
MsgBox "El formulario no consta" 'No tenemos dónde enviar los datos
Exit Sub 'Salir
End If
End Sub

Como podéis ver, con sendkeys me bastaba referirme al formulario principal de llamada y al control (del subformulario) correpondiente (que tienen el mismo nombre, es un dato fijo), y el pase de datos se producía sin ningún problema, apareciéndome el valor escogido en mi registro de detalle.
Sin Sendkeys, pensaba que se trataría de cambiar el valor de cadena del tipoAnotación (por ejemplo patatas) por su correspondiente IdTipoAnotación, así había sido hasta ahora.
Pues bien, empezó por darme "error definido por la aplicación o el objeto" sobre el que VBA no te da demasiada información. Supuse que sería por no hacer referencia al subformulario en el que estaba el campo - combo IdConcepto, así que empezó mi periplo por dar con la sintaxis adecuada: con puntos separando frm principal, sbf y campo, con signo de admiración, añadiendo la coletilla .form al subformulario, combinando, etc., etc., pero todas daba un error o el otro.
Al final deduje que el problema estaba en que, con la sintaxis correcta (si daba con ella) NO se puede pasar por variable el nombre del frm principal o por lo menos el del subformulario que contiene, en vez de 'leer' el contenido de la variable VBA me indicaba que no encontraba el campo "nombreVariable".
Busqué en el foro y no encontré hacer referencia a subformularios, pero en internet (http://www.llodax.com/Tutoriales/SintaxisSubForms.htm) encontré este artículo, al parecer de Xavi y en el qué se menciona a Eva Etxebeste, Mihura, Búho y un largo etcétera que lo han posteado, y me solucionó el problema. Es una tabla donde se escenifican llamadas a un formulario que contiene un sbf que a la vez contiene otro, y describe la sintaxis adecuada dependiendo desde dónde hagas referencia.
Entonces hice una prueba, introduje la sintaxis tal como se describe en la tabla, pero utilizando el nombre literal de form principal, subform y de campo, y voilà, objetivo conseguido. Esta es la sintaxis correcta en mi caso, llamando a un sbf desde "fuera":
Forms!SupermercadosTemporal!DetallesTemporal.Form!IdConcepto = IdDatos ' Pasar Valor
Sólo me quedaba distinguir entre uno u otro formulario de origen, cosa que conseguí con un Select Case:
        Select Case NameForm
        Case "supermercadosTemporal" 'El concepto se ha solicitado desde este form
        Forms!SupermercadosTemporal!DetallesTemporal.Form!IdConcepto = IdDatos ' Pasar Valor
        Case "Operaciones" 'El concepto se ha solicitado desde este form
        Forms!operaciones!Detalles.Form!IdConcepto = IdDatos ' Pasar Valor
        End Select

Llego a la conclusión de que no se puede hacer referencia a forms y sbfs mediante variables, pero no me atrevo a ser categórico. Alguien con superiores conocimientos podría desdecirme.
Es otra razón por la cual llegué a hacer tanto uso de Sendkeys allá por 2007 cuando creé esta BD. Vaya pues en mi descargo, aunque ahora estoy contento con el código sustitutivo, como dice JuLoMi: Si se puede imaginar se puede hacer!

Con esto he arreglado el problema de Sendkeys en 8 formularios y subformularios. Como veis la problemática se va diversificando, de no poder resolver el problema hubiera abierto otro hilo con la cuestión "referencia a subformularios" o algo así. Lo posteo por si a alguien le puede servir.
De tanto hacer DlookUp me he planteado automatizar la tarea, estoy creando un formulario en el que puedes escoger una de tus tablas o consultas, y esto te lista todos los campos que contiene con su tipo de datos. Dependiendo de estos, (ya sabéis, si string finalizar la condición where con un & "'", si es numérico, no, etc.). También solucionar si contiene apóstrofos el resultado. Cuando lo tenga listo lo colgaré en el foro por si alguien le puede sacar partido.

Muchas gracias, PUEDE CERRARSE este hilo, de surgir algún problema 'insoluble' y distinto a los mencionados abriré el hilo correspondiente.


-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)


Publicado por: pitxiku
Fecha de publicación: 27/Septiembre/2017 a las 21:09
Puedes usar variables para acceder a los elementos dentro de las colecciones Forms y Controls:

Dim varForm As String
Dim varControl As String

varForm = "Nombre del formulario"
varSecundario = "Nombre del control subformulario"
varControl = "Nombre del control"

Forms(varForm).Controls(varSecundario).Form.Controls("varControl") = IdDatos

Más o menos, escrito del tirón


Publicado por: Mihura
Fecha de publicación: 27/Septiembre/2017 a las 21:42
Es correcto, solo una puntualización, hay que quitar las comillas de "varcontrol", quedaría así:

Forms(varForm).Controls(varSecundario).Form.Controls(varControl) = IdDatos


-------------
Jesús Mansilla Castells.
Saludos desde Móstoles.

http://www.accessaplicaciones.com" rel="nofollow - Access Aplicaciones
http://www.tecsys.es" rel="nofollow - Tecsys.es


Publicado por: AmadeoIsaboya
Fecha de publicación: 28/Septiembre/2017 a las 19:12
Muchas gracias, lo probaré

-------------
Recuerden, hoy es el día de mañana que tanto les preocupaba ayer. (Dale Carnegie)



Imprimir página | Cerrar ventana