Re: Batch file and MFC (Properly Terminating Application)
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Thu, 08 Feb 2007 16:52:00 -0500
See below...
On 8 Feb 2007 07:30:45 -0800, "one-trick-pony" <worldofpain.aamir@xxxxxxxxx> wrote:
This thing eats my posts! Ugh I have to rewrite my post all over*****
again. This is not the first time it has happened. If you see two
posts, please disregard either one.
My question is, what is proper procedure for restarting/shutting down
machine? The application that initiates shutdown/reboot, what
procedure should it follow-if any?
Start menu, shutdown.
You don't want to do this.
*****
****
Joseph pointed out restarting/shutting down machine is not a good
practice and MS is making it difficult to do so. However, to give you
guys one example, my code changes system's Path Environment variable
but it does not take effect until the next restart of the machine.
First, you should not ever, ever, for any reason whatsoever, modify, touch, play with, or
actually depend on the PATH environment variable. To do so is to say "I want my program
to break. I enjoy tech support calls to people who never heard of environment variables,
and can't type, and will break their system even worse trying to modify the path. I enjoy
pain, suffering, and high post-deployment support costs".
Been there. Done that. I make it a policy that if there is a way to avoid using PATH for
*anything*, I will go to any length to avoid it. The good news is that you should need
PATH so rarely that the cost of avoiding it is zero.
Why do you think you need it? Given how easy it is to avoid ever needing it, what is the
rationale for using it.
Take this as a basic rule: ignore the existence of the PATH variable. All questions
relating to the use of PATH can be simplified by referring to this rule.
*****
****
Furthermore, could you explain the code below;
void CMyView::doInvert()
{
running = TRUE;
AfxBeginThread(run, this); << What is this line doing? More
precisely, what is purpose of 'this'?
AfxBeginThread ultimately calls CreateThread, but it actually doesn't start in your
function. Instead, it starts a function in the MFC library as the top-level thread, and
passes 'run, this' to it. Eventually, that function will call 'run' with 'this'. The
point here is that it has to use an internal MFC top-level function that handles the
creation, and eventual deletion, of the thread-specific MFC state.
The reasons for 'this' is discussed in my essay on worker threads. Since the 'run'
function must be static, you have no way to get back into "C++ space" (which has nothing
to do with faster-than-light travel at warp speeds) from "C space". So by using 'this',
you can go back into your C++ object, just running in a separate thread. Mostly, it is
'this' that is passed, but I discuss other options in my essay.
****
}****
UINT CMyView::run(LPVOID p) <<Why not directly execute run
function(thread code) below?
Because you'd have to write me-> in front of everything, and that's a pain, so you move
back into C++ space
****
{****
CMyView * me = (CMyView *)p; << what is happening here??
me->run();
return 0;
}
void CMyView::run() <<<<run function/thread code
{
for(int x=y = 0; running && y < image.height; y++)
So you are declaring x but not y; then you're declaring x in the next line. Why?
****
for(int x = 0; running && x < image.width; x++)****
changePixel(x, y);
running = FALSE;
For example, you'd have to do this as
for(int y = 0; me->running && y < me->image.height; y++)
for(int x = 0; me->running && y < me->image.width; x++)
changePixel(x, y);
******
}****
Essentially, what I want to know is what is purpose of function UINT
CMyView::run(LPVOID p) ? Thanks.
It has to exist because the function prototype for a thread function is
UINT name(LPVOID p);
and it must be a global function or a static member function; that is, if it is declared
in a class it must be declared as
static UINT name(LPVOID p);
which means that code in it cannot access any instance variables of the class, because it
is not a member function that is associated with an instance.
joe
*****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: Batch file and MFC (Properly Terminating Application)
- From: one-trick-pony
- Re: Batch file and MFC (Properly Terminating Application)
- References:
- Re: Batch file and MFC (Properly Terminating Application)
- From: one-trick-pony
- Re: Batch file and MFC (Properly Terminating Application)
- From: Scott McPhillips [MVP]
- Re: Batch file and MFC (Properly Terminating Application)
- From: one-trick-pony
- Re: Batch file and MFC (Properly Terminating Application)
- From: Scott McPhillips [MVP]
- Re: Batch file and MFC (Properly Terminating Application)
- From: one-trick-pony
- Re: Batch file and MFC (Properly Terminating Application)
- From: Joseph M . Newcomer
- Re: Batch file and MFC (Properly Terminating Application)
- From: one-trick-pony
- Re: Batch file and MFC (Properly Terminating Application)
- From: Joseph M . Newcomer
- Re: Batch file and MFC (Properly Terminating Application)
- From: one-trick-pony
- Re: Batch file and MFC (Properly Terminating Application)
- Prev by Date: Re: CRITICAL SECTION Help!
- Next by Date: Re: Source .cpp unchanged, .obj changes on recompile - why?
- Previous by thread: Re: Batch file and MFC (Properly Terminating Application)
- Next by thread: Re: Batch file and MFC (Properly Terminating Application)
- Index(es):
Relevant Pages
|