|
And the TerminateThread() seems dangerous because I create a buf in the socket thread.
|
|
|
|
|
googoo wrote:
And the TerminateThread() seems dangerous because I create a buf in the socket thread.
If you want to kill a non-responding thread, there is little else you can do. I suggest you redesign the thread so that this sort of situation does not arise.
Nish
Check out last week's Code Project posting stats presentation from :-
http://www.busterboy.org/codeproject/
Feel free to make your comments.
|
|
|
|
|
Not a non-responding thread,but an thread with a socket transferring loop:
create--listen--accept--read package--send package---
| |
-----------------------------------|
It seems difficult for me to avoid the WSAWaitForMultipleEvents()?
|
|
|
|
|
googoo wrote:
It seems difficult for me to avoid the WSAWaitForMultipleEvents()?
Then I think you should avoid using WSA_INFINITE as the time out interval. Use 5000 or something and then keep looping. Thus every 5 seconds you get a shot at closing the thread by posting a message to it.
Nish
Check out last week's Code Project posting stats presentation from :-
http://www.busterboy.org/codeproject/
Feel free to make your comments.
|
|
|
|
|
No, I still have a problem.Because I am writing a DLL,and the DLL users will load and release it dynamically in shore intervals repeatly in their programs，it is hard for me to wait for 5 seconds every time.But a short timeout may cause other problems because of the busy lan.
Maybe any good suggestions on my thread design?
|
|
|
|
|
Use WaitForMultipleObjects instead. I replaced the following code (listing1) in a loop as you describe with the new code in listing 2 with no problems.
//listing 1:
while(1) {
if (WaitForSingleObject(pThis->m_hKillEvent, 100) == WAIT_OBJECT_0)
break;
if (!pThis->Connect())
{
Sleep(1000);
continue;
}
DWORD dwRet;
dwRet = WSAWaitForMultipleEvents(1,
&pThis->m_dataSocket.m_hEvent,
FALSE,
100,
FALSE);
if (dwRet == WSA_WAIT_TIMEOUT)
continue;
// respond to the network event
}
//Listing 2:
while(1) {
HANDLE hEvents[2] = {pThis->m_hKillEvent,pThis->m_dataSocket.m_hEvent};
DWORD dwRet;
dwRet = ::WaitForMultipleObjects(2,hEvents,FALSE,INFINITE);
if (dwRet == WAIT_OBJECT_0)
break;
if ( dwRet == WSA_WAIT_TIMEOUT ) {
continue;
}
// respond to the network event
}
|
|
|
|
|
My program need some functions of Explorer,then i wonder to know how can i
use the Explorer commands such as hotkeys,context menus and so on in my
Listview and Shell tree?
i am coming quietly just as i am leaving quietly.
|
|
|
|
|
First you need create a new class from CListCtrl,and then override the WM_CONTEXTMENU and other mouse message to handle your own functions.
Regards
http://www.ucancode.net/ (Xtreme Diagram++ MFC Extension library home page)
|
|
|
|
|
I have an abstract class like:
class CMyAbstract
{
public:
virtual void Func(char *Param) = 0;
};
Then I have a class that uses it as its base class.
class CMyCLass : public CMyAbstract
{
public:
virtual void Func(char *Param);
};
In an implementation file
CMyAbstract *pClass = new CMyClass;
pClass->Func("yada");
This crashes as long as its a virtual function. Why is this. Don't worry about omitted thing like constructors.
Steve
Not all who wander are lost...
|
|
|
|
|
Does it crash in the constructor or destructor?
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
No it does not.
Steve
Not all who wander are lost...
|
|
|
|
|
Hope you have implemented the function?
Else being a virtual function it'll try and call the base function which points to NULL.
Nish
Check out last week's Code Project posting stats presentation from :-
http://www.busterboy.org/codeproject/
Feel free to make your comments.
|
|
|
|
|
yes the function is implemented.
Steve
Not all who wander are lost...
|
|
|
|
|
Steve Severance wrote:
CMyAbstract *pClass = new CMyClass;
Shouldn't it be:
CMyClass* pClass = new CMyClass;
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
Did you Copy/Paste the example code from your project?
If so, check the class names:
In the class definition CMyCLass is written with a uppercase L, the implementation fragment has CMyClass with a lowercase l.
|
|
|
|
|
The error is runtime(Access Violation) not compile time.
Here is actual source.
Header
class CInputCommandMap
{
public:
CInputCommandMap();
~CInputCommandMap();
void LoadCommandMap(char *file);
virtual void ProcessInput(char *keys, DIMOUSESTATE2 *mouse) = 0;
CInputCommand m_keyA;
CInputCommand m_keyB;
CInputCommand m_keyC;
More Keys...
};
class CDefaultKeyMap : public CInputCommandMap
{
public:
CDefaultKeyMap(){}
~CDefaultKeyMap(){}
void ProcessInput(char *keys, DIMOUSESTATE2 *mouse);
};
ProcessInput is overridden and contains the actual implentation.
LoadCommandMap is
void LoadCommandMap(CInputCommandMap *map){m_pCommandMap = map;}
I use it like this.
pDefaultCommandMap = new CDefaultKeyMap;
pDefaultCommandMap->LoadCommandMap("default.key");
pInput->LoadCommandMap(pDefaultCommandMap);
Code...In an update function that is in the main input class
if(m_pCommandMap)
m_pCommandMap->ProcessInput((char *)m_Keys,&m_MouseState);
Thanks once again for all you guys help.
Steve
Not all who wander are lost...
|
|
|
|
|
You've got the right idea, but you've got bugs in both your interfaces in your imnplementations.
The implementation bug is what crashes it. Sorry, can't help without _full_ definition.
The interface bug is that a class that is intended to be inherited from, especially if it contains data (!), should (almost) always have a virtual destructor.
To give you a hint: Your code is probably overwriting some memory it doesn't own.
|
|
|
|
|
Does anyone know if it's possible to have layered child windows? I looked in documentation for WS_EX_LAYERED, it says only top-level windows can have that attribute.
Anyone have any ideas?
Thanks,
Gene
----------------------------------------
----I said my name wasn't important
---------------------------SlartiBartFast
|
|
|
|
|
Why would you want to use WS_EX_LAYERED? It would exclude like 90% (or more) of the Win32 platforms.
It might be cool, but it's unsupported on far more Win32 platforms (both in count of platforms and installations) than it's supported on.
|
|
|
|
|
Mike Nordell wrote:
Why would you want to use WS_EX_LAYERED? It would exclude like 90% (or more) of the Win32 platforms.
Well, that depends. If you are talking about all machines world-wide where some version of Windows is installed, yeah, that's probably correct. However, that is not everyone's market. If you are targeting a specific group of users (such as a corporation where all software is standardized) then this decision is much more relevant.
And although this is feature seems generally to be used for unnecessary gimicks, there are other uses for it; i recall one person posting here a while back who was designing a HUD that needed to be displayed over another piece of software.
--------
all the modern things
have always existed
they've just been waiting
to come out
and multiply
and take over Björk, The Modern Things
|
|
|
|
|
Eugene Polonsky wrote:
I looked in documentation for WS_EX_LAYERED, it says only top-level windows can have that attribute.
This is true. It is not really a problem however, since you generally have much more control over how child windows are drawn. GDI+ can help if you need routines for doing alpha blending.
That said, one hack i have used in the past is to create a top-level window, but manually position and move it like a child window. Obviously this is generally useless, but in a few specific situations i could see it.
--------
all the modern things
have always existed
they've just been waiting
to come out
and multiply
and take over Björk, The Modern Things
|
|
|
|
|
I'm making a dialog based MFC program and I want to use two dialogs... but I would like to close the first one before the second opens.
How should I do? 
|
|
|
|
|
In your program's InitInstance(), after the first dialog has closed, create and show a new dialog.
--------
all the modern things
have always existed
they've just been waiting
to come out
and multiply
and take over Björk, The Modern Things
|
|
|
|
|
Shog9 wrote:
In your program's InitInstance(), after the first dialog has closed, create and show a new dialog.
This may have problems in dialog based apps. Because by defauly the main window is the first dialog. When you close it, it gets destroyed and MFC sorta takes this to mean that the main app has closed.
Nish
Check out last week's Code Project posting stats presentation from :-
http://www.busterboy.org/codeproject/
Feel free to make your comments.
|
|
|
|
|
 Yes, this seems to be true... Had to do a test proggy to figure out why.
Another one of those cases where MFC looks far more simple than it is... 
--------
all the modern things
have always existed
they've just been waiting
to come out
and multiply
and take over Björk, The Modern Things
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
