|
His capability in finding a boss who believes that.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
How to use the c++ to resolved Load Balance problem just as Emule server, but I donot know how to get the emule server source.
Is there anyone can tell me how to make the Load Balance using C++?
|
|
|
|
|
I think you are trying to bite off waaaay more than you can chew by posing such a general question here - and I doubt people will know or care know emule enough to help you
yu-jian wrote: but I donot know how to get the emule server source.
see here http://www.emule-project.net/home/perl/general.cgi?l=1&rm=download[^]
there's a download link under 'Sourcecode v0.50a'
As for the rest of your issue, I suspect you would be better of studying c++ tcp/ip socket servers etc and then asking a more specific question
'g'
|
|
|
|
|
The problem:
I am using an accessor to INSERT into a table but this does return a value so I am using two commands to find out the ID of what was just inserted or at least that is the idea. I get DB_E_ERRORSINCOMMAND so if anyone can point me to where I am going wrong then you can save both my sanity and my hair...
This is the accessor class from the test application I have been troubleshooting against.
class CDBEvtRawInsert
{
public:
int f_Direction;
int f_HubID;
TCHAR f_RawEvent[1400];
LARGE_INTEGER f_RawEventID;
BEGIN_COLUMN_MAP(CDBEvtRawInsert)
COLUMN_ENTRY(1, f_RawEventID)
END_COLUMN_MAP()
BEGIN_PARAM_MAP(CDBEvtRawInsert)
SET_PARAM_TYPE(DBPARAMIO_INPUT)
COLUMN_ENTRY(1, f_Direction)
COLUMN_ENTRY(2, f_HubID)
COLUMN_ENTRY(3, f_RawEvent)
END_PARAM_MAP()
DEFINE_COMMAND_EX(CDBEvtRawInsert, L" \
INSERT INTO [RawEvent] ([TimeStamp],[Direction],[Hub],[RawEvent]) \
VALUES (GETDATE(),?,?,?);SELECT @@IDENTITY AS RawEventID")
};
This is an extract from the function
CString szValue = _T("test");
HRESULT hr = E_FAIL;
CCommand<CAccessor<CDBEvtRawInsert >,CRowset, CMultipleResults > rsEvtRawInsert;
wcscpy_s(rsEvtRawInsert.f_RawEvent, szValue.GetLength()*2, szValue);
rsEvtRawInsert.f_Direction = 1;
rsEvtRawInsert.f_HubID = 0;
hr = rsEvtRawInsert.Open(theApp.m_oDB.session);
if(S_OK == hr)
{
DBROWCOUNT out;
hr = rsEvtRawInsert.GetNextResult(&out);
I know the SQL is ok as I have tested it in SQL Management Studio on the same DB this code is using. Also if I make it a single recordset by removing the SELECT @@IDENTITY that works too.
If you have an alternative suggestion which would achieve the same result then I am all ears.
Thank you for reading this far.
Alan
|
|
|
|
|
hello guys...how do I get the names of the available devices in a TAPI app?? thnx
|
|
|
|
|
overloaded Name wrote: how do I get the names of the available devices in a TAPI app??
Wouldn't that be up to the app to provide you with that information?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I have an MFC MDI app in which I have included a docking control bar (Cristi Posea - CSizingControlBar - a resizable control bar) The controlbar has a dialog associated with it which, amongst other things, continuously grabs data from a PCI A/D card using a worker thread.
I have the following code,
first initialise the control bar and associated dialog:-
in MainFrm.h:-
class CMainFrame : public CMDIFrameWnd
{
DECLARE_DYNAMIC(CMainFrame)
public:
CMainFrame();
CMainControlBar m_MCB;
CDataControls m_GrabDataDialog;
.
.
.
}
then in MainFrm.cpp:-
int CMainFrame::EnableControlBar()
{
if (!m_MCB.Create(_T("Data Window"), this, 50))
{
TRACE0("Failed to create Data Window\n");
return -1;
}
m_MCB.SetBarStyle(m_MCB.GetBarStyle() | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC );
m_MCB.EnableDocking(CBRS_ALIGN_ANY);
#ifdef _SCB_REPLACE_MINIFRAME
m_pFloatingFrameClass = RUNTIME_CLASS(CSCBMiniDockFrameWnd);
#endif
DockControlBar(&m_MCB, AFX_IDW_DOCKBAR_LEFT);
if (!m_DataDialog.Create(IDD_MAINCONTROLS,&m_MCB))
{
TRACE0("Failed to create instant bar child\n");
return -1;
}
m_DataDialog.ShowWindow(SW_SHOW);
return 0;
}
Next, set up the thread:-
class CDataControls : public CDialog
{
public:
virtual ~CDataControls();
CDataControls(CWnd* pParent = NULL);
CGraphDraw m_Graph;
void DoDataDraw();
void DoDataGrab();
BOOL m_TerminateThreads;
CWinThread *pDataGrabThread;
double Sig[1024];
.
.
.
};
and:-
BOOL CDataControls::OnInitDialog()
{
CDialog::OnInitDialog();
m_Graph.Initialise();
pDataGrabThread = AfxBeginThread(DataGrabThread,this,THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED);
if(pDataGrabThread==NULL)
AfxMessageBox(L"Crap Thread");
pDataGrabThread->m_bAutoDelete=FALSE;
pDataGrabThread->ResumeThread();
return TRUE;
}
Now the actual thread:-
UINT DataGrabThread(LPVOID me)
{
CDataControls *self = (CDataControls *)me;
while(self->m_TerminateThreads!=0)
{
self->DoDataGrab();
Sleep(100);
}
return 0;
}
To close the thread when the controlbar closes I have:-
void CDataControls::OnClose()
{
m_TerminateThreads=FALSE;
WaitForSingleObject(pDataGrabThread->m_hThread,10000);
delete pDataGrabThread;
CDialog::OnClose();
}
Now I assumed that when I close the main application that it would take care of closing the controlbar sensibly via CDataControls::OnClose() but it doesn't - CDataControls::OnClose() isn't called at all, and I get 'MFC Application has encountered a problem...' error.
So now I have the following in the MainFrm.cpp:-
void CMainFrame::OnClose()
{
::SendMessage(m_ControlsDialog,WM_CLOSE,0,0);
CMDIFrameWnd::OnClose();
}
This now works perfectly! No errors, no memory leaks just apparently a nice clean finish. My question then, is this the correct way to go about this? I haven't had much experience with threads and although this seems to work well and I'm fairly happy with it I would like to know if it is the right way to do it and if not how else might I go about closing a thread running in a non-modal dialog when the main application is closed?
modified on Thursday, September 16, 2010 11:02 AM
|
|
|
|
|
i think its not a safe practice to access the m_TerminateThread variable in main UI thread from another thread, without using any locking mechanisms. Better to use an Event object, which is initially non-signalled, set it to signaled in CDataControls::OnClose(), and wait on thread handle. And in Thread function,
while(WAIT_OBJECT_0 != WaitForSingleObject(self->m_hEvent,0))
{
self->DoDataGrab();
Sleep(100);
}
or,
while(WAIT_OBJECT_0 != WaitForSingleObjectself->m_hEvent,100))
{
self->DoDataGrab();
}
|
|
|
|
|
Actually it is safe in this particular case. As the worker thread only ever reads the state of the variable, but he has to make sure it is reading the changes on each loop, i.e. it must be declared [code]mutable[/code] elase a compiler optimisation step may remove the follow on reads.
As long as multiple threads are not read/writing it should be fine.
If you vote me down, my score will only get lower
|
|
|
|
|
IMO it needs to be no wider than what can be handled atomically (hence 32-bit) AND declared volatile. Then it does not matter how many readers there are, as long as there is only one writer all is fine. With several writers, it most often needs a lock of some kind.
|
|
|
|
|
Cool_Dev wrote: Better to use an Event object,
Thanks, I tried this - it works ok but I still need the WaitForSingleObject() in the CDataControls::OnClose() (see below) Why is this?
void CDataControls::OnClose()
{
SetEvent(g_Event);
WaitForSingleObject(pDataGrabThread>m_hThread,1000);
CDialog::OnClose();
}
|
|
|
|
|
because you need to give the thread a chance to see the event and react to it.
|
|
|
|
|
Thanks! Sometimes it's good to know why, not just that it works
|
|
|
|
|
Caslen wrote: ::SendMessage(m_ControlsDialog,WM_CLOSE,0,0); //send a message to close the dialog and thread
You've not shown how m_ControlsDialog was declared. I assume it's safe to send a message to. If it's a modeless dialog, why not just call DestroyWindow() ?
Caslen wrote: while(self->m_TerminateThreads!=0)
This loop is suspect if m_TerminateThreads is not declared as volatile . Otherwise, it may or may not execute, or it may fail to end. Because m_TerminateThreads is not being changed within the loop, the compiler would likely optimize it out.
A better way of having the secondary thread end is to have the primary thread signal an event.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I already figured out the 'volatile' thing - I was more concerned about why I had to 'SendMessage' from CMainFrame::OnClose() - why wasn't CDataControls::OnClose() automatically closed when the App is closed?
|
|
|
|
|
Caslen wrote: ...why wasn't CDataControls::OnClose() automatically closed when the App is closed?
Because it was in the secondary thread, which was not terminating, perhaps? To test this, change your code to:
WaitForSingleObject(pDataGrabThread->m_hThread, INFINITE);
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Ok, that is probably it - but it's correct to use SendMessage() from CMainframe to close it though?
|
|
|
|
|
Caslen wrote: ...but it's correct to use SendMessage() from CMainframe to close it though?
Is the dialog modeless?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
|
Then just call DestroyWindow() .
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Note that you should declare m_TerminateThreads as mutable volatile as a compiler optimisation could break your code.
These lines
while(self->m_TerminateThreads!=0)
{
self->DoDataGrab();
could be interpreted as the compiler as:
if (self->m_TerminateThreads!=0)
{
for (;;)
{
self->DoDataGrab();
If you vote me down, my score will only get lower
|
|
|
|
|
Hi
I want to draw line on OnMouseMove function of a dialog class.I want to draw
the line in one color(fixed color not inverse color ),but it is showing in
different/inverse color. If I omit SetROP2 the line will get spread.
<code>
CDC* pDC = this->GetDC();
int nR2 = pDC->SetROP2( R2_NOTXORPEN );
pDC->MoveTo(m_StartPoint);
pDC->LineTo(m_Previouspoint);
m_Previouspoint = point;
pDC->MoveTo(m_StartPoint);
pDC->LineTo(point);
</code>
How to solve it?
thanks
|
|
|
|
|
Please find previous thread.
that will help you
|
|
|
|
|
Exactly how would finding a thread help in drawing a line?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Benjamin Bruno wrote: I want to draw
the line in one color(fixed color not inverse color )
Did you select such a Pen object to your CDC before calling LineTo() function?
|
|
|
|