I am using WsReceive() function of the ATEasy framework and wanted to ask what is the meaning of the values "aioDefault
and aioDisableWsReceiveEarlyReturn" of "enMode" parameter?
I found this in the ATEASY documentation:
If enMode, input receive mode includes aioDisableWsReceiveEarlyReturn,
it prevents WsReceive from an "early return" when there is a momentary
interruption in the data being received.
And this from the online help of ateasy (By a tip of an expert from the ateasy forum) :
If sEos parameter is an empty string and aioDisableWsReceiveEarlyReturn mode flag is not used (default case), the function will return immediately if characters are found in the input buffer, and the timeout will be ignored. Using the aioDisableWsReceiveEarlyReturn flag will ensure that the function will return only if the timeout is reached or all lBytes characters were received.
Related
I need to write driver (DXE), that can transmit "couple of bytes" from virtual machine (QEMU) to the host system (OS - Ubuntu). I've read the UEFI_Spec and Guide for developers, but I still don't understand, how to write the code and what protocol should I use (tried to use TCPv4 but can't even LocateHandleBuffer).
EFI_STATUS Status = gBS->LocateHandleBuffer(ByProtocol, &gEfiTcp4ProtocolGuid, NULL, &HandleCount, &HandleBuffer);
I get:
EFI_UNSUPPORTED
If somebody can explain me or can show examples of the code, I'll be very grateful. Thanks.
For most network related protocols you first have to use the corresponding "Service Binding Protocol" to get a handle which contains the protocol you are looking for.
Use this steps to access the Tcp4Protocol:
gBS->LocateHandleBuffer(ByProtovol,gEfiTcp4ServiceBindingProtocolGuid, NULL, &HandleCount, &HandleBuffer);
// Loop over the HandleBuffer Array and pick the one you need
gBS->HandleProtocol(HandleBuffer[YourIndex], &gEfiTcp4ServiceBindingProtocolGuid, &Tcp4SBProtocol);
Tcp4SBProtocol->CreateChild(Tcp4SBProtocol, &Tcp4Handle);
gBS->HandleProtocol(Tcp4Handle, &gEfiTcp4ProtocolGuid, &Tcp4Protocol);
To check if a NIC is available you can use:
// This should return EFI_SUCCESS
gBS->LocateProtocol(&gEfiSimpleNetworkProtocolGuid, NULL, &SimpleNetworkProtocol);
There is a complete code sample for the HttpProtocol inside the Uefi specification (starting at page 1548), the Tcp4Protocol is not very different.
How do I find out if a variable has been defined in my Robot Framework script? I am doing API testing, not UI testing. I have a complex set up and tear-down sequence and, since I am interacting with multiple computers through the script, it is important to know the current state if a fatal error has occurred. I could track what I have done with some complex set of meta variables or a variable tracking list, but I would prefer to query if a particular variable has been defined and if so take the appropriate tear-down steps.
A simplified version is something like:
*** Test Cases ***
Check monitor
${monitored}= Connect to Monitor ${Monitor IP Address} ${User name} ${password}
${peer connected}= Connect to Monitor ${Peer IP Address} ${User name} ${password}
Get Information from Monitor ${IP Address}
Send Info to Peer ${buffer1}
Report back to Monitor ${Monitor IP Address}
We are assuming that the tear-down closes the connections. I want to close any connections that are open, but if I failed to open the peer connection I will close the monitor connection and fail on closing the monitor connection.
I am trying to determine if ${peer connected} is defined. Can I look into Robot Framework's variable storage to see if it is there (in that dictionary?)?
You can call Get Variables to get a dictionary of all variables, then check whether the variable you're interested in is in the dictionary.
*** Test cases ***
Example
${foo}= set variable hello, world
${variables}= Get variables
Should be true "\${foo}" in $variables
Should not be true "\${bar}" in $variables
There a pretty straightforward approach - the built-in keyword Get Variable Value returns python's None (by default) if there is no such variable defined:
${the var}= Get Variable Value ${peer connected}
${is set}= Set Variable If """${the var}""" != 'None' ${True} ${False}
I am fine with this approach. In case the variable is not defined, the test case does not fail....
${variables} Get variables
${status} Run Keyword And Return Status Evaluate $new_table in $variables
${new_table} Set variable if ${status}==${FALSE} new_tbl ${new_table}
Also possible is:
${variables} Get Variables
IF "\${dataPluginVersion}" in "${variables}"
No Operation
ELSE
${dataPluginVersion} Set Variable 0
END
Or:
${variables} Get Variables
IF not "\${dataPluginVersion}" in "${variables}"
${dataPluginVersion} Set Variable 0
END
A shorter way:
OEM-T01-99-Test-variables
[Tags] TEST
Variable Should Not Exist \${TESTDEVICE_SSH_CONNECTION}
Variable Should Exist \${TEST_NAME}
This method is more readable and less verbose than using "Get Variables" keyword, IMHO
Reference: Robotframework built-in keywords
I use twain 2.3 (TWAINDSM.DLL) in my application with HP Scanjet 200 TWAIN Protocol 1.9.
My TWAIIN calls are:
OpenDSM: DG_CONTROL, DAT_PARENT, MSG_OPENDSM
OpenDS: DG_CONTROL, DAT_IDENTITY, MSG_OPENDS
EnableDS: DG_CONTROL, DAT_USERINTERFACE, MSG_ENABLEDS
ProcessDeviceEvent: DG_CONTROL, DAT_EVENT, MSG_PROCESSEVENT
and as a result of the last call I allways get TWRC_NOTDSEVENT instead of TWRC_DSEVENT.
Could please someone help with this?
Once you use DG_CONTROL / DAT_EVENT / MSG_PROCESSEVENT, all messages from the applications message loop must be sent to the data source for processing. Receiving TWRC_NOTDSEVENT means the forwarded message isn't for the source so the application should process it as normal.
Keep forwarding all messages to the source until you receive MSG_XFERREADY which means there is data to transfer. Once the transfer is finished and you have sent MSG_DISABLEDS that's when you can stop forwarding messages to the source.
Twain is a standard, and when many company implement that standard, not all of them do the same way. Along the way to support Twain, we will learn and adjust the code to support all the different implementations.
I experienced this situation before, and this is my workaround:
Instead of placing (rc == TWRC_DSEVENT) at the beginning of code (will skip the following MSG_XFERREADY processing afterward) you can move the comparison to the end after MSG_XFERREADY processing, so that MSG_XFERREADY is always checked and processed.
(rc == TWRC_DSEVENT) is only to determine if we should forward the window message or not.
I don't know your specific situation. I ran into a similar issue because I called OpenDSM with a HWND/wId which is from another process. You should call OpenDSM with the HWND of
the active window/dialog which is owned by current process.
When I attempt to use SWI-Prolog's http_post/4, as follows:
:- use_module(library(http/http_client).
update(URL, Arg) :-
http_post(URL, form([update = Arg), _, [status_code(204)]).
When I query this rule, and watch the TCP traffic, I see the HTTP POST request and reply with the expected 204 status code both occur immediately. However, Prolog hangs for up to 30 seconds before returning back 'true'. What is happening that prevents the rule from immediately returning?
I've tried this variant as well, but it also hangs:
:- use_module(library(http/http_client).
update(URL, Arg) :-
http_post(URL, form([update = Arg), Reply, [status_code(204)]),
close(Reply).
I have a similar issue with http_delete/3, but not with http_get/3.
library docs state that http_post
It is equivalent to http_get/3, except for providing an input document, which is posted using http_post_data/3.
http_get has timeout(+Timeout) in its options. That could help to lower the latency, but as it is set to +infinite by default, I fear will not solve the issue. Seems like the service you are calling keeps the connection alive up to some timeout.
Personally I had to use http_open, instead of http_post, when calling Google API services on https...
Is there any way (C# or native) of counting the messages in a message queue (sub queue).
Using a queue name of "DIRECT=OS:slc11555001\private$\file-queue;retry"
I want to know how many messages are in the sub queue. At the moment I can see using the management console that there are in fact messages in that queue. If the OS can do it, so should I.
MQMgmtGetInfo returns 0xc00e0020 (which is not a documented error code).
I am therefore confused.
I am using code from here:
http://functionalflow.co.uk/blog/2008/08/27/counting-the-number-of-messages-in-a-message-queue-in/
The error is as follows (from http://support.microsoft.com/kb/304287):
MQ_ERROR_UNSUPPORTED_FORMATNAME_OPERATION (0xC00E0020).
MQMgmtGetInfo won't understand the subqueue format name.
The retry subqueue only really exists as a logical division of private$\file-queue queue.
You can call a count on the file-queue but not subqueues within it.
Cheers
John
From the MSDN page on subqueues:
Subqueues are created implicitly, so only the following APIs can be
used with subqueues: MQOpenQueue, MQCloseQueue, MQCreateCursor,
MQReceiveMessage, MQReceiveMessageByLookupId, MQHandleToFormatName,
MQMoveMessage, and MQPathNameToFormatName. Calling any of the other
Message Queuing APIs returns an error