|
But the area is not a regular one...
|
|
|
|
|
I create a stream socket and start listening immediately.
But when I use "netstat -a" command in the cmd window,the socket's port would not be shown in the list.The sample code only like below:
CSocket listenSocket;
if(listenSocket.Create(0,SOCK_STREAM)==TRUE)
{
SOCKET port=listenSocket.m_hSocket;
if(listenSocket.Listen(10)==FALSE)
cout<<"Listen Failed!"<
|
|
|
|
|
Is your listenSocket variable going out of scope?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
No,the socket is the member of the class
|
|
|
|
|
because you use listenSocket.Create(0,SOCK_STREAM) create listen socket, "0" means the server listen port is random number. this random number is also shown in the "netstat -a" list.
If you use listenSocket.Create(8000,SOCK_STREAM), the listen socket port will be fixed 8000. try "netstat -a" command you will find the listen port is 8000.
|
|
|
|
|
But,if I change to Create() and listen,the problem remain so.
Thanks
|
|
|
|
|
kcynic wrote: But,if I change to Create() and listen,the problem remain so.
Try something like Create(2500, SOCK_STREAM) and see if there's a socket listening on port 2500.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
But my real work is to create a listen socket and report the listening port to others then other client can to connect to the listening socket.
Thanks.
GOOD LUCK
|
|
|
|
|
I wrote a simple MFC multithreaded program using mutexes that was based on a sample MFC multithreaded program I found somewhere. I want to get time in the worker thread and then display it in the main dialog. I tried to pass the data between the threads using using global variables declared in a .h file included in both modules but I keep getting a link error, i.e., TimeThread.obj : error LNK2005: "long icount" (?icount@@3JA) already defined in clockDlg.obj. I am sure that there is a better way to pass data between threads than this way, anyway. I would appreciated some help as to the best way to pass data between threads.
Greg
|
|
|
|
|
Your linker problem is caused by the fact that the global variable "icount" is instantiated in every source file that includes the .h that declares it.
Try:
(In .h file)
<ref>
...
extern volatile long icount;
..
and in either of TimeThread.cpp or clockDlg.cpp (but not both)
<ref>
...
volatile long icount;
...
Without the "volatile" keyword, it doesn't matter how many mutexes you use, different threads may see different values depending on compiler optimisations.
It doesn't look to me as though you really need synchronisation with what you're doing here though, so why not just use RegisterWindowMessage(...) at startup to get a unique message ID & use PostMessage(...) from your worker thread to send the value to your dialog?
Regards,
T-Mac-Oz
|
|
|
|
|
Hi
I want to learn if i there is a list of defining .cpp files that mfc functions are defined.
I assume all the source code is in that directory C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\src\mfc.
For example in that code:
ON_COMMAND(ID_FILE_NEW, &CWinApp::OnFileNew)
I want to see CWinApp::OnFileNew's implementation.
I tried to put breakpoint in that line strat to debug by F11. But i can not find the source code.
Is there another solution or where am i wrong?
For an example; How can i find the CWinApp::OnFileNew's implementation file?
I am looking for your answers.
Thanks.
|
|
|
|
|
I spend a significant amount of time looking into the ATL/MFC source code.
Thankfully, the Find in Files dialog saves used paths!
Ctrl-Shift-F, select the path in the dropdown (project, solution, PSDK includes, CRT source,
ATL/MFC source are the ones I use all the time), type in the Find What edit box if it's not there
already, and go.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
You could try adding an ID_FILE_NEW handler to your application class which calls the base class implementation & setting a breakpoint on it.
i.e.
<ref>
void C{YourProject}App::OnFileNew()
{
CWinApp::OnFileNew(); // Set breakpoint here
}
Regards,
T-Mac-Oz
|
|
|
|
|
Thank you
Both of your solutions work well.
Good works...
|
|
|
|
|
Have you tried F12?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thanks for the handy tip-of-the-day!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
All of a sudden I cannot debug my applications. When I go to start, I get the above error.
I'm running VS2005SP1 with unmanged c++
I was able to run the other day, but today i cannot. This is code I'm trying to run (pretty simple)
--------------------------------------------------------
int main(int argc, char *argv[])
{
return 0;
}
---------------------------------------------------------------
Any thoughts
Tom
|
|
|
|
|
I don't know if it helps any, but a google search on "msdia80.dll"
yields several fixes for assorted problems related to that DLL.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I did look there first. However, none of them matched my situation close enough. I'm trying not to have to re-install vs2005 to fix problem.
|
|
|
|
|
I did a repair install of VS2005 (1.5 hours), and that fixed the problem.
It appears some setting somewhere was corrupted.
Tom
|
|
|
|
|
Bummer.
Thanks for the update though...good to know!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
i created a mfc dialog with worker thread, i used events for communication between main thread and worker thread, but i ran into some problems i can't figure it out.
UINT ThreadFunc(LPVOID pParam)
{
THREADPARMS*ptp=(THREADPARMS*)pParam;
CWnd*pWnd=ptp->pWnd;
CMy61xxMTDlg*pDlg=ptp->pDlg;
CEvent* pKillEvent=ptp->pKillEvent;
CEvent* pOutputEvent=ptp->pOutputEvent;//ptp->pOutputEvent=&m_OutputEvent
delete ptp;
while(::WaitForSingleObject(pOutputEvent->m_hObject,1000)==WAIT_OBJECT_0)
{
pDlg->m_OutputEvent.ResetEvent();
SpcGetParam(//output some data, an external library function)
pWnd->PostMessageW(WM_USER_GET_DATA,0,0);
// i need to access GUI object-sliders, and store the positions of sliders into array, so i post a message,the handler is OnGetData()
if(::WaitForSingleObject(pKillEvent->m_hObject,0)==WAIT_OBJECT_0)
{
pWnd->PostMessageW(WM_USER_THREAD_ABORTED);
return -1;
}
return 0;
}
LRESULT CMy61xxMTDlg::OnGetData(WPARAM wParam, LPARAM lParam){
CMy61xxMTDlg*pDlg=(CMy61xxMTDlg *) GetActiveWindow();
if(pDlg!=NULL)
pDlg->GetData(pbyData[nBufIdx], BUFSIZE);
return 0;
}
void CMy61xxMTDlg::GetData(ptr8 pbyData, int32 lBufsize)
{
int i;
for (i=0; i<BUFSIZE; i ++)
{
pbyData[i]=(int8)m_Slider_Data[i].GetPos();
}
m_OutputEvent.SetEvent();
}
i set the m_OutputEvent to be manual reset, the thread wait for the signal
<pre>while(::WaitForSingleObject(pOutputEvent->m_hObject,1000)==WAIT_OBJECT_0);<pre>
then i reset the signal
<pre>pDlg->m_OutputEvent.ResetEvent();<pre>
then i post a message to run the CMy61xxMTDlg::GetData() function, which stores the slider position in the data array, at the end of the function, i signal the outputevent
<pre>m_OutputEvent.SetEvent();<pre>
the idea is that i don't want the data to be output(SpcGetParam() function) if the data is not ready yet.
i found that the loop
<pre>while(::WaitForSingleObject(pOutputEvent->m_hObject,1000)==WAIT_OBJECT_0) <pre>
only run for once, and second time the it waits(actually the program freeze a little bit) for SEVERAL seconds and jumped to "return 0" statement, which means the m_OutputEvent is not signaled,, this is quite weird....
what's happening?
-- modified at 16:56 Friday 10th August, 2007
|
|
|
|
|
It's hard to tell what's happening - you left out some brackets somewhere in your posted code.
What's the purpose of the second thread? Just to do something every (approx) 1000ms?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
the a worker thread is to continuously output the position of sliders(mentioned in my previous posts),
the worker thread waits for the signal that data is ready for output, and waits for 1000ms, should take that long to complete the GetData() function, in my case, only 4 sliders.
|
|
|
|
|
As far as I can tell from what you've posted, the extra thread is unnecessary.
Any time you need to pick an arbitrary timeout that "should" be the right amount of time,
there's probably something flawed in the design.
I can't tell what's going on since there's missing code (at least one curly bracket is
missing from the thread proc).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|