views:

37

answers:

2

I am making a program for handheld PDAs using .net 2.0 compact framework and I have this one part which I'm not proud of and I was hoping for a more elegant solution. Basically the problem is another process using my file in this case its Windows Media Player. I start the process by passing the file location to Process.Start but it seems the process returned is short lived and it is spawning another process? So I tried looking up how to get child process information but had some problems with that (i think no processes were being returned for some reason).

So i currently do this dodgy fix

            string processName = item.Text;
            Process proc = Process.Start(processName, null);
            if (!proc.Start())
                MessageBox.Show("Failed to start process", "Error", MessageBoxButtons.OK, MessageBoxIcon.Hand, MessageBoxDefaultButton.Button1);
            else
            {
                IntPtr newWindow = IntPtr.Zero;
                TimeSpan limit = TimeSpan.FromSeconds(3);
                DateTime start = DateTime.Now;
                DateTime now = start;

                // do while the following:
                // window is not null
                // window is not ourself
                // under 3 seconds
                do
                {
                    newWindow = Win32.GetForegroundWindow();
                    now = DateTime.Now;

                    // taking too long
                    if (now - start > limit)
                        break;
                }
                while (newWindow == IntPtr.Zero || newWindow == this.Handle);

                if (newWindow != IntPtr.Zero && newWindow != this.Handle)
                {
                    uint processID = 0;
                    if (Win32.GetWindowThreadProcessId(newWindow, out processID) != 0)
                    {
                        //const int stringSize = 1024;
                        //StringBuilder sb = new StringBuilder(1024);
                        //Win32.GetWindowText(newWindow, sb, stringSize);
                        m_processes.Add(new ProcessIDWithName(processID, processName));
                    }
                }
            }

As you can see I don't like it and it's unreliable however it does work for now (i needed a solution whether it was bad or not). Why do I need the process ID? Because windows media player is keeping the file open on me and I cannot move/delete the file and therefore I need to kill the process off before I do so. I could do a similar fix with FindWindow but I was thinking more generically as it might not be a media file opened in windows media player.

So basically I would like a better solution if possible!

Also if you wondering why I'm not using a Stopwatch its because it doesn't seem to exist in .net 2.0 cf, also I don't need accuracy to that extent.

+1  A: 

There are loads of questions that pop up here.

  1. Why aren't you executing media player itself instead of shellexecuting the name of the target file?
  2. How do you know when the media is done playing in order to close the file?
  3. Why not use the toolhelp APIs to simply enumerate processes instead of the wacky GetForegroundWindow/GetWindowsThreadProcessId shenanigans?
  4. Why aren't you just using the Media Player ActiveX control instead of this kludge so you'd actually have control over things?

If you intend to make this generic for any file (i.e. not just media, but maybe something like the Word viewer, etc) then you're really out of luck and need to rethink whatever it is you're trying to do (you've not told us what you're trying to achieve, only how you['ve decided to implement it). Applications don't normally close in WinMo, they typically just lose focus of get minimized, so you don't really know when a user is "done" with the file.

The application associated with the file may already be running, so terminating it yourself is an unfriendly thing to do.

The target application really is not designed to give you a callback when it's done with any particular file.

ctacke
1: i wasn't sure if windows media player is always in the same location and is always present with .net 2.0. However if it is the same then yeah this would be an easy method.2: If they have tabbed back to my program in order to move/save the file I warn them that I have to close the process off. 3: I did try this method but for some reason Process32First simply wouldn't work :S Hmm wasn't aware of option number 4, I will try it.
MobileDev
Hmm after looking into option 4 I came across http://social.msdn.microsoft.com/forums/en-US/Vsexpressvb/thread/1acb8695-7df1-458c-b11c-a9ddec6617f9 which looks like I can't use it in a program that's going to be sold? (not your fault as I didn't mention it) Or can I? Licensing is so confusing
MobileDev
That's a desktop question, which isn't pertinent here. The control already resides on every device - it's part of the platform (and it's what the WMP UI uses). You'll simply be using it, not distributing it, and that's fully allowed.
ctacke
1. WMP is always present. The location is always in the \Windows folder.2. What if they bring up another app, like Notes or something?3. You probably need to do a SNAP_NOHEAPS to keep the working set small.
ctacke
Awesome, thanks for you help
MobileDev
A: 

I have no experience with PDA programming, bu you can try to use Job objects (see http://msdn.microsoft.com/en-us/library/ms684847.aspx#job_object_functions). With respect of CreateJobObject you can create a new job. Then you create a suspended process and use AssignProcessToJobObject to assign the new process to th job object. Then you can resume the process.

The advantage of job object is, that you can receive full control of all child processes of the job. You can use TerminateJobObject to terminate all processes. If you create creates an I/O completion port to wait for the end of the direct started process and all it's child processes or monitor of all child processes created and much more. If you need I could post some code examples of links to code examples.

Oleg
That's pretty cool, haven't heard of this before. Handy to know
MobileDev
Unfortunately this is all unsupported in the Compact Framework.
ctacke