|
hi, all
I kinda fixed the issue but still not sure what's wrong with the previous method.
it was having access violation at this point:
void CSurchrgDlg::Exit()
{
if( !m_bCanceled )
{
.....
}
CDialog::OnCancel();
}
now I used "PostMessage( cDlg->GetSafeHwnd(), WM_QUIT, 0, 0 );" replaced the exit funtion at the end of RUN. seems to work.
OR I used PostMessage(WM_QUIT); to replace CDialog::OnCancel(); would work, too.
could someone tell me what's wrong with the calling the CDialog::OnCancel();? Thank you for your time!
-- modified at 17:59 Monday 3rd October, 2005
|
|
|
|
|
If you are multithreading you cant call thouse funtions from another thread.
I dont know if I guessed it rite.
-prakash
|
|
|
|
|
Hi for all
I would like to know what is these types of variables
HDC, HWND, HGLRC.
Thanks a lot
|
|
|
|
|
They are all handles.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
what is the different between them?
I
|
|
|
|
|
HDC - Device handle to Device Context.
HWND - Handle to window.
HGLRC - I dont remember (need to lookup)
Basically they are all handles, i.e. The handles are just a 32bit value and nothing more then that.
It is one of the way of hinding the data that the window is using for displaying the window and the user can work on it only by passing the handle to appropriate windows function.
-prakash
|
|
|
|
|
is HGLRC an OpenGL rendering context ?
|
|
|
|
|
yes 
-prakash
|
|
|
|
|
when I try to use this optimization (Visual Studio .NET 2003) I get the following compiler error:
error C2664: '_beginthread' : cannot convert parameter 1 from 'void (void *)' to 'void (__cdecl *)(void *)'
any workarround to avoid this or any other way of use threads and __fastcall optimizations. I need to kill the thread from the class where is created when this class is clossing.
regards.
|
|
|
|
|
So what does the call to _beginthread() look like?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
*** 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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
