[Delphi] Sendinput terwijl PC gelocked is.

[Quitter3]

Voor het maken van een automatisch testtool, maak ik gebruik van SendInput om Keyboard input van een gebruiker te simuleren naar een externe applicatie.

Dit werkt op zich prima. De test willen we draaien op een server, maar die locked automatisch na 5 minuten. Vervolgens werkt de SendInput niet meer.

Is hier een workaround voor? Of is er een andere manier om te zorgen, dat ik toch Keyboard input kan sturen naar een app, als de pc gelocked is?

[pjvandesande]

Kwa SendInput werkt dat niet, dit is denk ik niet mogelijk maar waarom zou je willen werken met SendInput en niet gewoon dmv sockets bijvoorbeeld acties uitvoeren?

[Tomatoman]

Het lijkt me dat als SendInput op een gelockte computer werkt dat een enorme veiligheidsblunder zou zijn. Het lijkt me daarom voor de hand liggen dat er geen enkele workaround bestaat. Als je die toch weet te vinden, zal Microsoft je hartelijk bedanken voor de vondst en een securitypatch uitbrengen om de workaround onmogelijk te maken.

[curry684]

SendInput simuleert (net als keybd_event) een hardwarematige toetsaanslag. Op het moment dat de computer gelocked is zal deze op de WinLogon desktop uitgevoerd worden en dus idd nooit bij je programma aankomen. Je kunt proberen via de WM_CHAR messages te werken, messagepumps werken wel gewoon door.

Alternatief is er gewoon voor zorgen dat je regelmatig dummy input genereert dmv SendInput, dan lockt die bak gewoon nooit

[Quitter3]

Ik ben het nu via WM_KEYDOWN, WM_CHAR, WM_KEYUP aan het proberen.

Echter krijg ik dit niet voorelkaar. Ik heb de handle naar de externe app, maar er gebeurt niks.
Handle heb ik gecheckt met Spy&Capture en met Winsight32

Ik heb de externe app (is van mijzelf) in debug gedraaid, en hij ontvangt de messages wel (in OnMessage), maar vervolgens gebeurt er niks.

Ik snap er niks meer van. Heb bijna alles hierover al gelezen, maar het werkt gewoon niet.

[Gerco]

Stuur je de message wel naar de control die deze moet ontvangen ? Of stuur je die naar het main window? Volgens mij moet je een WM_CHAR achtige message afleveren bij de control die hem moet verwerken (de textbox of button dus).

[ Voor 6% gewijzigd door Gerco op 28-01-2005 09:02 ]

[riezebosch]

Je moet even met AttachThreadInput jouw thread aan die van de actieve thread knopen. Anders heb je geen toestemming om er WM_CHAR messages heen te sturen, en zullen deze dus genegeerd worden.

edit:

Zie ook mijn topic

[ Voor 23% gewijzigd door riezebosch op 28-01-2005 11:09 ]

[Quitter3]

De messages worden inderdaad naar het mainwindow gestuurd.
Tijdens debug zag ik inderdaad, dat de messages niet in het goede control terechtkomen.

Dit gaat dus heel lastig worden. Ik weet namelijk niet altijd welk control de message moet hebben.

[riezebosch]

Waarom weet je dat niet? Dat registreer je dan toch gewoon ook tijdens het opnemen? Lees ook even deze reactie van me over op welke niveaus je objecten kan herkennen.

[OZ-Gump]

Idee zou verder misschien zijn om de gestuurde message een herkenningspunt te geven voor de control die je in je applicatie moet hebben. Binnen je applicatie kun je dan die message redirecten naar de betreffende control.

Wanneer testen de enige reden is voor deze input, vraag ik me nog steeds een beetje af of dat niet makkelijker kan dan met messages te gaan zitten knutselen. Tenzij het gaat om een applicatie die je niet in eigen beheer hebt?

[Quitter3]

Het gaat om het testen van een eigen applicatie. Maar het testtool dat we maken zal ook aan enkele klanten geleverd worden.
Het moet dus eenvoudig werken.

Het product wat getest moet worden is een thin client voor een databse applicatie.
Deze client bouwt schermen dynamisch op uit een definitie file (een beetje browserachtig).

De testtool werkt nu goed met Send_Input. Maar dan mag de PC niet gelocked worden.
Op zich niet zo'n probleem, maar ik had liever dat het simpel (voor de tester) met messages kon.

[OZ-Gump]

Is het geen mogelijkheid om door middel van starten met schakelopties testbestanden op te geven aan de te testen applicatie? En dat je in je eigen applicatie aan de hand van dat bestand een testrapport opslaat of mailt? Automatisch mailen met Delphi in combinatie met de INDY componenten stelt bijvoorbeeld al niet veel voor, en dan krijgt de beheerder automatisch een mailtje met bevindingen.

Ook het register (of the good old HD) kan een manier zijn om gegevens van en naar je applicatie te krijgen. Misschien niet de allermooiste oplossing, maar wel een mogelijkheid die volgens mij werkt, ook wanneer de PC gelocked is.

Toevoeging:
Een andere mogelijkheid is om een COM interface te bouwen waarmee je de te testen aplpicatie laat bedienen door de testapplicatie. Denk bijvoorbeeld aan de mogelijkheden die bijvoorbeeld de Office toepassingen bieden.

[ Voor 16% gewijzigd door OZ-Gump op 28-01-2005 14:44 ]

[curry684]

Je kunt overigens met GetInputDesktop wel detecteren dat je gelockt bent. Helaas kun je alleen niet met SwitchDesktop terug unlocken

[Quitter3]

Aansturing via COM hebben we al een oplossing voor. Deze oplossing maakt alleen geen gebruik van de client. Deze gaat rechtstreeks naar de Applicaite server.
Ook hebben we de mogelijkheid om tramsactielogs van klanten af te spelen. Maar ook deze gaan rechtstreeks naar de applicatie server. Dit wordt voor stresstesting gebruikt.

Met het afspelen van via sendinput willen we juist de client meenemen in de test.
Dus een volledige productiedag naspelen. Vanaf vershillende machines gebruiker input afspelen en nadien de end of day batches draaien.
En dan aan het eind alle output vergelijken.

Het feit dat de pc niet gelocked mag zijn is niet een heel groot probleem.
Ik wilde alleen graag weten waaron het messages verhaal niet werkte.
Ik heb er namelijk een hekel aan als iets niet lukt en ik weet niet waarom.