 |
|
 |
Apologies for the shouting but this is important.
When answering a question please:
- Read the question carefully
- Understand that English isn't everyone's first language so be lenient of bad spelling and grammar
- If a question is poorly phrased then either ask for clarification, ignore it, or mark it down. Insults are not welcome
- If the question is inappropriate then click the 'vote to remove message' button
Insults, slap-downs and sarcasm aren't welcome. Let's work to help developers, not make them feel stupid.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
 |
|
 |
For those new to message boards please try to follow a few simple rules when posting your question.- Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
- Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
- Keep the subject line brief, but descriptive. eg "File Serialization problem"
- Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
- Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
- Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
- If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode HTML tags when pasting" checkbox before pasting anything inside the PRE block, and make sure "Ignore HTML tags in this message" check box is unchecked.
- Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
- Please do not post links to your question in one forum from another, unrelated forum (such as the lounge). It will be deleted.
- Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
- If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
- No advertising or soliciting.
- We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
 |
|
 |
void lxt971reset()
{
int temp2,temp1;
pioreset1=pioreset1 | 0x0010;
*pioaddr_ptr=9<<24;*piowrdata_ptr=pioreset1;wait(10);*piowr=1;*piowr=0;
wait(1000);
pioreset1=pioreset1 & (~0x0010);
*pioaddr_ptr=9<<24;*piowrdata_ptr=pioreset1;wait(10);*piowr=1;*piowr=0;
}
|
|
|
|
 |
|
 |
Are you going to pay for it?
Every new day is another chance to change your life.
|
|
|
|
 |
|
 |
Using Microsoft's NMAKE with -I option for include paths. It works for the include files in these folders, but can't seem to find one in a named subfolder:
Here's the resulting command & error message:
cl /nologo /Ox /MD /EHsc /W3 /D_CRT_SECURE_NO_DEPRECATE -I "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\sys"; -I. "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\sys" "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include" "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include" -DAVOID_WIN32_FILEIO -DCHECK_JPEG_YCBCR_SUBSAMPLING -DDEFAULT_EXTRASAMPLE_AS_ALPHA -DSTRIPCHOP_DEFAULT=TIFF_STRIPCHOP -DSTRIP_SIZE_DEFAULT=8192 -DLOGLUV_SUPPORT -DNEXT_SUPPORT -DTHUNDER_SUPPORT -DLZW_SUPPORT -DPACKBITS_SUPPORT -DCCITT_SUPPORT -DTIF_PLATFORM_CONSOLE -DFILLODER_LSB2MSB /c tif_unix.c tif_unix.c tif_unix.c(35) : fatal error C1083: Cannot open include file: 'sys/types.h': No such file or directory
Two things to note:
1. The "missing" file, "types.h", IS in the "sys" subfolder of one of the include paths, so "sys/types.h" should have been found, and
2. The "sys" subfolder was also included (out of desperation) and types.h STILL wasn't found.
Any ideas why this include file can't be found?
"Microsoft -- Adding unnecessary complexity to your work since 1987!"
|
|
|
|
 |
|
 |
I haven't messed with make files in a very long time, but it seems that the preprocessor is going to look in the following folders for sys/types.h:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\sys"
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\sys"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include"
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include" Of the above, only the last one would appear to contain a folder named sys, correct?
Does the \ vs. / make any difference? I don't think it does, but I just wanted to mention it.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
 |
|
 |
Is it safe to pass CComVariant declared locally to other function
1. Can I pass the CommVariant to other function, when not created using new ?
2. Should I free it/delete expecitly some where ?
3. Is it safe ? any precauions ?
CComVariant comVart;
comVariant.vt = VT_I4;
comVariant.intVal = 10;
SendComVariantToOtherFunction(comVart);
Thanks in advance!!
|
|
|
|
 |
|
 |
ptr_Electron wrote: 1. Can I pass the CommVariant to other function, when not created using new ?
Yes.
ptr_Electron wrote: 2. Should I free it/delete expecitly some where ?
No, when not allocated on the heap. When using new, it must be of course freed using delete. Everything else is done by the destructor.
ptr_Electron wrote: 3. Is it safe ? any precauions ?
It is safe. But you must take care when assigning data (type and data must match).
|
|
|
|
 |
|
 |
