Prior to iOS8.3 we were able to get the caller number using "CTCallCopyAddress". In iOS8.3 and above the address received using "CTCallCopyAddress" is 0x0, so unable to get the Caller Number. Apple has restricted the access to caller number in iOS8.3 and above ? Please let me know if there is any other alternate method for getting the Caller Number.
Related
I'd like to be able to GET a value of a key and immediately know what type it is. I'm using
res, err := conn.Do("GET", key)
This returns an interface{} in res. Depending on the type, I'd like to call one of the helper functions like redigo.String(res) or redigo.Bool(res). I know I can do conn.Do("TYPE", key) to get the type separately, but how can I get the type just from the result of one GET request?
Wait, REDIS TYPE command does not provide you the details of value type it just tells you whether the key's value is a string, list, set, zset, hash, or stream.
So your application code or client code must identify what's it's equivalent for your programming language.
You can try to decode your data using the known key value types.
could I interact with functions in my deployed contract without using truffle-contract?
I just want to run and play with my functions to check how they work.
I used MyContract.at("0x...").MyFunctionName(parameters,{from:"x0..."});
but it doesn't work.
Any idea or suggestions
Thanks
It's hard to know what you mean by "it's doesn't work", but I guess is that you are not seeing any output when running MyContract.at("0x...").MyFunctionName(parameters,{from:"x0..."}); in the truffle console?
If yes, the reason is because invoking a method to an instance of a contract will give you a Future, and you must handle the result coming back from the call in an asynchronous way. For example, if the function return a value indicating that some computation has happened, you can print the returned value in the console by:
MyContract.at("0x...").MyFunctionName(parameters,{from:"x0..."}).then(console.log)
If you're writing unit tests (to be executed via truffle test), then you can handle the return value by doing this:
MyContract.at("0x...").MyFunctionName(parameters,{from:"x0..."}).then(function(returnedValue) {
// do something with the returnedValue, e.g.
// assert.equal(returnedValue, 3, "The returned value must be 3");
});
I'm getting an E_POINTER error from the ReadSample call, and as far as I can tell, none of the pointers are invalid. See snippet below (note, it's a C++/CLI app):
IMFSample* sample = NULL;
pin_ptr<IMFSample*> pinnedSample = &sample;
LONGLONG timeStamp;
HRESULT hr = mSourceReader->ReadSample(
(DWORD)MF_SOURCE_READER_FIRST_VIDEO_STREAM,
0,
NULL,
NULL,
&timeStamp,
pinnedSample
);
I suspect the problem lies in the construction of the mSourceReader (an IMFSourceReader instance, created from an IMFMediaSource). But, alas, I've no idea how to backtrack and find the source, as all the COM calls in the chain of commands that created mSourceReader returned S_OK.
Much thanks for any tips.
You don't need pin_ptr when taking the address of a local variable, since the garbage collector never moves local variables around anyway.
I'd guess that one of the other three parameters you're passing NULL to is non-optional, but I need to see what function you're calling to know for sure.
Did you create the IMFSourceReader in synchronous or asynchronous mode? The docs say:
This method can complete synchronously or asynchronously. If you provide a callback pointer when you create the source reader, the method is asynchronous. Otherwise, the method is synchronous.
I think this is your problem:
In synchronous mode:
The pdwStreamFlags and ppSample parameters cannot be NULL. Otherwise, the method returns E_POINTER.
You've passed NULL for pdwStreamFlags, which is not allowed.
Doc link: http://msdn.microsoft.com/en-us/library/dd374665.aspx
i'm talking to a COM object (Microsoft ADO Recordset object). In a certain case the recordset will return a failed (i.e. negative) HRESULT, with the message:
Item cannot be found in the collection
corresponding to the requested name or
ordinal
i know what this error message means, know why it happened, and i how to fix it. But i know these things because i read the message, which fortunately was in a language i understand.
Now i would like to handle this exception specially. The COM object threw an HRESULT of
0x800A0CC1
In an ideal world Microsoft would have documented what errors can be returned when i try to access:
records.Fields.Items( index )
with an invalid index. But they do not; they most they say is that an error can occur, i.e.:
If Item cannot find an object in the
collection corresponding to the Index
argument, an error occurs.
Given that the returned error code is not documented, is it correct to handle a specific return code of `0x800A0CC1' when i'm trying to trap the exception:
Item cannot be found in the collection
corresponding to the requested name or
ordinal
?
Since Microsoft didn't document the error code, they technically change it in the future.
They did document this error code, but it's hard to find:
ErrorValueEnum:
adErrItemNotFound 3265 -2146825023 0x800A0CC1 Item cannot be found in the collection that corresponds to the requested name or ordinal.
..so, as its' a documented error code, it is safe to test for it explicitly.
You'll have to decide whether or not it is worth the risk, but I believe that it is unlikely that Microsoft will change this error code. Checking for this particular error code is a pretty robust way to go.
Yes, it is fine. It is in fact a documented error code, although finding them is never easy. It is defined in the msdao15.idl Windows SDK file, adErrItemNotFound (error 3265)
When implementing a COM interface I always assign to the out parameters on success but should I do so also on error?
HRESULT CDemo::Div(/*[in]*/ LONG a, /*[in]*/LONG b, /*[out,retval]*/ LONG* pRet)
{
if (pRet == NULL)
return E_POINTER;
if (b == 0)
{
*pRet = 0; // is this redundant?
return E_INVALIDARG;
}
*pRet = a/b;
return S_OK;
}
At one time I was bit on the nose by not initializing an out parameter and assuming that if I initialized the variable it will remain that value if I don't change it inside the method. However I used this method from .NET and since the marshaller sees that this is an [out] parameter it discarded the initial value I placed on the call site and put in garbage after the function returned (it was fun debugging that, not).
Is assigning to an out param even on failure overcompensation or should I really do it?
Edit: Even though formally one should not access out params if the function failed I often see (and sometimes write) code like this (using the example from sharptooth's post):
ISmth *pSmth = NULL;
pObj->GetSmth(&pSmth); // HRES is ignored
if (pSmth) // Assumes that if GetSmth failed then pSmth is still NULL
{
pSmth->Foo();
pSmth->Release();
}
This works fine in un-marshalled code (same thread apartment) but if a marshaller is involved is it smart enough to only set the return value if the function succeeded?
While the other answers are not wrong, they miss a very important point -- a COM server that intends to return a failure HRESULT MUST set all [out] parameters to NULL. This is not merely a matter of good style, it is required by COM and not adhering to it can cause random crashes when there is marshaling involved.
That said, the *pRet = 0; in the original code is not redundant but correct and required.
The rule is that the calling party is not allowed to do anything with the out parameters value if the call fails. The server therefore should not provide valid values and should not pass ownership of any resources to the out parameters.
For example if you have
HRESULT GetSmth( [out] ISmth** );
method then it's expected that the server calls AddRef() on the ISmth** variable prior to returning. It must not call AddRef() if it is going to return a failure code because the client is not allowed to use the returned out parameter value and therefore will not call Release() and you'll get a memory leak.
I'm not sure I 100% agree with sharptooth. I certainly agree that for a failed COM call you cannot and must not assign any resource ownership to any out parameters. This includes memory allocation or AddRef'ing a COM object.
However I see nothing wrong (and in fact encourage) setting purely out parameters to empty values as long is does not transfer any resource ownership. For instance there is nothing technically illegal about your code setting pRet to point to 0. This transfers no resource ownership over to pRet and is merely a helper to some caller who did not properly check for success of the call.