Well, the call inside the loop is pretty useless but if it makes you happy...
The sole purpose, as written, is to cause the big while loop to break out if the response is anything but "still running". But the WaitForSingleObject() returning anything other than "WAIT_TIMEOUT" (that is, WAIT_OBJECT_0) also breaks out of the loop (the "else clause") which will happen as soon as the thread stops running (which sets the exit code and signals the hProcess object).
Now, I'll grant you that by having the call at the bottom of the while loop may cause you to notice the process termination a couple of microseconds earlier than if you went to the top of the loop but you counter act that miniscule gain by discarding the status you might have received then and issue another GetExitCodeProcess() immediately upon exiting the while loop.
So, it adds nothing to the code, adds processing at each iteration. But, like I said, if it makes you happy ....
If I were a malicious / devious person, I'd write my process to "return 259;" as the exit status. Since GetExitCodeProcess() returns either status STILL_ACTIVE or the return code from the process. If 259 is my exit code, following Microsoft's method for testing the status would be fooled into thinking the process is still running. Does this count as "Amusing Microsoft API Tricks"
Anyway, WaitForSingleObject() on the hProcess object is the only way to be sure.
I observe that you are passing a variable named sz_SQLServer_Install_FileName to CreateProcess which would obviously imply that you are installing SQL Server. Are you using a MSI installer? According to the documentation... the MsiExec.exe and InstMsi.exe MSI installers will return useful status/error codes.
I'm running these programs. I think Microsoft wrote the installer.
I just finished running the test, and put the line back in. Can't detect a cancel when I click the red X square during the expansion of the files to the temp dir. With the line, I can detect the click. So I guess the line is useful. I just want to cover my butt, who knows what the user will do.
So I detect the cancel, use the message pump to acknowledge the cancel, messagebox, start the installation again.
Thanks for your help last night Randor. Your open and closed probe questions help me understand why I needed that line of code, to detect if the process was still running.
It did not dawn on me that that the exit code came from the program that I was running, and that I can't trust the program to produce an exit code upon exit.
As far as the WaitForSingleObject goes, I have it set for 10, because I needed the cosmetic loop to run, and needed to be able to send messages to the pump.
I like the way it is, so I will leave it, and add something to make a check for completion, like checking to see if the final install log file exist or something.
I was tired last night so I left the office.
Almost done with the initial version of my program, and everything actually works. I was able to translate all my vb programs so far which amazes me. Should be done by the end of the month, and will then make the deployment package.
Going to need some alpha testers, I wonder if Code Project can help me with that.
dynamic linking: your code is built to use functions in a shared library; your code runs, the OS finds the shared lib and gives you access to the functions you need.
dynamic loading: your code can discover, load and execute code from shared libraries. but the shared libraries might not even exist at run time. your code explicitly loads the shared library. best example of this is plugins.
to see if the thread is finished before calling again to save another report. And if not just wait. It seems in Win7 now, this call will not exit so that the program will just freeze. It does not freeze all the time, seems random. In WinXP, the same program seems not to have this problem. I am not sure what I am missing.
Any help or suggestion will be appreciated. Thanks!
From the code example I take it that you create the Save2CWGCoilRep thread from the UI thread, i.e. from a menu or button handler function. My guess then is that you have a deadlock:
1. The background thread sends messages to the UI thread. Maybe it tries to display a message box, but it could be anything really.
2. The UI thread is suspended in WaitForSingleObject and can't process the message.
It's risky to suspend the UI thread as you don't know when or why messages are posted to it. I would instead protect the critical parts of Save2CWGCoilRep with a critical section and take away the WaitForSingleObject call in the UI thread.
Obj1 is a derived class object where base class char pointer is initialized with "singh" and
derived class char pointer is initilized with "sunil". I want to create Obj2 out of Obj1. Separate memory should be created for
Obj2 char pointer (base part and derived part as well) and that should be initialized with the strings contained in Obj1.
Here the problem is: Derived class part can be initialized with copy constructor. How to initialize the base class char poniter of Obj2 with the base class part of Obj1. char pointers in
both the classes are private.
I tried using initializer list but could not succeed.
Does this do what you want?
1) Added +1 to all of the strlen statements used for memory allocation (strlen doesn't account for the NULL terminator - which you need to allow for when storing the string, as opposed to simply displaying it)
2) Made the data members protected
3) Uncommented the call to the Base constructor in the 2nd constructor for Derived