I want to check how to get source filter IBaseFilter that connected to my filter input pin?
In CheckInputType method I can allow or deny connection by media type, but I need to know more information about source filter.
Transform filter is simple, 1 inout pin and 1 output pin, based on CTransformFilter.
You derive from CTransformFilter, from there:
m_pInput is your input pin
m_pInput->m_Connected is your input pin's connected peer
IPin::QueryPinInfo gets you pin data including IBaseFilter pointer you are looking for
I've found a correct way.
In CheckConnect method you can return E_FAIL to deny connection.
You can get IBaseFilter interface from IPin using PIN_INFO struct.
Related
I searched in documentation and google a little but didn't see the "arduinocloud.begin" function call without the "WiFiConnectionHandler" parameter. I am handling wifi connections with the ESP8266WiFiMulti library and don't want to change it.
Is there a way to bypass the parameter of begin and other events connected to it?
For example (golang):
type {
Product struct {
Name string
}
Customer struct {
Name string
Products []*Product
}
}
Which is the correct behavior:
GRPC honor the *Product pointer and transfer it only once.
GRPC will transfer the same *Product as many times as it associated to different Customer.
Michael,
It is not clear on your message, but I am assuming that you will send a Customer as part of your request to a gRPC server.
Golang will marshal the struct into []byte (https://godoc.org/github.com/golang/protobuf/proto#Marshal), so the message will not have such thing as a pointer. It will be just an encoded message. (see
https://github.com/golang/protobuf/blob/master/proto/wire.go#L22).
gRPC is not a Golang thing, so a pointer on a side (e.g. server) does not mean it must be a point on the other side (e.g. client).
Finally, answering your question, the expected behavior is 2. However, you may take a deeper look into proto buff serialization (https://developers.google.com/protocol-buffers/docs/encoding). I have no idea how it works, but maybe the message is compressed, so repeated []bytes maybe be discarded.
I am using the Radiohead library in an Arduino sketch for sending and receiving transmissions at 433.92 MHz. The sketch I am using works and I am able to send and receive sensor data (temperature, humidity) embedded in character strings "on air". However, I am puzzled by an implementation detail.
The recv() method of the RH_ASK class for receiving messages takes two arguments. The first is a pointer to an array of characters. This is understandable as messages are sent and received as character arrays. The second is the length of the array. This is an integer-valued number which is also passed as a pointer. Isn't it more convenient to send the integer-valued number itself i.e. pass-by-value instead of pass-by-reference?
Here is the relevant code snippet modeled on the article here.
Include the library, create an instance of the receiver object and initialize it.
// Include RadioHead Amplitude Shift Keying Library
#include <RH_ASK.h>
// Create Amplitude Shift Keying Object
RH_ASK rf_driver;
// Initialize ASK Object
rf_driver.init();
Receive a stream of characters into buffer, convert to string and parse for sensor readings.
// Set buffer to size of expected message
uint8_t buf[11];
uint8_t buflen = sizeof(buf);
// Check if received packet is correct size
if (rf_driver.recv(buf, &buflen)) // Why &buflen and not simply buflen?
{
// Message received with valid checksum
// Get values from string
// Convert received data into string
str_out = String((char*)buf);
// Thereafter, parse the string to extract sensor readings,
// and print them out.
}
I'd appreciate any help understanding the concept behind passing a perfectly good integer by reference instead of value.
Because the function needs to change the integer to the length of the received data.
https://github.com/PaulStoffregen/RadioHead/blob/e8581c127fac9bffb0ee800ae18847f673e9b4a5/RH_ASK.cpp#L462
I want to use tcdrain with termios2.
The problem is the method is defined in termios.h, but not in asm/termbits.h.
It is not possible to use termios.h with asm/termbits.h together as there would have compilation errors as some of the structs are defined in both files.
Background: I would like to control my serial transmission by invoking tcdrain after write to make sure my data have transmitted before continue execution of my program. I would like also use custom serial speeds (thus, using termios2).
How do I use tcdrain with termios2?
tcdrain is a simple ioctl call:
ioctl (fd, TCSBRK, 1)
When an app running on iOS8 is backgrounded, all uniquely identifiable information appears to be scrubbed from the Bluetooth advertising package. peripheral.name, peripheral.identifier, etc. It all goes away as soon as the app is backgrounded.
The only workaround I have discovered - to identify and range multiple bluetooth-emitting apps - is to scan and connect with a set of known devices (iPhones).
My app transmits as a peripheral, with a service that has a characteristic whose value is a unique identifier. This works.
Where I fall down is once I have read the characteristic (and identified the device) I need to range it. In the delegate call for did get RSSI, I get a peripheral object, but due to the asynchronous nature of the delegate pattern I don't know which of the discovered peripherals I am getting the RSSI signal for. Peripheral appears to remain anonymous, even after connected!
-(void) peripheral:(CBPeripheral *)peripheral didUpdateValueForCharacteristic:(CBCharacteristic *)characteristic error:(NSError *)error {
if (error == nil) {
NSString *valueString=[[NSString alloc] initWithData:characteristic.value encoding:NSUTF8StringEncoding];
NSLog(#"The new value=%#",valueString);
peripheral.delegate = self;
[peripheral readRSSI];
}
}
-(void) peripheral:(CBPeripheral *)peripheral didReadRSSI:(NSNumber *)RSSI error:(NSError *)error {
NSLog(#"Got RSSI update in didReadRSSI : %4.1f", [RSSI doubleValue]);
// but which peripheral (and associated id) did we get back??
}
This is either a limitation of Apple's spec, or something wrong with my expectations. One central to many peripherals, unlike the original Bluetooth architecture of one-to-one.
Any ideas how I can identify and range an app broadcasting as a peripheral while backgrounded? Huge thanks if so!
The CBPeripheral object itself should be unique. You can keep a dictionary of your discovered / connected peripherals along with the custom identifier from your characteristic. When the didReadRSSI delegate is called, you can check against your 'known' collection of devices to identify a specific device.