My application is up and running at full speed. Thanks again, Ilan

Once again, thanks for your help. When I ran things under the debugger, I looked at the directories, saw what files there were, saw how they were created, and I was happy that everything was working. When I let it go, I realized I still had a problem. Your help has been extremely useful. Ilan

I've run into a new problem. ShellExecute launches the program and then returns. I need the results of the program so I need to know when the program is finished. It turns out that system() returns only after the program has finished. Is there any obvious way to know the program has finished? Thanks, Ilan

Nave, I just wanted to let you know what a joy the ShellExecute is. I used c:\a b c\ as the default directory and I separated out the command from the parameters. In system it was all one big mess and the exe file got confused. With ShellExecute everything works like a charm. Thanks again for your generous help, Ilan

Nave, thanks for all your kind help. It has been very useful indeed! Apparently it is a combination of system together with that particular exe I'm using. The exe has to parse the command line to get the input and output files and it has a subtle bug. All my experiments of using notepad worked fine. (I copied notepad into a b c for test purposes.) On the other hand that exe fails using the system command. If I take the buffer which I pass to system and copy it into a command box, all works fine! I think it is time to use ShellExecute as you originally suggested. The experiments have been fun, but the system command with that exe doing parsing don't seem to work. Ilan

It is an exe file which I received to decompress JPEG Dicom files. I'm sure the problem exists for any command which has parameters on the command line. Again it worked just fine until I tried using a path which included "Program Files". Maybe I should try to run notepad with an input file and see if notepad opens the file. I'll try something like ""c:\a b c\notepad" myfile.txt" First I'll try c:\ilan\notepad myfile.txt, since that should work.

Really? Unbelievable! Maybe the problem is that I'm giving an input and an output filename as parameters? If I do it at a command prompt with quotes, all works perfectly OK. If I do it by using system - on exactly the same string, it does nothing. I tried even moving the quotes to the directory with spaces, but it made no difference. c:"a b c"\dcmdjpeg C:\ic2006\dicom\kressel\study1\ctseries\view0405.dcm c:"a b c"\jpegUncompress.dcm I made a directory "a b c" just for test purposes. In this case I forgot the backslash "c:\a b c", but that isn't the problem. Could you do me a favor and see if system works if you pass parameters? For me it works fine so long as I don't both spaces in the path and spaces to separate parameters. Thanks, Ilan

Thanks again Nave. No I didn't and that is exactly the answer I am looking for. I knew there was something which replaces system, but I couldn't remember what it was. I will try ShellExecute immediately. Ilan

Thanks for the answer Nave. That is exactly what I tried. To my disappointment, it doesn't work for the system command. Apparently the system command is too old?

This has got to be an easy question, but I can't find a place to start. I want to give a command inside my code. The problem is when the path has a space in it like c:\Program Files\... I wanted to use system(buff) where buff = "c:\Program Files\myDir\myProg" This works fine for paths without spaces, but there is something to replace it for paths with spaces. I just can't remember what it is. Thanks, Ilan

Thank you very much. That is my missing link.

So I don't use FindWindow(). If I would use something better, how could I give focus?

Today in the second program I use a mutex to detect the second instance and kill it. The reply below this one is correct in the sense that I want to give it focus. However I don't know what it means to give focus to a totally different process.

I don't want to send any information between the programs, just give the second program control - like you do when you click on the task bar.

In my application I have a button to start another application (a different program altogether). I use the old WinExec which works fine. The problem is that I don't want multiple instances of the other application. (For example the user clicks on the first application and again it gets control and then he clicks on the button again.) What I would like to do is transfer control to that program if it is running and not start and new instance of it. (This would be the equivalent of clicking on its icon on the bar on the bottom of the screen.) Is there a way to do such a thing? Thanks, Ilan

Thanks to all for the replies. It is nice to receive so many replies. They were useful and the problem is now solved (using a mutex). Ilan

I have a program where sometimes I need a button to launch a different program. I used WinExec() for the job, even though I get the impression that it is out of date and I should be using something else. So, first of all, if there is a better choice, please let me know. WinExec() does the job nicely since it is so simple. Here is my real question. The second application takes a lot of memory and I don't want to launch multiple instances of it. So I would like something to check to see if it is running. If not, launch it. If yes, jump to the instance which is running. Is there an easy way to do this? Thanks, Ilan

I wanted to try Visual Studio Express as a debugging medium. I brought over a project and tried to compile it. It complained that it couldn't find afxwin.h which is all the MFC core stuff. I looked around and couldn't find it either on that computer. My question is: can I add something to make the express edition support MFC? Thanks, Ilan

James thanks, This turns out to be messy. I couldn't figure out how to put the command (with full path?) once and for all into the command line. Up would come a message box and if I have to enter full path each time, I might just as well attach to a process. Up until now I've always used c++ and it was simple to put the break point in the calling routine and then just step into the routine under the dll. With java I first thought maybe I could use a get character from keyboard to trap it and then attach to the process, but then I remembered the old int 3, which may do the job for me. (In any case I have to recompile the dll with a one line change when I want to debug it.) Int 3 is now __debugbreak(), but it does the job. Up comes a message box telling me my program has crashed and if I want to send a report to Microsoft? There is a debug button which allows me to attach a debugger, which is what I wanted to do in the first place. In short, this looks like the easiest solution. You asked me to reply if your suggestion helped. I couldn't reply so long as I didn't have a solution. You should be aware that even your offer to help is of great value. It gives additional thought for consideration which is always of great value when you are stuck with only your own way of thinking. So, if you helped? I think the answer is always YES! Thanks. Ilan

How does one normally debug a dll? I agree one has to start the process which calls the dll. In my case the process is the JVM. "java osnat.HelloWorld" starts this process under the command box. I assume there should be some way to start it under the Visual Studio debug mode? If I really have no other choice, then I could try to attach to a process that is in some loop, but I hope there is a more direct method. Ilan