I want ot check CComVariant.boolval is valid and extract bool value from it
if(SUCCEEDED(m_abc->GetProperty("test", comVar)))
{
if (comVar.boolVal == VARIANT_TRUE)
{
}
}
please help!
|
|
|
|
 |
|
 |
It could be that m_abc->GetProperty returns something other than a bool, so you should also check comVar.vt to see that you really have a boolean.
|
|
|
|
 |
|
 |
You must also check the vt member. When expecting a boolean value, it must be VT_BOOL. When the requested property exists but did not contain a value, VT_EMPTY or VT_NULL are returned (the return type depends on the property value type).
|
|
|
|
 |
|
 |
I have craeted following kind of function in a class:
void SetStr(string& s1, string& s2)
{
const char* s =(s1+s2).c_str();
cout<<s<<endl;
}
On calling it from main nothing is getting printed on console. While the following function works:
void SetStr(string& s1, string& s2)
{
cout<<(s1+s2).c_str()<<endl;
}
Can someone please tell me what is the problem.
Thank you.
|
|
|
|
 |
|
 |
The result of an expression is temporary, and it is destroyed an the and of the expression evaluation.
In your first case, you are getting a temporary string as a result of s1+s2, whose buffer pointer is saved in s. After that, the expression finish, the temporary is destroyed, and so it is its buffer and s is left dangling. You had been lucky in having printed nothing. accessing a deleted buffer can even result in a crash.
In your second example, the temporary string resulting from s1+s2 is kept alive until the expression it belongs ( cout<<(s1+s2).c_str()<<endl; ) is evaluated. Hence its buffer (renturned from c_str()) is still there at the time its pointer is given to cout.
Your first sample works correctly if you retain the string:
void SetStr(string& s1, string& s2)
{
string ss; ss = s1+s2; const char* s = ss.c_str(); cout << s << endl; }
2 bugs found.
> recompile ...
65534 bugs found.
modified 12 hrs ago.
|
|
|
|
 |
|
 |
Great answer.
You miss an underscore in your sample code.
--Carlo The Nitpick
Veni, vidi, vici.
|
|
|
|
 |
|
|
 |
|
 |
