|
Thanks for acknowledging
|
|
|
|
|
Hello,
I´m developing a softphone and using asterisk 1.6 as server.
By sending audio from a wavefile in 20ms blocks over RTP, on the receiver
the stream will be played out too fast. If I´m doing a pause of 20ms before sending
each packet, it is played out well.
Is this problem on the timestamp?
I´m initializing the timestamp with 0 and then incrementing it with 160 like RFC 3550 said.
Before sending I´m converting the value with htonl() To Network Byte Order.
The softphone run on Windows.
What could I do false?
Best Regards,
Crazy
|
|
|
|
|
Could somebody know how to hide MFC dialog to tray icon in the bottomright Toolbar?
I can open the MFC dialog by click the tray icon or select some menu items I set.
|
|
|
|
|
They are two different things.
You can create a tray icon using Shell_NotifyIcon .
And you hide the dialog using ShowWindow(SW_HIDE) .
When the user clicks on the tray icon, you will get a notification message that you specified in the uCallbackMessage parameter of the NOTIFYICONDATA structure.
There you can create a popup menu using CreatePopupMenu and TrackPopupMenu .
|
|
|
|
|
Hi...
I have createed a dll. Name is
CMyClass
my main calss is
void CTestDLLDlg::OnOK()
{
CMyClass objMyClass;
UpdateData(true);
CString str = "Some text";
CString strResult = objMyClass.SayHello(str);
}
I have the foolowing function in MyClass dll
CMyClass::SayHello(CString strName)<br />
{<br />
Hwnd dlg;<br />
SetDlgItemTextW(dlg,IDC_EDIT1,strName);<br />
return "Hello " + strName;<br />
}
Dll class window id is IDD_DIALOG1 and class name is CMyClass. Here i have to set strName in IDC_EDIT1. How to do this?
Any help will be appriciated...
Thanks...G.Paulraj
|
|
|
|
|
Paulraj G wrote: Hwnd dlg;
SetDlgItemTextW(dlg,IDC_EDIT1,strName);
Here you are calling SetDlgItemTextW() on an invalid handle. May be you can pass a valid dialog handle to the function SayHello().
|
|
|
|
|
Hi All,
follow the following code please:
int i = 2;
i = ++i + (++i)
cout<<i;
logically the="" code="" should="" print="" value="" '7'="" but="" i="" am="" getting="" '8'="" as="" output.
why="" is="" it="" so?
thanks="" in="" advance
regards
pankaj<div="" class="signature">French is the language of love, for everything else there is c++ ...(anonymous)
|
|
|
|
|
You can disassemble and see how exactly the expression is evaluated.
When disassembled you can see something like follows which I think is self explanatory.
mov eax,dword ptr [i]
add eax,1
mov dword ptr [i],eax
mov ecx,dword ptr [i]
add ecx,1
mov dword ptr [i],ecx
mov edx,dword ptr [i]
add edx,dword ptr [i]
mov dword ptr [i],edx
|
|
|
|
|
would u please let me know how to disassemble ? French is the language of love, for everything else there is c++ ...(anonymous)
|
|
|
|
|
I assume you are using Visual Studio. Put a break point on the code. Hit F5. When the break poin is reached, right click on the source to see a context menu having an item 'Go to Disassembly'.
|
|
|
|
|
I am in college and we are using Turbo C++.
How can i perform the same here??
Thanks & Regards
PankajFrench is the language of love, for everything else there is c++ ...(anonymous)
|
|
|
|
|
I am sorry, I have no idea about how to do this in Turbo C. But you can take a look at the assembly code in my previous post to understand why 8 is displayed.
|
|
|
|
|
Pankaj D.Dubey wrote: int i = 2;
i = ++i + (++i)
cout<<i;
logically the="" code="" should="" print="" value="" '7'="" but="" i="" am="" getting="" '8'="" as="" output.
why="" is="" it="" so?
<="" blockquote="">
Actually, 8 is just as a correct answer as 7. To research this, search for the term "sequence points".
In ++i + (++i) for each ++i, i is first incremented, then the value is used. Also, the add will be done last. This does not fully define the order of evaluation of everything - and the implementation is free to choose the rest of the order.
So it could do things in the order you were thinking of. Another equally valid order is:
do the first increment ( i gets 3),
do the second increment ( i gets 4 ),
add current i to current i (8)
The bottom line is that you shouldn't write expressions where parts of the expression have side effects that could alter the value of other parts of the expression.Please do not read this signature.
|
|
|
|
|
If i take another variable say 'Y' and perform the evaluation in that like
Y = ++i + (++i);
cout<<y;
it will="" give="" '7'.="" now="" whats="" the="" reason="" behind="" this="" concept.<div="" class="signature">French is the language of love, for everything else there is c++ ...(anonymous)
|
|
|
|
|
Exact same reason. You are using exactly the same expression on the right side of the equals sign. Since you didn't change anything relevant, nothing changed.
Edit: Yes, you did change the expression on the left side of the equals sign and got a different answer, but the issue is unchanged.Please do not read this signature.
modified on Wednesday, February 24, 2010 11:05 AM
|
|
|
|
|
Exactly
thanks mate, thanks a ton
Thanks and Regards
PankajFrench is the language of love, for everything else there is c++ ...(anonymous)
|
|
|
|
|
It is safer not to use such code because you will get different results in different compilers.
IIRC I got different results in VC 6.0 when compiled in Windows application and console application.
|
|
|
|
|
Definitely it is not safe. Even the same compiler in different situations in the source code could produce different results, as the OP seems to have experienced. The relative order of evaluation including application of side affects isn't fully specified by the standard, so the compiler gets to pick what's convenient - and can pick differently in different places. Please do not read this signature.
|
|
|
|
|
The standard DOES have something to say on this. In the Expressions section introduction, it specifically states <quote>Except when noted, the order of evaluation of operands of individual operators is undefined. In particular, if a value is modified twice in an expression, the result of the expression is undefined except when an ordering is guaranteed by the operators involved. For example,
i = v[i++];
i = 7,i++,i++;
</quote>
[Stroustrup, 2nd ed, p492]
So it's not that the standard fails to fully specify, it specifies that the result is undefined.
|
|
|
|
|
It seems it is easy to fall into this trap especially when somebody is new to C++.
|
|
|
|
|
people seem to fall into traps like this -- when they try to be cool.
there's no good reason to combine several distinct operations into single statement.
one thing I've learned in my years is that 'cool is costly' -- you could spend many many hours trying to debug that mistake.
write it simply and clearly (and readable) -- the compiler will optimize it for you.
-p
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<a href="http://www.soonr.com">SoonR Inc -- PC Power delivered to your phone</a>
|
|
|
|
|
Clarification/correction accepted. When I wrote "relative order ... isn't fully specified", I meant "is not fully dictated" (hence, as you say, is officially undefined) rather than "is not talked about". Please do not read this signature.
|
|
|
|
|
I have this function..
void MyFunction(BSTR* param, int nArraySize);
and I'm supposed to pass an array of string ("String1", "String2", "String3") as param. How can I do this?
|
|
|
|
|
BSTR str[10];
for (int i = 0; i < 10; ++i)
str[i] = ::SysAllocString(_T("String"));
MyFunction(str, 10);
|
|
|
|
|
I use GDI+ in my project under windows Vista/7 without any problems.
But when i try to compile the code or run the code under windows XP, the program crashes/ the compiler throw an exception.
I found that pBmp1 is NULL under the windows XP:
HBITMAP hbmp1 = ::LoadBitmap(AfxGetInstanceHandle(), MAKEINTRESOURCE(IDB_BITMAP1));
ASSERT(hbmp1!=NULL);
Bitmap* pBmp1 = Bitmap::FromHBITMAP(hbmp1,NULL);
ASSERT(pBmp1->GetLastStatus() == Ok);
How can i Correct it?
Best,
MJM
|
|
|
|