|
The thread function has an LPVOID parameter that you can use to pass the object variables belong in. I usually make the thead proc a simple stub to the "real" function that does the job:
static DWORD WINAPI CMyClass:ThreadProcStub(LPVOID arg)
{
CMyCLass * obj=static_cast<CMyCLass *>(arg);
obj->Thread();
return 0;
}
void CMyClass::Thread()
{
}got the idea?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
a million thanks for your help, i got it working
Kuniva
--------------------------------------------
God gave man a penis and a brain but not enough blood to make both of 'em work at the same time.
|
|
|
|
|
Glad to have been helpful. See you around.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
sorry i didn't look close enough, CreateThread is also win32 
Kuniva
--------------------------------------------
God gave man a penis and a brain but not enough blood to make both of 'em work at the same time.
|
|
|
|
|
If you need to call WSAAsyncSelect, your window handle cannot be a fake!
WSAAsyncSelect won't send any event until something was detected. Since this
is Microsoft extension to socket library. You need to provide a correct
window handle or else you must do it yourself. For example, you could have
a thread sending this message (WM_SOCKET /w events) to your application.
Hope that help!
"Dirty hands lead to important discovery..." - Thomas Edisson
|
|
|
|
|
Your best bet is probably to create another thread that just runs, because the thread with your fake message loop will block on the call to GetMessage until a message is sent to that thread. This may prevent any code that you would want to be executed from happening.
Could you give a little more detail in why you want to have this message pump with out any windows. Is it to send messages across threads or something?
If I have more details I may be able to suggest a better solution.
|
|
|
|
|
... doesn't mean anything, but it made you look...
Hello!
I'd like a guru to take a look at this:
if I use a pragma pack on a STRUCT like this:
#pragma pack(1) // aligment of 1 byte(was 4)
struct CODE
{
unsigned char cType;
union
{
DWORD iValue;
FARPROC lpAdress;
unsigned char * lpString;
};
};
#pragma pack(4) // aligment of 4 bytes
I will save out the 3 bytes never used with data alignment of 4 bytes, but does this slow down handling the struct? ( or "Where's the catch?" or "Why isn't everything aligned 1 byte?")
Thank You !
Georg Haan (.NL)
|
|
|
|
|
Georg Haan wrote:
but does this slow down handling the struct? ( or "Where's the catch?" or "Why isn't everything aligned 1 byte?")
Yes, in a big way. I believe most current processor instructions expect 4, 8, 16 or 64 byte alignment. In a world where memory is cheap (or at least cheaper than speed), you should use the default alignment the compiler selects for the appropriate build target.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Don't ask me why, but with my code, I'm somethimes searching for a CODE with ctype = 6 and iValue = 4, with bytealignment = 1 I can do a
while((*(short*) &Ops[p02++].cType)!=(short)((0x100*OPSEP)+4))
where Ops is a CODE array, p02 a counter and OPSEP =
#define OPSEP 6
Hmz, Maybe if I add another bogus short and char in front of the ctype...
Comments?
Thanks.
Georg Haan (.NL)
|
|
|
|
|
Relying on byte alignment is dangerous and makes for hard to maintain code.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
|
Every time I try to start a debug session the entire .Net visual studio application locks up and I have to restart it. Even if I create a new MFC application and add nothing to it, the app hangs.
I can run it without debugging just fine, but when I try to "start", no way.
Any thoughts?
"Thank you, thank you very much" Elvis.
|
|
|
|
|
I'm trying to create a view class derived from CListView. It is created as the main view object of an MDI application, by the appwizard on project creation.
OnInitialUpdate() is where you place the code that initializes a view. My problem is that I can't seem to get the CListView to show the column headers. Can anyone see what I'm doing wrong? (Here's my OnInitialUpdate
void CMailBoxProtoView::OnInitialUpdate()
{
CListView::OnInitialUpdate();
int x;
// Get a reference to the list view's control
CListCtrl& listCtrl = this->GetListCtrl();
// Add the columns
listCtrl.InsertColumn(0, _T("From"), LVCFMT_LEFT);
listCtrl.InsertColumn(1, _T("Received"), LVCFMT_LEFT);
listCtrl.InsertColumn(2, _T("Subject"), LVCFMT_LEFT);
listCtrl.InsertColumn(3, _T("Size"), LVCFMT_LEFT);
// Set the column sizes
for(x = 0; x < 4; x++)
listCtrl.SetColumnWidth(x, LVSCW_AUTOSIZE_USEHEADER);
// Set the style of the list control
listCtrl.SetExtendedStyle(LVS_REPORT);
// This displays fine, but where's the headings?!
listCtrl.InsertItem(0, "Item0");
}
Many thanx,
funbag!
skydiving....if at first you don't succeed, you're fecked!
|
|
|
|
|
I test your code and it's ok,problem is not here.
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
that's really strange! I can't seem to get it going at all. You think maybe there might be a message I'm not mapping or something???
skydiving....if at first you don't succeed, you're fecked!
|
|
|
|
|
overriden OnCreate of your view class and change it to this:
int CYourView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
lpCreateStruct->style |= LVS_REPORT;
if (CListView::OnCreate(lpCreateStruct) == -1)
return -1;
return 0;
}
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Thank you thank you thank you thank you thank you
(and I didn't use copy and paste there either!)
It works great! Thank you!
skydiving....if at first you don't succeed, you're fecked!
|
|
|
|
|
In MFC Doc/View SDI or MDI application, every command message sent by menu items or buttons in a toolbar can be routed to CMainFram::OnCmdMsg(..) function. Howevey, if I want to menually send a command message using:
<br />
SendMessage(AfxGetMainWnd(), WM_COMMAND, ID_MYCOMMAND, 0);<br />
or using
<br />
PostMessage(AfxGetMainWnd(), WM_COMMAND, ID_MYCOMMAND, 0);<br />
this message doesn't get routed to CMainFram::OnCmdMsg(..). Why? In other words, how can I simulate the menu command message using SendMessage or PostMessage?
|
|
|
|
|
You're sending/posting the message correctly. However, you need a handler of the form:
ON_COMMAND(ID_MYCOMMAND, OnMyCommand) /ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Thanks. I did have the command handler. The message sent by SendMessage or PostMessage did get routed to CMainFrame::OnCommand(...) function not CMainFrame::OnCmdMsg(...). But the message sent by a menu item gets routed to CMainFrame::OnCmdMsg(...). What I am wondering is that the difference between those two mechanism.
|
|
|
|
|
Hmmm, that's odd. The command handler for IDC_MYCOMMAND should get called for the menu item IDC_MYCOMMAND. Perhaps the notification isn't being passed down the chain.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
The command handler gets called actually for either mechanism but it seems so via different road. Menu command thru OnCmdMessage, and mannually sent command thru OnCommand.
The reason I ask this question is that the command handler may be located in a View or Doc class, not necessary in CMainFrame class, if the menually sent command message is routed to CMainFrame::OnCmdMsg function, then I had the chance to forward the message to other classes capable of handling message.
|
|
|
|
|
as far as I can see all WM_COMMAND messages gets routed to the receiving windows' OnCommand handler, which in turn calls OnCmdMsg (provided some prerequisites are present).
Call stack:
CCmdTarget::OnCmdMsg
CWinApp::OnCmdMsg
CWnd::OnCmdMsg
CView::OnCmdMsg
CFrameWnd::OnCmdMsg
CWnd::OnCommand
CFrameWnd::OnCommand
CWnd::OnWndMsg
CWnd::WindowProc
AfxCallWndProc
AfxWndProc
So your SendMessage and your menu selection should all be routed through OnCommand first and then to OnCmdMsg. You could put a breakpoint in OnCmdMsg and check on the call stack that OnCmdMsg is called from OnCommand in both instances.
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Steen Krogsgaard wrote:
So your SendMessage and your menu selection should all be routed through OnCommand first and then to OnCmdMsg. You could put a breakpoint in OnCmdMsg and check on the call stack that OnCmdMsg is called from OnCommand in both instances.
I did exactly what you described above but I did not see the command got routed to OnCmdMsg. However, it did get routed to OnCommand function. Odd, huh.
Is there any difference between menu sent message and message sent by SentMessage or PostMessage?
|
|
|
|
|
I made a little test program with three menu items: The Option, Post It and Send It. The Option just displays a message box. Post It and Send It posts or sends a WM_COMMAND with IDC_THE_OPTION as wParam to the AfxGetMainWnd() window. I have overriden the view OnCmdMsg and the framewnd OnCmdMsg (it's a SDI app) and put traces in if IDC_THE_OPTION (or any of the other two menu items) passes through.
I get what I'd expect: Everything goes through first CFrameWnd::OnCmdMsg and the CView::OnCmdMsg. So there must be something else "wrong" with your app.
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
