|
It works Lord Salsbery!!
Norman Fung
|
|
|
|
|
Project-->Link：winmm.lib
#include "mmsystem.h"
BOOL GetRecordradio()
{
UINT m_uMxId2;
//HWND m_hWnd;//回调句柄
HMIXER m_hmx2;
MIXERCAPS mxcaps;
//返回系统中混音器数量(如:一块普通声卡提供一个混音器设备)
int devnum=mixerGetNumDevs();
int i=0;
for(i;i<devnum;i++)
{
m_umxid2=i;
if (mmsyserr_noerror="" !="
mixerOpen(&m_hmx2," m_umxid2,null,="" 0,="" callback_window))
="" 使用dwcallback参数
return="" -1;
="" 得到相应设备标识号
="" mixergetid((hmixerobj)m_hmx2,&m_umxid,mixer_objectf_hmixer);
="" 确定各混音器设备的能力:保存在mxcaps结构中（wmid,wpid,szname,cdestinations）
if="" false;
="" 检索指定音频线路的信息,保存在mixerline结构中，
="" 其中一些成员根据不同情况要初始化
mixerline="" mxl;
mxl.cbstruct="sizeof(MIXERLINE);" 必须赋值
="" 可以通过多种条件来检索：
="" 方式一：根据目标单元编号
="" mxl.dwdestination="0;等同用mxl.dwComponentType=MIXERLINE_COMPONENTTYPE_DST_SPEAKERS
//mxl.dwDestination=1;等同用mxl.dwComponentType=MIXERLINE_COMPONENTTYPE_DST_WAVEIN
//对应flag:" mixer_getlineinfof_destination
="" =="" mixerline_componenttype_dst_wavein;
="" 对应flag:="" mixer_getlineinfof_componenttype
if="" (::mixergetlineinfo((hmixerobj)m_hmx2,
&mxl,
mixer_objectf_hmixer="" |
mixer_getlineinfof_componenttype)
!="MMSYSERR_NOERROR)" return="" 查询="" 录音控制面版中="" 麦克风线路的编号=""
mixerline="" mxl_v;
uint="" cconnections="(UINT)mxl.cConnections;
UINT" dwsource_v="0;
do
{
mxl_v.cbStruct" sizeof(mxl_v);
mxl_v.dwdestination="mxl.dwDestination;
mxl_v.dwSource" dwsource_v;
dwsource_v++;
if=""
&mxl_v,=""
mixer_getlineinfof_source))
return="" false;
}="" while="" ((dwsource_v="" <="" cconnections)="" &&=""
(mxl_v.dwcomponenttype=""> cConnections) ||
(mxl_v.dwComponentType !=MIXERLINE_COMPONENTTYPE_SRC_MICROPHONE))
return FALSE;
dwSource_v--;//得到编号
//下面这段文字说明在本例中已经没有什么实际意义，是以前调试时留下的，也不删除了，
//可以知道如何控制主音（Volume）线路的禁音状态：
//－－可以利用得到的主音（Volume）线路的mxl.dwLineID,
//来查询Volume的禁音状态
//要想查询（或设置）可以混音到DST_SPEAKERS主音（Volume）中的
//相关音源线路（如：wave、micphone等）的禁音状态，还必须再使用
//一次 mixerGetLineInfo 进一步指定其dwLineID
//注意：不要简单的直接修改上面的：
//mxl.dwComponentType = 类型;
//虽然可能有时不会报错，但这成了我们程序中的隐患，
//因为有的线路在DST_SPEAKERS和DST_WAVEIN中均有，如：
//MIXERLINE_COMPONENTTYPE_SRC_COMPACTDISC
//下面实现了"强制"单选麦克风线路为录音源输入
MIXERCONTROL mxc;
MIXERLINECONTROLS mxlc;
mxlc.cbStruct = sizeof(MIXERLINECONTROLS);
mxlc.dwLineID = mxl.dwLineID;
mxlc.dwControlType = MIXERCONTROL_CONTROLTYPE_MUX;
//MIXERCONTROL_CONTROLTYPE_MUTE;
mxlc.cControls = 1;
mxlc.cbmxctrl = sizeof(MIXERCONTROL);
mxlc.pamxctrl = &mxc; //为了得到相应的mxc.dwControlID，
//锁定mxlc.dwLineID和mxlc.dwControlType指定的线路控制
//目前将对录音目标单元的录音音源线路做单选（多路复用）
if (::mixerGetLineControls((HMIXEROBJ)m_hmx2,
&mxlc,
MIXER_OBJECTF_HMIXER |
MIXER_GETLINECONTROLSF_ONEBYTYPE)
!= MMSYSERR_NOERROR) return -1;
//根据mxc.dwControlID检索线路，
MIXERCONTROLDETAILS_BOOLEAN mxcdMute[8];
MIXERCONTROLDETAILS mxcd;
mxcd.cbStruct = sizeof(MIXERCONTROLDETAILS);
mxcd.dwControlID = mxc.dwControlID;//在上面的&mxc得到
mxcd.cChannels = 1;
mxcd.cMultipleItems =mxc.cMultipleItems;//多路因子数目
mxcd.cbDetails = sizeof(*mxcdMute);
mxcd.paDetails =&mxcdMute;//存放检索结果
if (::mixerGetControlDetails((HMIXEROBJ)m_hmx2,
&mxcd,
MIXER_OBJECTF_HMIXER |
MIXER_GETCONTROLDETAILSF_VALUE)
!= MMSYSERR_NOERROR) return -1;
//做相应单选改变
int j;
for(j=0;j<(int)mxc.cMultipleItems;j++)
mxcdMute[j].fValue=false;
mxcdMute[dwSource_v].fValue=true;
//重新设置dwControlID锁定的线路控制
if (::mixerSetControlDetails((HMIXEROBJ)m_hmx2,
&mxcd,
MIXER_OBJECTF_HMIXER |
MIXER_GETCONTROLDETAILSF_VALUE)
!= MMSYSERR_NOERROR) return -1;
}//for(i;i
|
|
|
|
|
I need to convert a COLORREF value to 3 COLOR16 (hex) values. I'm trying to fill out this structure:
typedef struct _TRIVERTEX {
LONG x;
Long y;
COLOR16 Red;
COLOR16 Green;
COLOR16 Blue;
COLOR16 Alpha;
}TRIVERTEX, *PTRIVERTEX;
GetRValue, GetGValue, and GetBValue will give me color intensity integers, but those need to be converted to hex values. So to be more precise I need to convert from an integer to a COLOR16 hex value. Anyone got ideas?
|
|
|
|
|
From the docs:The color information of each channel is specified as a value from 0x0000 to 0xff00. So you can take the one-byte value from the COLORREF and multiply by 256.
|
|
|
|
|
How do I take the 1 byte value from it?
|
|
|
|
|
It's the value returned by GetXValue:
COLORREF cr = RGB(64,128,196);
BYTE red = GetRValue(cr);
COLOR16 red16 = red * 256;
|
|
|
|
|
|
COLORREF colorref = RGB(0x01,0x02,0x03);
TRIVERTEX TriVertex;
TriVertex.Red = (COLOR16)GetRValue(colorref) << 8;
TriVertex.Green = (COLOR16)GetGValue(colorref) << 8;
TriVertex.Blue = (COLOR16)GetBValue(colorref) << 8;
|
|
|
|
|
Hello all.
I have a code something like this:
<br />
void CMyDialog::OnLButtonUp(UINT nFlags, CPoint pt)<br />
{<br />
AfxMessageBox(_T("Trace 1"));<br />
EndDialog(IDOK);<br />
AfxMessageBox(_T("Trace 2"));<br />
}<br />
As far as I know, the dialog must end after a call to EndDialog (it is a modal dialog by the way). Thus, it is showing the second message box. Why is this? 
Any thoughts will be really appreciated.
Thanks in advance. Regards,
Fernando.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine.
Personal Site
|
|
|
|
|
Even though you've ended processing for the dialog the function still returns and execution
continues on the next line. The return code (IDOK) will eventually be returned from the DoModal()
call that started the dialog.
Also, the docs state:
"EndDialog does not close the dialog box immediately. Instead, it sets a flag that directs the
dialog box to close as soon as the current message handler returns."
|
|
|
|
|
Oh, I see. Then what can I do to end the dialog immediately?
Thanks for your reply.
Regards,
Fernando.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine.
Personal Site
|
|
|
|
|
That's the way you should end the dialog. The same thing that happens when you click a
default OK or Cancel button or the ESC key.
The dialog should end quickly and return from the original DoModal() call.
You probably shouldn't do anything else except return after calling EndDialog() since message
handling for the window is essentially done.
What is happening that makes you feel it's not ending fast enough?
Mark
|
|
|
|
|
Thanks again for the reply.
The problem is the following. I have a function that is being called from OnLButtonUp. Under determined circumstances, must end the dialog. However, the code is being executed twice... that is, after the EndDialog for some weird reason it is executing the same code again... When it is executed again, it throws me an exception because the dialog has already been destroyed (!).
I think that such problem is caused by remaining messages in the queue or something. I can't figure out what is happening really, and the spy++ is not working.
Tahnks again. Regards,
Fernando.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine.
Personal Site
|
|
|
|
|
That's what I mean...it's not a good idea to do anything after you've called EndDialog().
Even if it's from a nested function - that function shouldn't do anything except return.
Can you return a value from that function indicating that the dialog has been ended? Check
that returned value and if it indicates the dialog has ended then just return.
Mark
|
|
|
|
|
|
Put a return statement after the EndDialog().
|
|
|
|
|
Yep, actually there is a return. That is why this issue is freaking me out... In fact, while I was spy++ing the app, I realized that even a WM_CLOSE and a WM_DESTROY message was sent to the application, and then it ran the code again 
Thanks for your reply.
Regards,
Fernando.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine.
Personal Site
|
|
|
|
|
|
Are you looking for AfxAbort()?
Nobody can give you wiser advice than yourself. - Cicero
ப்ரம்மா
|
|
|
|
|
Can you show code, how you are using this dialog ?
|
|
|
|
|
|
Hello. First of all, I'd like to thank you all for the help provided. Indeed, I am so happy now, and after your help and like 50 cigarrettes, I was able to find the bug. Here's the issue.
It was happening something like Mark and Michael told me, about not running a single line of code after the EndDialog. That is, the code must have a return after the EndDialog call. However, in my code there was an EndDialog and a return. Yet in other part of the code, this dialog created another dialog and this new child window, when it ends the dialog, does not have a return and indeed there was more code executing after the call of EndDialog. So a simple return there ended the problem. Something like the following:
<br />
<br />
void CAnotherDialog::EndDialog()<br />
{<br />
DoSomething();<br />
if (m_bSomething)<br />
EndDialog(IDCANCEL);<br />
<br />
DoMoreStuff();<br />
}<br />
<br />
void CMyDialog::DoSomething()<br />
{<br />
CAnotherDialog dlg;<br />
dlg.DoModal();<br />
<br />
if (bSomeFlag)<br />
{<br />
EndDialog(IDCANCEL)<br />
return;<br />
}<br />
<br />
DoMoreStuff();<br />
}<br />
So I just changed it into:
<br />
<br />
void CAnotherDialog::EndDialog()<br />
{<br />
DoSomething();<br />
if (m_bSomething)<br />
{<br />
EndDialog(IDCANCEL);<br />
return;<br />
}<br />
<br />
DoMoreStuff();<br />
}<br />
<br />
void CMyDialog::DoSomething()<br />
{<br />
CAnotherDialog dlg;<br />
dlg.DoModal();<br />
<br />
if (bSomeFlag)<br />
{<br />
EndDialog(IDCANCEL)<br />
return;<br />
}<br />
<br />
DoMoreStuff();<br />
}<br />
Thank you guys, you really saved my nervous system. 
One last thing: should I post this issue in the subtle bugs section, or it was only pure lack of knowledge (stupidity, that is) from my part?
Thanks again.
Regards,
Fernando.
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine.
Personal Site
|
|
|
|
|
Hi,
How can I write an instant messenger (IM) that would scale well with increased numbers of users? Any ideas about implementing the server side and handling a large number of connections? I need a place where I can start from.
Do you have any information about current IMs e.g Yahoo, MSN, .. etc? Specifically about their server side implementations and how they can handle those large numbers of users? Any help is appreciated.
Regards,
Wal
|
|
|
|
|
Waleed wrote: How can I write an instant messenger (IM) that would scale well with increased numbers of users?
This is a trick question in a way, and hopefully I can point you in the direction of a decent solution. The only solution that will scale well is, one in which demand indirectly creates supply, this is most commonly seen in Peer to Peer networking. The more users who join the network imply the more capacity the network has, and all P2P is not evil incidently.
Using the traditional client server approach is dangerous, it may never be able to fully cope with spikes in demand. So I suggest you take a look at Pastry, it is a Microsoft P2P client written in Java funnily enough. Another solution would be to look at Ekiga, the most popular Linux IM solution with the full source code available.
|
|
|
|
|
Thanks a lot, I'm going to look for what you pointed out in your message.
Wal
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
