I would try to explain my situation by steps to be better understood :
I'm working on an application using .NET and MVVM Pattern and now I'm building an online service so I need to use the Remote Desktop Load Simulation Tools to prove the conections of the clients.
To do that I've configurated the Tools and I've written a VBscript using the RUIDCOM object and his functions.
The problem: I need to know the state of the execution of my script and for do that I use the RUIDCOM function PressKeyAndWaitForEvent. This function uses one parameter to know what kind of event is waiting for. My problem is that the script keeps waiting no matters what kind of event executes the program.
Any idea?
Here is the description of the function:
Long PressKeyAndWaitForEvent( Label, KeyCode, KeyFlags, szWaitString, SEvent, lTimeout)
This function is the heart and soul of the automation. It sends
keyboard input to the Remote Desktop session and also waits for an
event which is expected as a consequence of the input. Additionally,
it logs an entry in a response-times log specifying the amount of time
taken for this action.
Label: is the string used for logging the elapsed time in the
response-times log
KeyCode: is the ASCII code of the key that you want to press. Example:
asc(“f”) will send the “f” key
KeyFlags: is a combination of the following flags. This is used to
send special key combinations like Alt+”f”
VKeyFlag = 1 AltFlag = 2 CtrlFlag = 4 ShiftFlag = 8
Example: AltFlag OR CtrlFlag - this will send a combination of Alt +
Ctrl key
szWaitString: is the string associated with the event that you expect
to occur on the server as a response to sending the keys
SEvent: is one of the following accessibility events
WINDOW_EVENT = 1 MENU_EVENT = 2 OBJECTSHOW_EVENT = 3
OBJECTFOCUS_EVENT = 4
lTimeout: is the optional time out value in milliseconds. If this is
not specified, the script will wait indefinitely for the specified
event. Otherwise it will return after the timeout elapses
Return value: the function will return the time elapsed in
milliseconds between sending the keyboard input and the firing of the
server event. If the wait times out, it will return -1
Related
I'm writing a small accessibility app which simulates certain keyboard gestures, such as volume up\down.
The goal is to send a single command.
In practice, the volume goes all the way up to 100%, as if user pressed a button for couple seconds or as if the message was dispatched multiple times.
This behavior is the same with both PostMessage and SendMessage, in both C and C# (using PInvoke)
C:
PostMessage(0xffff, 0x0319, 0, 0xa0000)
C#:
PostMessage(new IntPtr(0xffff), WindowMessage.WM_APPCOMMAND, (void*)0, (void*)0xa0000);
The meaning of parameters: send to all windows, message, no source, volume up
Question: How do I issue a command which would result in Windows adjusting volume by the smallest increment?
Additionally, I attempted using WP_KEYUP and WP_KEYDOWN, without success
// dispatch to all apps, message, wparam: virtual key, lparam: repeat count = 1
User32.PostMessage(new IntPtr(0xffff), User32.WindowMessage.WM_KEYDOWN, new IntPtr(0xaf000), new IntPtr(1));
User32.PostMessage(new IntPtr(0xffff), User32.WindowMessage.WM_KEYUP, new IntPtr(0xaf000), new IntPtr(1));
The reason why the command is sent multiple times is, as pointed by Hans in the comment, I broadcasted it to all windows using 0xffff as first parameter. Every window handled it by increasing volume by a notch.
The solution to sending multiple messages is to send the message to either
The shell handle GetShellWindow()
The foreground window handle GetForegroundWindow()
Both handles adjusted the volume by one notch. GetDesktopWindow() did not work, though.
I am currently working on writing a little script on VB6 to replace a script running on a UNIX machine. What that script does is wait for the UPS system to close a switch which is then received by a COM port and a driver shuts down the UNIX machine. I want to do that for a Windows PC but it is giving me some trouble.
I built a connector, according to the schematics I have, bridging pins 7 and 8 and connecting a switch between pins 2 and 3 (RXD and TXD). Flipping the switch on is exactly the same as the UPS system doing it.
Private Sub shutdownPC()
Dim inStr As Variant
myCom.CommPort = 1
myCom.Settings = "9600,e,7,1"
myCom.RThreshold = 1
myCom.InputLen = 0
myCom.InputMode = comInputModeBinary
myCom.InBufferCount() = 0
myCom.PortOpen = True
'Shell ("shutdown.exe -s -t01")
If myCom.CommEvent = comEvReceive Then
inStr = myCom.Input
End If
End Sub
This is my code so far. I have included the MSComm library and added an MSComm object to my form. When I use comInputModeBinary and comInputModeText, I get "No variables" and "" on myCom.Input respectively. Using Powershell I can see that the COM1 port is working.
Any ideas on what I am doing wrong?
connecting a switch between pins 2 and 3 (RXD and TXD)
That would create a loopback.
That is only useful if your program is sending out test messages.
If nothing is received, then the switch is still open. When the switch closes, then the program will begin receiving the messages it sent.
Any ideas on what I am doing wrong?
Your program cannot wait passively.
It has to poll the UPS by sending bytes out and then check if any of the data is received back.
You either have to loop or put in an event handler as your code will execute before anything in the external world happens. Looping wastes battery life and slows computers down. The helpfile is at C:\Windows\HELP\COMM98.CHM.
OnComm Event
The OnComm event is generated whenever the value of the CommEvent property changes, indicating that either a communication event or an error occurred.
Syntax
Private Sub object_OnComm ()
The OnComm event syntax has these parts:
Part Description
object Anobject expression that evaluates to an object in the Applies To list.
Remarks
The CommEvent property contains the numeric code of the actual error or event that generated the OnComm event. Note that setting the RThreshold or SThreshold properties to 0 disables trapping for the comEvReceive and comEvSend events, respectively.
I have an Internet Transfer Control on a form called "inetFTP". After I call
inetFTP.Execute , "Get " & "test.zip" & " " & "C:/test.zip"
I want to pause the code execution until the download is finished, so there wouldn't be any other code operating on the file afterwards that could encounter problems. Is there a way to do that?
Normally you'd use the control's StateChanged event and monitor for at least the icError and icResponseCompleted states.
But in real programs it is often necessary to use this along with a Timer control and an elapsed time counter and cancellation flag. You'll want to be sure you don't miss any state changes (some don't seem to fire the event if they occur in quick succession), to handle timeouts, to cancel long running operations, etc.
I suspect there are some long standing bugs in the control that have never been ironed out, which is why StateChanged isn't as reliable as one might hope. Some of this may relate to inherent quirks or race conditions in the session-oriented FTP protocol. HTTP operations seem quite a bit more deterministic.
From there you'd need to change your program flow to properly fit the model of a Windows program.
A long running async operation can be started, but then there is only so much more "worth doing" in most cases until you get a completion signal (or an abort, etc.).
So you do that Execute and then exit the event handler you are running in. Once completion is signaled you resume processing in that completion event handler.
VB6 is not QBasic, and Windows is not DOS.
You can use a Timer (VBA.DateTime.Timer), see below:
Dim PauseTime As Single, start As Single
PauseTime = 2 ' pause the execution of code for two (2) seconds:
start = Timer
Do While Timer < start + PauseTime
DoEvents
Loop
I found the answer. I should insert
Do While inetFTP.StillExecuting
DoEvents
Loop
and this loops until the Internet Transfer Control finishes it job.
I am writing a cross-platform library which, among other things, provides a socket interface, and while running my unit-test suite, I noticed something strange with regard to timeouts set via setsockopt(): On Windows, a blocking recv() call seems to consistently return about half a second (500 ms) later than specified via the SO_RCVTIMEO option.
Is there any explanation for this in the docs I missed? Searching the web, I was only able to find a single other reference to the problem – could somebody who owns »Windows Sockets
Network Programming« by Bob Quinn and Dave Shute look up page 466 for me? Unfortunately, I can only run my test Windows Server 2008 R2 right now, does the same strange behavior exist on other Windows versions as well?
From Networking Programming for Microsoft Windows by Jones and Ohlund:
SO_RCVTIMEO optval
Type: int
Get/Set: Both
Winsock Version: 1+
Description : Gets or sets the timeout value (in milliseconds)
associated with receiving data on the
socket
The SO_RCVTIMEO option sets the
receive timeout value on a blocking
socket. The timeout value is an
integer in milliseconds that indicates
how long a Winsock receive function
should block when attempting to
receive data. If you need to use the
SO_RCVTIMEO option and you use the
WSASocket function to create the
socket, you must specify
WSA_FLAG_OVERLAPPED as part of
WSASocket's dwFlags parameter.
Subsequent calls to any Winsock
receive function (such as recv,
recvfrom, WSARecv, or WSARecvFrom)
block only for the amount of time
specified. If no data arrives within
that time, the call fails with the
error 10060 (WSAETIMEDOUT). If the
receiver operation does time out the
socket is in an indeterminate state
and should not be used.
For performance reasons, this option
was disabled in Windows CE 2.1. If you
attempt to set this option, it is
silently ignored and no failure
returns. Previous versions of Windows
CE do implement this option.
I'd think the crucial information in this is:
If you need to use the SO_RCVTIMEO option and you use the WSASocket
function to create the socket, you
must specify WSA_FLAG_OVERLAPPED as
part of WSASocket's dwFlags parameter
I hope this is still useful :)
I am having the same problem. Going to use
patchedTimeout = max ( unpatchedTimepit - 500, 1 )
Tested this with the unpatchedTimepit == 850
your problem is not in rcv function timeout!
if your application have a while loop to check and receive just put an if statement to check the receive buffer last index for '\0' char to check is the receiving string is ended or not.
typically if rcv function is still receiving return value is the size of received data. size can be used as last index of buffer array.
do{
result = rcv(s,buf,len,0);
if(buf[result] == '\0'){
break;
}
}
while(result > 0);
Using MS Visual Studio 2008 C++ for Windows 32 (XP brand), I try to construct a POP3 client managed from a modeless dialog box.
Te first step is create a persistent object -say pop3- with all that Boost.asio stuff to do asynchronous connections, in the WM_INITDIALOG message of the dialog-box-procedure. Some like:
case WM_INITDIALOG:
return (iniPop3Dlg (hDlg, lParam));
Here we assume that iniPop3Dlg() create the pop3 heap object -say pointed out by pop3p-. Then connect with the remote server, and a session is initiated with the client’s id and password (USER and PASS commands). Here we assume that the server is in TRANSACTION state.
Then, in response to some user input, the dialog-box-procedure, call the appropriate function. Say:
case IDS_TOTAL: // get how many emails in the server
total (pop3p);
return FALSE;
case IDS_DETAIL: // get date, sender and subject for each email in the server
detail (pop3p);
return FALSE;
Note that total() uses the POP3’s STAT command to get how many emails in the server, while detail() uses two commands consecutively; first STAT to get the total and then a loop with the GET command to retrieve the content of each message.
As an aside: detail() and total() share the same subroutines -the STAT handle routine-, and when finished, both leaves the session as-is. That is, without closing the connection; the socket remains opened an the server in TRANSACTION state.
When any option is selected by the first time, the things run as expected, obtaining the desired results. But when making the second chance, the connection hangs.
A closer inspection show that the first time that the statement
socket_.get_io_service().run();
Is used, never ends.
Note that all asynchronous write and read routines uses the same io_service, and each routine uses socket_.get_io_service().reset() prior to any run()
Not also that all R/W operations also uses the same timer, who is reseted to zero wait after each operation is completed:
dTimer_.expires_from_now (boost::posix_time::seconds(0));
I suspect that the problem is in the io_service or in the timer, and the fact that subsequent executions occurs in a different load of the routine.
As a first approach to my problem, I hope that someone would bring some light in it, prior to a more detailed exposition of the -very few and simple- routines involved.
Have you looked at the asio examples and studied them? There are several asynchronous examples that should help you understand the basic control flow. Pay particular importance to the main event loop started by invoking io_service::run, it's important to understand control is not expected to return to the caller until the io_service has no more remaining work to do.