I'm running a cosmetic loop, and I think I should check to see if the CreateProcess is still running. I've seen other post for the same thing, but could not remember the nomenclature for it.
Just looking for recommendations
I played around with checking the exit code, but I know it's not the proper way to do it
GetExitCodeProcess(pi.hProcess, (unsigned long *)&exit_status);
if (exit_status != 259)
break;
My CreateProcess
if (CreateProcess(sz_SQLServer_Install_FileName, szParameters, NULL, NULL, FALSE, CREATE_DEFAULT_ERROR_MODE | NORMAL_PRIORITY_CLASS, 0, sz_SQLServer_Install_FolderPath, &si, &pi) ) {
while(WAIT_TIMEOUT == WaitForSingleObject(pi.hProcess, 10)) {
MSG oMSG;
while(::PeekMessage(&oMSG, NULL, 0,0, PM_NOREMOVE)) {
if(::GetMessage(&oMSG, NULL, 0,0) ) {
::TranslateMessage(&oMSG);
::DispatchMessage(&oMSG);
}
else {
break;
}
|
|
|
|
 |
|
 |
Hi Jim,
What problems are you having? The call to GetExitCodeProcess looks good to me although not sure why you needed the cast on exit_status.
Also... WaitForSingleObject will return WAIT_OBJECT_0 when the process has exited.
|
|
|
|
 |
|
 |
The original problem that lead to the question was that when the program running in the process was canceled, or halted due to a requirement missing, the cosmetic loop would still be running, instead of exiting and sending the appropriate message to the message pump to go to the next stage. So I added the GetExitCode to double check that the process was still running, or if the process had been halted.
Just didn't think my quick fix was the correct way to check, and just wanted to do it right.
|
|
|
|
 |
|
 |
jkirkerx wrote: The original problem that lead to the question was that when the program running in the process was canceled, or halted due to a requirement missing, the cosmetic loop would still be running, instead of exiting and sending the appropriate message to the message pump to go to the next stage.
I actually have something to say about this. I have noticed over the last few years that many of the younger junior programmers coming out of college are no longer using exit codes. I have noticed this in many of the recent Microsoft products and applications from various other software vendors. I believe it is probably because most of us older engineers have experience with the Unix and DOS shell and have extensively used exit codes in bash,cshrc scripts and/or DOS batch files.
Unfortunately since the installer you are using is not returning an exit code upon cancellation... you may need to think outside the box and come up with a creative way to determine if your installer has completed. I noticed that one of your variable names was associated with Microsoft SQL Server... so maybe you could check the registry keys under the tree: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\
Finally, I would encourage you (and anyone reading this) to think of this experience as a lesson; Exit codes might be useful to someone... rather than always return 0; consider returning a useful value that reflects the outcome of the task.
-Best Wishes,
-David Delaune
|
|
|
|
 |
|
 |
I was considering doing something like that.
Chunk is saying to dump my line of code, and trust the WaitForSingleObject.
I do know the name of the SQL Server installation process, just an idea.
Let me run some more test with and without the cancel after removing the lines, and see what happens again. They take 30 minute each for a full run. Back tomorrow.
|
|
|
|
 |
|
 |
There's nothing wrong with using WaitForSingleObject() on the hProcess returned from CreateProcess(). Its very purpose is to give you a waitable object that's signalled when the process teminates. Until it terminates, the GetExitCodeProcess() cannot tell you the exit code
Some folks might comment on the fact that your wait loop includes a message pump which implies that you are waiting during processing of a GUI element / button but to each his own. This works.
|
|
|
|
 |
|
 |
Cool.
Well I'm not getting the exit code, but I do get a still active code which is OK for now.
Thanks Chuck.
|
|
|
|
 |
|
 |
That's the defined behavior of GetExitCodeProcess(). The exit code does not exist until the process exits! The defined return is "Still Active", meaning "No exit code exists", or colloquially expressed, "Yo, Dude, What Exit Code? It Ain't Exited Yet".
|
|
|
|
 |
|
 |
This is the complete code I wrote.
If no one has an objection to the GetExitCodeProcess in the loop, I'll stick with it because it works. I just thought it was completely wrong to use, or perhaps I'm just getting better at this.
if (CreateProcess(sz_SQLServer_Install_FileName, szParameters, NULL, NULL, FALSE, CREATE_DEFAULT_ERROR_MODE | NORMAL_PRIORITY_CLASS, 0, sz_SQLServer_Install_FolderPath, &si, &pi) ) {
while(WAIT_TIMEOUT == WaitForSingleObject(pi.hProcess, 10)) {
MSG oMSG;
while(::PeekMessage(&oMSG, NULL, 0,0, PM_NOREMOVE)) {
if(::GetMessage(&oMSG, NULL, 0,0) ) {
::TranslateMessage(&oMSG);
::DispatchMessage(&oMSG);
}
else {
break;
}
if (ndx != 100) {
SendMessage(g_SQLServer_Install_Progress_Bar, PBM_SETPOS, (WPARAM)ndx, 0);
UpdateWindow(g_SQLServer_Install_MDIWindow);
Sleep(100);
++ndx;
}
else {
if( iMO == 0 ) {
SetWindowText(g_SQLServer_Install_Progress_Text, L"Installation may take up to 30 minutes");
iMO = 1;
}
else {
SetWindowText(g_SQLServer_Install_Progress_Text, L"Installing Microsoft SQL Server Express 2008");
iMO = 0;
}
UpdateWindow(g_SQLServer_Install_MDIWindow);
ndx = 0;
}
GetExitCodeProcess(pi.hProcess, (unsigned long *)&exit_status);
if (exit_status != 259)
break;
}
}
GetExitCodeProcess(pi.hProcess, (unsigned long *)&exit_status);
if (exit_status == 0) {
SendMessage(g_SQLServer_Install_MDIWindow, WM_COMMAND, (WPARAM)g_SQLServer_Install_IDC_COMMAND, (LPARAM)g_SQLServer_Install_IDM_COMPLETE );
}
else {
SendMessage(g_SQLServer_Install_MDIWindow, WM_COMMAND, (WPARAM)g_SQLServer_Install_IDC_COMMAND, (LPARAM)g_SQLServer_Install_IDM_CANCEL );
}
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
exitCode = 1;
bResult = TRUE;
|
|
|
|
 |
|
 |
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 ....
|
|
|
|
 |