|
I am creating a little setup console application in C++. The application is called from autorun on a cd-rom. Once called, the application opens an html page and wait for the html page to be closed and start another setup program. The problem I have is that when someone accidentally eject the CD and reinsert it, the same html page is launch again. Is there a function that I can call to see if the html file is already opened and not open another html file if the first one is still open? I open the html page using ShellExecuteEx(), wait for the page to be closed using WaitForSingleObject(), and launch the second setup program using CreateProcess(). Any help would be appreciated, thanks.
|
|
|
|
|
What happens if you try and open the .html file using OpenFile(..., OF_SHARE_EXCLUSIVE)? If that fails then you know the file is already open.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Detect that the CD was ejected and then automatically close the web page.
If they re insert it then it re-starts the process.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
How do I detect that the CD was ejected and what can I use to close the file with? Right now my code looks like this:
STARTUPINFO si;
PROCESS_INFORMATION pi;
ZeroMemory(&si, sizeof(si)); // Zero out STARTUPINFO structure.
si.cb = sizeof(si); // Get size of STARTUOINFO structure.
ZeroMemory(&pi, sizeof(pi)); // Zero out PROCESS_INFORMATION structure.
// Set up SHELLEXECUTEINFO structure.
SHELLEXECUTEINFO sInfo = {0};
sInfo.cbSize = sizeof(SHELLEXECUTEINFO);
sInfo.fMask = SEE_MASK_NOCLOSEPROCESS;
sInfo.hwnd = NULL;
sInfo.lpVerb = "open";
sInfo.lpFile = Path;
sInfo.lpParameters = "";
sInfo.lpDirectory = NULL;
sInfo.nShow = SW_SHOWMAXIMIZED;
sInfo.hInstApp = NULL;
if (!ShellExecuteEx(&sInfo))
{ // Print error message if ShellExecuteEx failed.
printf("ShellExecuteEx failed (%d).\n", GetLastError());
} // Print error message if ShellExecuteEx failed.
WaitForSingleObject(sInfo.hProcess, INFINITE); // Wait for hta window to be closed.
if (!CreateProcess(0, Path, 0, 0, FALSE, NORMAL_PRIORITY_CLASS, 0, 0, &si, &pi))
{ // Print error message if CreateProcess failed.
printf("CreateProcess failed (%d).\n", GetLastError());
} // Print error message if CreateProcess failed.
|
|
|
|
|
The other process may not really have the file open anymore, it could have read it into memory and closed it.
The one question I have though is if the CD is removed, can you continue your installation? If so, then perhaps the single instance check that Blake Miller proposed is all you need. If not, then I'm not saying you shouldn't implement that you probably should implement that either way, however if it is an issue that you can't continue your installation after the CD was ejected, then I would pop up an error message "CD Ejected, Installation Canceled" and you could even make it a modal parent of the application you just launched.
To close the application is a tough one. The simplest method is simply "TerminateProcess", but that's a rough one and usually a last resort. There is a support article on MSDN that specifies the steps you could do to attempt to shut down an application peacefully.
Terminate an application cleanly[^]
You could do a simple polling to check if a file is on the CD until it fails, but that is kind of ugly. I haven't looked into seeing if there is a callback I would search the windows messages or perhaps WM_DEVICECHANGE may even work.
Registration for device Removals[^]
Alternatively, you could lock the drive so you can't eject then re-enable it after you're done.
Check this URL out for all the IOCTLs:
Locking the drive from being ejected[^]
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
While our setups were waiting for another program to finish, we created a special mutex.
If your AutoRun saw that this special mutex existed, then we did not launch our setup again. We assumed it was still running. Our setup ALSO checked for this mutex, in case the user accidentally started the setup program twice. Either way, it works well enough for not allowing your setup program to be running more than once. You can look at some of the 'limit program to a single instance' examples here on CodeProject.
|
|
|
|
|
i rying to code project provided here about process monitoring but it doesn't work i don't now may be th .dll or psapi.h ,psapi.lib ,kernal32.h
not working so th program not working if someone can help me by sending me this files..
this link is the project
http://www.codeproject.com/threads/A_not_so_simple_firewall.asp[^]
|
|
|
|
|
|
thanks''
if u can help i need another implementation of "process monitorer"
that one i couldn't anderstand easily..
plz
i need to know how to alow any process to start or not;;
|
|
|
|
|
Thank you for helping me out before with LPCTSTR, I understand it much better now, and I can get the visual c++6 to complie my program now. Some of the samples I recieved didn't work, and don't know why.
The PROBLEM:
Everytime I send a set of characters over the COM-port, and what I get on the display is: "?????????a" where a is the character I pressed last. I understand that ? means unknown value in the array, but why? Doesn't the program incrament the array and fill in it's unknows? If I set the array to some values, it will display those values, and overwritting the last character.
What am I doing wrong?
My aim is to catch the individual characters that are send to SortData(pszData)in a temporary buffer, and then filter the data that is recieved, and Display it on screen.
int i=1;
void CChildView::SortData(LPCTSTR pszData)
{
TCHAR buffer[1024];
_sntprintf(buffer, 1024, _T("%s"), pszData);
TCHR tempData[10];
tempData[i]=buffer[0];
if (i == 10)
{
i=0;
TCHAR buffer2 [1024];
_sntprintf(buffer2, 1024, _T(%"s"), tempData);
DisplayData(buffer2);
}//end if
i++;
}//end SortData
A computer virus is a program that
will make copies of itself in the memory of a computer, and will transfer
itself to other computers. Thus it fits the definition of a living system. Like a biological virus, it is a rather degenerate form,
because it contains only instructions or genes, and doesn't have any
metabolism of its own. Instead, it reprograms the metabolism of the
host computer, or cell. Some people have questioned whether viruses
should count as life, because they are parasites, and can not exist
independently of their hosts. --Stephen Hawking
|
|
|
|
|
First, I would recommend that you stop using _sntprintf for doing a simple string copy. Use _tcsncpy, that is what it exists for.
Second, if you end up copying the full amount of your buffer, you will not get a NUL terminator, and attempting to treat the contents of the buffer as a normal string may cause you problems.
The code you posted has a typo/bug in the second call to _sntprintf, the format string is incorrect.
The contents of tempData are undefined - it looks like you are assigning a value to the array starting at the second location in the array (1, instead of 0), and you are not NUL terminating the array before treating it as a string.
If you are trying to display the first 10 characters of any data that comes into the function, then you do not need the first string copy (or the buffer buffer), nor the tempData buffer. You can do something like:
void CChildView::SortData(LPCTSTR pszData)
{
TCHAR buffer[ 16 ];
_tcsncpy( buffer, pszData, 10 );
buffer[ 10 ] = _T( '\0' );
DisplayData( buffer );
} If that is not what you are trying to do, I misunderstand both your post and your code.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote:
First, I would recommend that you stop using _sntprintf for doing a simple string copy. Use _tcsncpy, that is what it exists for.
It's recommended that someone should stop using all the unsafe functions from the C libraries and start using the C++ library! I was also using C functions for formatting strings and such, but found that using the C++ stringstreams have more flexibility and are more elegant and fool proof than their C equivalants.
A better code example would be:
void CChildView::SortData(LPCTSTR pszData){
std::string sData(pszData);
DisplayData( sData.c_str() );
}
Utilizing the STL is better if performance is not a big issue, since it is less error prone that using straight C.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Would this work:
std::string sData(pszData);
if pszData is NOT NUL terminated?
I think the reason the _tcsncpy was used was because the input was not guaranteed to be NUL terminated.
|
|
|
|
|
pszData should be NULL terminated! If it's not, you are in big trouble!
The reason why pszData is NULL terminated, is because the name says it. p(ointer)s(tring)z(ero terminated)Data implies that the string is NULL terminated.
Also, all strings in C / C++ are NULL terminated, unless it's explicitly stated. So if pszData is a string like anything else, it's NULL terminated. If it's a buffer from something, it sould not be called a string. You should track down the origins of the string and go from there.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Those functions are safe as you are allowed to present a character count to the API. The unsafe ones are the ones that do not allow this, such as gets(), strcpy(), sprintf().
And I would never reccomend using C++ on even my worst enemy! 
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Toby Opferman wrote:
Those functions are safe as you are allowed to present a character count to the API. The unsafe ones are the ones that do not allow this, such as gets(), strcpy(), sprintf().
They are unsafe in the sense that you have to manage the amount of data that you use. The "safe" classes however do this for you.
Toby Opferman wrote:
And I would never reccomend using C++ on even my worst enemy!
Why is that? 
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I would hope that a programmer is capabile of managing program resources!
Well, I'm not a fan of C++ for many reasons; but I don't want this to get into a religious battle
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Toby Opferman wrote:
I would hope that a programmer is capabile of managing program resources!
I can only say that practice makes perfect. And with C++, some people need a lot of practice... 
Toby Opferman wrote:
Well, I'm not a fan of C++ for many reasons; but I don't want this to get into a religious battle
I read some of your tutorials on debugging and I think that if you are a fan of something, it must be assembler. And C++ makes assembler just a little bit harder to understand doesn't it?
You are spending some time here on the VC++ forum and if you are not a fan of C++, what are you a fan of I wonder?
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I am a fan of assembler and of C programming. C++ doesn't make assembler harder to read, I debug C++ all the time. An extra parameter on the stack or being passed into a function via the ECX register doesn't make the code harder to read than C at that level (It's actually harder to read at the source level!) I have many other issues with it that would take a while to explain, mostly with maintainability and other semantecs.
Well, Visual C++ is just a compiler and it does support C programming as well. Also, I am a fan of programming, so language independent I can talk about Windows or programming in general.
I more consider myself a mid-level programmer (jack of all trades, master of none ) because I do have some interaction with the hardware or just above it in the kernel, but I also have some interaction with applications but again not a lot. I'm usually somewhere inbetween the application and the hardware. So I don't do a lot of GUI programming but I know some of it, and I don't do a lot of direct hardware access but I know some of it, but I understand a lot of what glues them together so to speak. I work all over the place, graphics drivers, network applications, services, user mode, kernel mode, etc. etc.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
The hardware explains why you do a lot of assembler and C. I had some courses on embedded systems in college and C++ is just not going to work on the small ones.
I want to know something about everything and master C++, server oriented architectures and application design. I consider myself now a little under average programmer, so I've got a long road ahead.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
In the DOS days assembly was more nessecary if you wanted to do anything (The DOS API equivlent of Window's WIN32 API was software interrupts!) but with Windows and abstractions it's rarely ever needed except for possibly specialized optimization code and even that is not so common.
Even a lot of embedded systems these days have higher level language compilers! There are some small CPUs which have limited RAM and possibly need optimized for size but even embedded systems you see a trend away from direct assembly.
Console game systems used to be in all assembly. Nintendo, Sega Saturn, etc. all the old consoles didn't have high level langauges and actually that was one of the downfalls of the Sega Saturn. I heard that the assembly language for it was very complicated. Newer console platforms though have high level language SDKs (They just cost like 25k).
I have always liked assembly language so I still use it in pet projects sometimes. I also only debug applications at the assembly level and never at the source level. I have some radical ideas about debugging such as you don't need to understand what the program is doing to figure out what the problem is. That being the case you can ignore most of the code and look for common patterns of problems. It's harder to look for those patterns if you see a higher layer complex overview of what's going on. It makes it harder to abstract since every line of code is really a complex operation that you must understand. A line of assembly is a very simplistic logic operation and doesn't need to be understood at a higher level of thinking.
A lot of bugs also need to be looked at on the lower level to be caught. So if you are already debugging at that level you get everything since we've abstracted out the need for understanding high level logic. An example would be a function call with invalid calling convention, messes up the stack pointer. Harder to see if you're looking at source code and also doesn't require you to understand anything the program is doing!
It works under the same principal that if you wanted to crack a third party application, you don't need to know what that application's logic is you just need to find that one instruction that determines the path divergence to either fail or continue execution of the application.
So, that's mostly why my debug tutorials are in assembly language
I wouldn't say you're below average. For example, you had the right idea on that keyboard input thread yesterday about keeping track of the key presses, other people seemed to miss that on the thread. There's a lot to learn and what you know today is usually only good for a few years before it's replaced by something new that you have to re-learn! Creating an ISR to keep track of key presses is definately not used by application programs anymore for example, yet I did that 10 years ago.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Hello,
I just got back from my holliday, so this post may be a little late, but I didn't have internet access at my location  .
I agree that some problems are more easy to detect in a lower level context than others, but there is also a plethora of other problems that are more easy to detect with a high level view. An example of this is the infamous corner case bug, where you loop once too many or once to few. This is more easy to detect if you understand the context. (It's actually the comment that does the trick, but the high level view is less cluttered..)
I'll stop with my arguments, since I think that we both don't want to get involved in an endless debate about peoples passion for things.
Toby Opferman wrote:
It works under the same principal that if you wanted to crack a third party application, you don't need to know what that application's logic is you just need to find that one instruction that determines the path divergence to either fail or continue execution of the application.
It's mandatory to think that way, since you'll never have the source code available. If you have it, there would be no need to crack it..
Toby Opferman wrote:
I wouldn't say you're below average. For example, you had the right idea on that keyboard input thread yesterd
ay about keeping track of the key presses, other people seemed to miss that on the thread.
Thank you, I feel flattered
Toby Opferman wrote:
There's a lot to learn and what you know today is usually only good for a few years before it's replaced by something new that you have to re-learn! Creating an ISR to keep track of key presses is definately not used by application programs anymore for example, yet I did that 10 years ago.
The coding techniques are generally old at the moment that you are using them. They are new at the moment you learn them. The key is to learn an abstract technique, algorithm, etc. that you can implement in different languages, so that you don't have to relearn everything. The only thing to relearn is the technique to implement the idea.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
Bob Stanneveld wrote:
An example of this is the infamous corner case bug, where you loop once too many or once to few. This is more easy to detect if you understand the context. (It's actually the comment that does the trick, but the high level view is less cluttered..)
I've never had to go to source level debugging and I fix 10x as many bugs as anyone else. I was so good they only had be debugging everyone's code! So, I had to get momentum to move onto a different team (I work in research now) in order to avoid having to fix everyone's code for life. After years of debugging user mode traps, blue screens, etc. I've actually found patterns in debugging and use this to find the answer to the next bugs. I should write a book on "Debugging Patterns", how to recognize what a bug is by it's symptoms and how to fix it. I actually came up with an idea to completely automate debugging and cut down the work by a significant effort (Weeks worth of effort). Most of what you do is routine anyway.
I believe that high level code is more cluttered. Each line is a complex operation and if you attempt to comprehend it you will slow down.
Bob Stanneveld wrote:
I'll stop with my arguments, since I think that we both don't want to get involved in an endless debate about peoples passion for things.
Yes that's true, it becomes like OS wars or editor wars, it never ends!
Bob Stanneveld wrote:
It's mandatory to think that way, since you'll never have the source code available. If you have it, there would be no need to crack it..
I've found that this mentality actually works for everything and finds things faster. The source is always available for referencing if need be.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
STL is an all or nothing proposition though - if you start using it, it triggers some changes in the way that the code is compiled and forces everything to STL. If you are dealing with legacy code this can be a major major - and unnecessary - pain in the neck.
|
|
|
|
|
Hello,
May I suggest that you format your post, so that your for /* or other loop */ statement becomes visible.
May I ask why you use so much ugly C functions and buffers and copy all those things manually? You would write much cleaner code if you utilize all that the STL's streams or MFC's CString and CArray classes have to offer..
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
