FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Detectar tipo de componente en aplicación externa
Hola foro, qué tal?
Estuve googleando esto y buscando en los foros, pero ni siquiera encontré algo que se asemeje a lo que busco. Tengo una aplicación que hace una carga automática de datos sobre una plataforma hecha en JavaScript + C#.Net + JSP + no sé qué otro lenguaje, todo en una página web. Yo supongo que está hecha en esos lenguajes y no tengo forma de comprobarlo. Mi aplicación se basa en clickear algunos botones para abrir formularos, pegar texto con CopyPaste, settear el cursor sobre campos de texto y pegar otro texto, clickear OK, etc. Todo eso lo hace correctamente, pero el problema está en que se hace a través de máquinas virtuales montadas en servidores con conexión por internet, así que cuando la conexión es un poco lenta tengo el problema de que no sé si cuando hice el proceso de "Posicionar cursor sobre campo de texto > Clickear" se haya hecho correctamente. Hice unos métodos que detectan si se abrió X ventana, si el cursor está posicionado donde debe y otras validaciones más. Pero no encuentro la forma de saber si tengo el "foco de Windows" sobre un campo de texto o no. ¿Se entiende? No tengo forma certera de saber si cuando hice "Posicionar cursor sobre campo DESCRIPTION > Hacer click" efectivamente se hizo el click y el foco está puesto sobre dicho campo de texto. Mi duda es si habrá alguna forma, por más rebuscada que sea, de verificar que el "foco de Windows" (no sé si se dirá así, por eso las comillas) está posicionado sobre un campo de texto para decirle a mi aplicación "listo amigo, ahora podés escribir". Ojalá alguno tenga una idea loca que me lo solucione. Cualquier duda sobre mi aplicación que les parezca necesaria para entender mejor me avisan. Saludos y gracias a cualquiera que se vaya a quemar las neuronas un rato por mí jeje!!! Y si a ninguno se le ocurre nada bueno, no pasa nada, no se empeora la situación |
#2
|
||||
|
||||
Hola, yo no se si entiendo lo que quieres hacer, puede que en este hilo encuentres un poco de luz.
http://www.clubdelphi.com/foros/showthread.php?t=26354 Saludos.
__________________
Confórmate con lo que tienes pero anhela lo que te falta. |
#3
|
|||
|
|||
Cita:
El tema sería yo tengo mi aplicación A y además está abierta la aplicación B que no es mía. Yo desde A hago que el cursor se posicione sobre un campo de texto en B, se hace doble click y por teoría el campo B.CampoDeTexto debe quedar seleccionado. La idea sería poder hacer A.IsCampoTexto(B.CampoFocuseado) para asegurarme que la ventana no se movió, que la velocidad de conexión no hizo que se "perdiera" el doble click y que el campo no se haya seleccionado, etc. Voy a ver si encuentro alguna manera de hacer eso mediante el handle (que lo tengo). Saludos. |
#4
|
||||
|
||||
¿No te serviria usar GetFocus() para encontrar la ventana con el foco y luego GetClassName para encontrar el nombre de la clase de dicha ventana ?
// Saludos |
#5
|
|||
|
|||
Cita:
La ventana que se abre tiene un campo tipo TEdit para "Nombre", un campo tipo TMemo para "Descripción", uno tipo TMemo para "Resultados" y tres botones. Yo sé que posiciono el cursor sobre el campo "Descripción" porque al hacer SetCursorPos(X,Y) uso otro método WaitUntilCursorPos(X, Y) para validarlo. Luego de eso simulo un doble click. El asunto es que no tengo un "WaitUntilTextAreaFocused", que eso sería lo que necesito. Al hacer el doble click (el campo ese de texto se activa con doble click) no tengo la certeza de que se hayan efectuado correctamente los 2 clicks, no tengo la certeza de que en esa ventana el foco esta seteado en ese componente. Creo que no se entiende porque mientras lo escribo me parece que no puedo dejarlo claro jaja Saludos. |
#6
|
||||
|
||||
Un Edit también es una ventana. De hecho, todo TWinControl es una ventana, y sólo una ventana puede tener el foco. Entonces, si tienes un formulario con un Edit dentro y seleccionas éste, la ventana con el foco es el Edit, no el formulario.
Haz la prueba, poniendo este código en un SpeedButton (para que el clic en el botón no te mueva el foco):
Verás que el nombre de lcase que obtienes es el del control seleccionado. // Saludos |
#7
|
|||
|
|||
Cita:
Mil gracias roman! |
#8
|
|||
|
|||
Hola. Espero que este mensaje no lo tomen como un mensaje basura. Vengo a avisar solamente que todavía no pude probar la solución de roman porque estoy tapado de trabajo. Solamente eso, así no piensan que solucioné mi problema sin explicar cómo.
Saludos! |
#9
|
|||
|
|||
Bueno, les comento que ya solucioné mi problema. Chau.
Jajaja no me voy a ir así nomás Lo solucioné con la ayuda de roman haciendo un leve cambio. En vez de utilizar GetFocus() usé una variable THandle y le asigné la ventana con GetForegroundWindow. Les muestro precisamente cómo quedó y cómo funciona:
Solamente recibe el nombre (que lo obtuve usando otra mini aplicación con GetClassName(Handle, Buffer, 255) y las mismas variables) y espera hasta que aparece focuseado, que por la lógica de mi aplicación es 100% seguro que va a estar focuseado aunque tarde mucho tiempo. El procedimiento lee el nombre del TWinControl (agradecimiento enorme a roman por explicarme que todo componente es una ventana ) y lo compara con el nombre que le pedís que encuentre. Si no lo encuentra se pausa 0.0250 segundos y vuelve a mirar. Nada más, muy simple. Muchas gracias a los que aportaron, a los que lo leyeron y no pudieron responder pero pensaron a ver si se les ocurría algo, a todos. Si algún moderador pudiera editar el nombre del topic y ponerle al principio "[RESUELTO]" y cerrarlo sería grandioso y que quede como ejemplo Saludos!!!!!!!!!!!!!! |
#10
|
||||
|
||||
Pero tú código no puede funcionar tal como está. La obtención del Handle debe estar dentro del ciclo.
// Saludos |
#11
|
|||
|
|||
Cita:
El handle lo agarro con GetForegroundWindow sí o sí, porque la ventana abierta y activa es la que tiene el componente. No te preocupes, ya lo probé y funciona como debe. Saludos. |
#12
|
||||
|
||||
Concuerdo con roman al advertir que ese código tiene algo que llama la atención. Handle tiene el valor de la ventana que deseas siempre que le de tiempo a estar abierta en ese momento. Pero el código, tal como está me hace pensar que o bien el bucle sobra, o la obtención del Hanle debe realizarse dentro del mismo. Si la función pretende esperar a que el nombre de la clase del Handle obtenido sea el que esperas, entonces tu función debe ser modificada a algo como esto:
Saludos. |
#13
|
|||
|
|||
Cita:
El handle, por otra parte, lo consigo correctamente y sin problemas porque justo antes de entrar en la función abro la ventana. No entiendo por qué les cuesta tanto creer que funciona perfectamente... |
#14
|
|||
|
|||
Hola...
Será que es por que si en ese preciso momento alguna otra ventana se coloca al frente (un popup de alguna otra aplicación), tu método puede recibir el handle de la ventana incorrecta y fallar. Saludos... |
#15
|
||||
|
||||
Cita:
Pero, en todo caso, si así te sirve, pues ¿quiénes somos nosotros para contradecirte? // Saludos |
#16
|
|||
|
|||
Cita:
|
#17
|
|||
|
|||
Cita:
Igualmente, más allá de que los pop-ups están contemplados, la plataforma con la que trabaja la aplicación es OnTop y en ese preciso momento no tiene forma de devolver ningún pop-up. Es decir, los únicos pop-ups/raise que tira son en otras circunstancias, como por ejemplo al presionar botones. |
#18
|
||||
|
||||
Cita:
Por otro lado, hay algo que no queda claro. Si tú tienes un formulario con un control de edición, GetForegroundWindow y GetFocus no devuelven lo mismo. El primero te devolverá el formulario y el segundo el control de edición. Seguramente percibes que tu programa funciona bien, y me alegro por ello. Pero cuando algo funciona por las razones equivocadas, habría que poner atención en ello en lugar de obstinarse, pues en algún momento o circunstancia, te puede fallar. // Saludos |
#19
|
|||
|
|||
Cita:
Con el procedimiento WaitUntilFieldFocused intento poner un modo de asegurar que esté seleccionado el campo, nada más. Es muy probable que sea innecesario ese procedimiento, pero lo uso para asegurarme que ningún retraso o lag del SO interfiera con lo que hago. GetForegroundWindow lo uso para obtener el handle de la ventana como varias veces dije. En ningún momento usé el GetFocus. El handle lo llamo desde ahí solamente para poder pasárselo al GetClassName, pero en todo momento sé cuál es el handle, antes y después del procedimiento. Entonces, si GetClassName me pide un handle, guardo en una variable el handle de la ventana que abrí yo mismo. Como GetClassName me va a devolver el nombre del campo de texto, antes de llamar al procedimiento hago doble click en ese campo de texto. Teóricamente siempre que llame a WaitUntilFieldFocused voy a estar en ese campo de texto, por lo que teóricamente no es necesario. Pero repito que es pura y exclusivamente para asegurarme. Remarco, dejá de llamar obstinados a las personas porque no hagan las cosas de la misma manera que vos lo harías. No podemos ser todos tan perfectos como vos. Tu actitud me hace recordar un topic sobre los users que no aparecen más por el foro, y que la gran mayoría se fueron a otros foros. Tal vez debas rever tu actitud para con las personas. Hasta acá llegaron mis ganas de usar este foro. Ya me encontré anteriormente con vos y otros users "sabiondos" que se ponen en posición absolutamente pedante y rebajan a los que preguntan. Eso no es un foro. Suerte a todos. FIN |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
abrir aplicación externa desde delphi y detectar su cierre | petete2008 | API de Windows | 2 | 10-02-2012 11:44:23 |
Ejectuando una aplicacion externa | jandrorm | Varios | 5 | 09-02-2011 16:13:56 |
Manipular aplicación externa | oabel5 | API de Windows | 30 | 27-05-2010 07:04:41 |
Aplicacion externa a c++ | alloger | C++ Builder | 1 | 28-10-2006 00:37:09 |
Manipular una aplicacion externa | lookmydoom | API de Windows | 2 | 09-08-2006 22:22:52 |
|