|
*** Disclaimer: i might not fully understand what you're trying to do ***
_beginthread() takes the address of a function meant to be called using the __cdecl calling convention. If you want to start a thread using _beginthread(), you will create a __cdecl function (just put __cdecl before the function name) and pass the address in. End of story.
Mostly OT, but keep in mind that it's usually a bad idea to kill threads from other threads - best off setting a flag and letting the thread process exit when it gets around to checking it.
|
|
|
|
|
what I meant by killing is:
//this is done in the OnShowWindow function because I only need the thread
// running when dialog is shown.
if(bShow)
{
m_hThread = (HANDLE)_beginthread(reader,0,this);
}
else
{
::GetExitCodeThread(m_hThread,&dwExitCode);
if (STILL_ACTIVE == dwExitCode)
{
::TerminateThread(m_hThread,dwExitCode);
::CloseHandle(m_hThread);
};
m_hThread=NULL;
};
so how should I call "reader" and how is the definition of reader to avoid
compiler error when using __fastcall convention?.
regards.
|
|
|
|
|
DaviziN wrote:
so how should I call "reader"
You do not explicitly call this function. It is the starting address for the secondary thread.
DaviziN wrote:
how is the definition of reader to avoid
compiler error when using __fastcall convention?.
The prototype for it should look like:
void __cdecl reader( void * );
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
DaviziN wrote:
what I meant by killing is:
First off, don't use TerminateThread() - it doesn't give the thread a chance to clean up after itself, and is pretty much just asking for trouble.
The simplest way to close the thread cleanly is to have a global variable somewhere, and check it from within the thread - when the variable is set, the thread knows to exit. You could also use an Event object. Either way, you can then wait for it to end safely before continuing.
|
|
|
|
|
This is not *exactly* a VC++ question, but bear with me 
The following code works fine on VC6/7.1
#include <stdio.h>
void doit( const char* &g )
{
g++;
}
int main( int argc, char** argv )
{
char* s = "Hello";
printf( "%s\n", s );
doit( s );
printf( "%s\n", s );
return 0;
}
So why does GCC piss and moan about it? Is there something I'm missing? Specifically it(GCC) claims that the function call to doit() is bad because
test.cpp:13: error: invalid initialization of reference of type 'const char*&'
from expression of type 'char*'
test.cpp:5: error: in passing argument 1 of `void doit(const char*&)'
Any idea why VC7.1 doesn't flag this? I wanted the function doit() to potentially increment the pointer but NOT change it's value. So you'd see
Hello
ello
for the output of the test.
Is there a better way to accomplish this?
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
-- modified at 14:01 Monday 3rd October, 2005
|
|
|
|
|
Jim Crafton wrote:
Any idea why VC7.1 doesn't flag this? I wanted the function doit() to potentially increment the pointer but NOT change it's value. So you'd see
Hello
ello
for the output of the test.
Is there a better way to accomplish this?
Look , for example we have two functions :
void doit1( const char *g )
{
cout<<&g<<" ";
cout<<g<<" ";
cout<<*g;
cout<<endl;
g++;
}
void doit( const char *&g )
{
cout<<&g<<" ";
cout<<g<<" ";
cout<<*g;
cout<<endl;
g++;
}
int _tmain(int argc, _TCHAR* argv[])
{
char* VALUE = "Hello";
doit1(VALUE);
cout<<s<<endl;
doit(VALUE);
cout<<s<<endl;
return 0;
}
in case (A) when function doit1() is executed you pass to this function as avalue a pointer to char. So inside doit1() function, new const char* g object is created
and it is pointing to VALUE , so when you write g++ ,nothing happens with VALUE, only g is pointing to a new address , so when function ends.VALUE remains the same.
in case (B) when function doit() is executed you pass to this function a reference to pointer to char. So inside doit() no objects are cerated and you are operating straight with the address of VALUE , so when you write g++ , VALUE-s address changes and therefore when function ends "ello" is printed.
clear??
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
-- modified at 15:19 Monday 3rd October, 2005
|
|
|
|
|
Thanks!
That's what I thought was going on. So why does GCC flag it (in your example, function B) as an error? That's what is really bugging me. It seems to me that this is perfectly acceptable and correct C++.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
|
|
|
|
|
Jim Crafton wrote:
So why does GCC flag it (in your example, function B) as an error?
no idea 
Jim Crafton wrote:
It seems to me that this is perfectly acceptable and correct C++.
to me too
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
|
|
|
|
|
I am using ReadDirectoryChangesW to detect changes on a file in an MFC app (basically watches the containing directory and then sees if it was the specified file).
When I modify the file and save, the event is detected and the thread calls the main application thread to process. However, it appears that a file modification (or creation for that matter) generates 3 or 4 notification records all containing the FILE_ACTION_MODIFIED constant. This results in the event handler processing the event multiple times instead of once giving poor performance. First do they represent different updates (eg. content, attributes) and second is there a simple way of differentiating between them without writing complicated code checking attributes, etc?
I tested Wes Jones's DirWatcher project and it does the same thing.
TIA
|
|
|
|
|
Does FindFirstChangeNotification() work any better?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Not the suggestion I wanted to hear as I anticipate a time-consuming restructuring of some stuff but anyway.  Having looked at the MSDN stuff though, I can't see how it would be different since it's the events that are raised that's the issue. I would imagine the same file system events would be notified regardless of which function one is using to get them. Good idea though. If all else comes to nought, I'll give FindFirstChangeNotification() a go.
Thanks
|
|
|
|
|
i knew its a beginner question but still
i need to open dialog that in my project with the code
not with DoModel because in need the dialog that opend the
new dialog to keep on running
|
|
|
|
|
DoModeless then. Sorry, I don't have a lot of experience with Modeless Dialogs, though.
Danny
The stupidity of others amazes me!
|
|
|
|
|
you need a modeless dialogs.
CMyDialog mydialog;
mydialog.create(...);
mydialog.showwindow(...);
or
CMyDialog *pMydialog;
pMydialog = new CMyDialog;
pMydialog->Create(...);
pMydialog->ShowWindow(...);
-prakash
|
|
|
|
|
As others stated you need to use Modeless dialogs in your application,
you can learn how to create and use them from here[^]
"Success is the ability to go from one failure to another with no loss of enthusiasm." - W.Churchill
-- modified at 13:10 Monday 3rd October, 2005
|
|
|
|
|
morning, this app works fine in debug but crash on release mode with access violation. I have tried to turn optimazation to default, still no luck. it's a motithreading app, anybody got experience about this? here is the call stack when it crash:
USER32! 77e338b0()
CDialog::EndDialog(CDialog * const 0x00000000 {CDialog hWnd=???}, int 2) line 580 + 13 bytes
CDialog::OnCancel(CDialog * const 0x00000000 {CDialog hWnd=???}) line 709
CSurchrgDlg::Exit() line 270
Run(void * 0x0012f75c) line 310
_AfxThreadEntry(void * 0x0012f280) line 112 + 5 bytes
ADDSURCHRG! _beginthreadex + 202 bytes
KERNEL32! 7c57b388()
|
|
|
|
|
simply put, you window is not valid when it was closed.
Yes, these kind of problems are quite common in VC++ w.r.t apps running in Debug and not working on Release.
Since you need to take care while multithreading in MFC, I do notknow how the you have created the window, which thread own/created the window. Does that thread has its own message loop, etc ,etc.
-prakash
|
|
|
|
|
Thank you for the reply
here is part of the dialog window:
BOOL CSurchrgApp::InitInstance()
{
.....
CSurchrgDlg dlg;
m_pMainWnd = &dlg;
dlg.DoModal();
}
when I set breakpoint at dlg.DoModal(); I would get the &dlg, dlg and m_pMainWnd with {CSurchrgDlghWnd=0x0000000}, but this seems like the standard coding, not sure why it's getting all the 00000000......
|
|
|
|
|
See http://www.codeproject.com/debug/survivereleasever.asp
|
|
|
|
|
Using Shared Memory with a large structure, but when I start a new project using the current one as a basis, the names referenced in the structure are the old names and not the new names.
If I type in the new names then All OK, but if I select old name from list error (as would expect). But how to arrange for the display of new structure items in the list.
Is this an IDE bug or does the registry need a tidy up (and how).
<br />
struct TSharedMemory{<br />
....<br />
....<br />
};<br />
<br />
g_hMap = ::CreateFileMapping((HANDLE) 0xFFFFFFFF,<br />
NULL,<br />
PAGE_READWRITE,<br />
0,<br />
sizeof(TSharedMemory),<br />
"TP_SharedMem"<br />
);<br />
if(g_hMap == NULL)<br />
{<br />
int s = GetLastError();<br />
g_szFormatting.Format ("Shared Memory Not Obtained (Signals); Error = %d", s); <br />
AfxMessageBox(g_szFormatting);<br />
}<br />
else<br />
{<br />
g_hMap = (TSharedMemory*)::MapViewOfFile(g_hMap,FILE_MAP_WRITE,0,0,sizeof(TSharedMemory));<br />
<br />
memset(g_pMem, 0, sizeof(TSharedMemory));<br />
}<br />
<br />
memcpy(&g_pMem->tips.buffer, &BCbuffer.data , sizeof(BCbuffer.data));
i.e. when you type &g_pMem-> its the old names that are shown.
|
|
|
|
|
hi,
i want to know if it's possible to trigger an event in ms-word from mi MFC project, i.e. trigger a button click event without clicking that button with the mouse..
thanx
|
|
|
|
|
Hi,
I've put a ComboBox control into a toolbar using clickety[^], and want to trap the user pressing enter. However, this keypress seems to disappear into the aether, and I can't trap it using OnChar, OnSelendok, or any of the other message handlers I've tried, in any of the Main Frame, view or combobox classes!
Any idea where the Enter keypress goes? 
|
|
|
|
|
Not sure about ComboBoxes as I've not tried to do this, but have you tried handling the CBEN_ENDEDIT message from WM_NOTIFY?
In your message map add
ON_NOTIFY_REFLECT(CBEN_ENDEDIT, OnEndEdit)
and in your class you'd add a method such as
void Class::OnEndEdit (NMHDR *pNMHDR, LRESULT *pResult)
{
...
*pResult = 0;
}
I did something akin to this when catching the end of someone editing a List Control edit thingmy.
Note that I make no guarantee's that this will do anything close to what you want.
|
|
|
|
|
As an additional note, you should cast pNMHDR to a NMCBEENDEDIT*, and it will show you the reason why you're in your function:
NMCBEENDEDIT* pCBEnd = (NMCBEENDEDIT*)pNMHDR;
if (pCBEnd->iWhy == CBENF_RETURN)
Or something like that.
I'd try coding it up to prove my theory, but I'm too busy thinking up silly things to say in the Lounge.
|
|
|
|
|
Thanks for the suggestions. I found this[^] which sorted it out in a slightly different way.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
