yeah, it's rubbish, isn't it. pos_type has an int64 member, but there's no operator overload to get that out -only an int. using System.Beer;

Look at this for guidance: .NET Animation Control[^] .45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001 modified on Monday, April 26, 2010 5:45 PM

Hi Jon, I've been struggling with this one for a while myself and was able to create a scenario where standard out/err data were not handled by dumping a large number of lines from the process right before exiting. I had hoped to be able to switch from asynchronous to synchronous reads once the WaitForExit() returns, and then receive the remaining data with a process.StandardOutput.ReadToEnd(). Unfortunately, this is not possible: "You cannot mix asynchronous and synchronous read operations on the redirected StandardOutput stream. Once the redirected stream of a Process is opened in either asynchronous or synchronous mode, all further read operations on that stream must be in the same mode. If you cancel an asynchronous read operation on StandardOutput and then need to read from the stream again, you must use BeginOutputReadLine to resume asynchronous read operations. Do not follow CancelOutputRead with a call to the synchronous read methods of StandardOutput such as Read, ReadLine, or ReadToEnd." http://msdn.microsoft.com/en-us/library/system.diagnostics.process.canceloutputread.aspx[^] As far as I can tell, this applies to anything you could check (process.StandardOutput.EndOfStream) to see if it were necessary for you to delay cleanup. Unless I'm missing something, which is entirely possible, this seems like a shortcoming of the Process class, because it essentially means that you can't trust the asynchronous interface to provide you with all of your data. Sadly, this seems to leave us with synchronous IO, perhaps a couple extra threads, and the additional synchronization issues that this approach entails (see here[^] for a deadlock condition to watch out for). The only other thing that has worked for me so far, and this is sort of hackish, is to sleep the thread that handles the Exited event (or a return from WaitForExit) to give the DataReceived events time to fire a few more times. I ended up with something like this: RunningProcess.Start(); RunningProcess.BeginOutputReadLine();

In bad mood, today? :-D If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile. This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke [My articles]

Hi Jon, I think I start to get the overall picture now. Here are some thoughts: 1. your buffers are "large", i.e. larger than 85KB, hence allocated on the large-object-heap LOH which never gets compacted, and therefore is subject to fragmentation (unless all objects have the exact same size). In extreme cases fragmentation could mean your app is really using only a few megabytes, yet fails to allocate one more megabyte. Remember: collections such as lists are implemented as arrays, not linked lists, so whenever their count exceeds the next power of two, the array gets reallocated with twice the size, potentially also invading the LOH. 2. The line jpegData = nullptr; probably is not relevant since in the previous line (m_callback->ReturnFrame(jpegData);) you passed the reference to another method, which could store it somehow, and hence keep the array alive. 3. You may have a performance problem: with 5 frames per second, you need an overall throughput of 23MB/sec which you copy once with Marshal.Copy, copy once more with m_outputWriter.Write, and finally the system must dump to the disk in order for the memory to become available again. That could be beyond your system's capabilities; watch Task Manager and/or experiment with less data (smaller frames, or fewer frames per second, maybe skip every second frame). 4. Maybe you could simplify things (and reduce the system load) by passing a ready-made buffer to your native code, rather than have it allocate, fill, copy and deallocate. That is how I have always done image processing in mixed environments. If all the data needs to go through is generate natively and write to a managed file, you could do that with just one array, using it over and over. Hope this helps. If you need more detailed discussions, I'd probably want to see ALL code relevant to allocating, pinning. copying and freeing buffers. :) Luc Pattyn [Forum Guidelines] [My Articles] The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.

Do you know that person? I mean that is certainly not authoritative. I would consider this[^], a more reliable source. Note that he speaks specifically about Vista. I have no idea if previous implementations are identical in this regard.

You could host your control in a parent control. Dock the parent control, and in its resize handler do something like child.size = min( this.width, this.height ) (and recentre it in the parent if desired) Help me! I'm turning into a grapefruit! Buzzwords!

I think that a #pragma pack (1) or #pragma pack (2) declaration before the structure's definition would help. Think so? 36. When you surround an army, leave an outlet free. ... Do not press a desperate foe too hard. SUN-TZU - Art of War

Certainly not automatically, but if it's important enough you could probably engineer a mechanism. Something along these lines comes to mind: public static readonly System.Collections.Generic.HashSet<string> DefinedOptions = new System.Collections.Generic.HashSet<string>() ; ... if DEBUG DefinedOptions.Add ( "DEBUG" ) ; ... endif But that would only work where such statements are valid. On the other hand, I question whether or not using conditional compilation is an appropriate technique for your requirement.

I had a similar issue. I read that you have to create the pointer locally in the function then assign it to a member variable afterwards something like this: IDiscMaster *dscMaster; hResult = CoCreateInstance(CLSID_MSDiscMasterObj, 0, CLSCTX_ALL, IID_IDiscMaster, &dscMaster); if (SUCCEEDED(hResult)) m_pDiscMaster = (IDiscMaster *)dscMaster; else return false; Don't be overcome by evil, but overcome evil with good

Thanks Iain, I should use my eyes more I think. using System.Beer;

Very clever, anyway I suspect he wants the allocation to happen onto the stack. :) If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile. This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke [My articles]

Thanks both, I'd not seen that event before. This has shed a bit more light on the matter: my control is only getting invalidated once. However, OnPaint is called twice - any idea why? using System.Beer;

This article[^] has a LimitToList property that when true will fire a NotInList event. I'm sure it could be adapted to your needs. Another one here[^]. Dave BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Expect everything to be hard and then enjoy the things that come easy. (code-frog)

Press CTRL+SHIFT+B which will re-build the solution and clear the previous errors that you fixed. :) Guy Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)

Have you tried scanning through your source image using an unsafe region? public static bool Extract(Bitmap b) { BitmapData bmData = b.LockBits(new Rectangle(0,0, b.Width, b.Height), ImageLockMode.ReadWrite, PixelFormat.Format24bppRgb); int stride = bmData.Stride; IntPtr scan0 = bmData.Scan0; unsafe { byte *p = (byte*)(void*)scan0; //... Extract the image here } } The code you are using to extract your image portions would obviously go after the byte* p section. Deja View - the feeling that you've seen this post before. My blog | My articles

Vasudevan Deepak K wrote: Chris responded to this in 'Suggestions & Bug Reports' forum that it is because of search engine restrictions. Not in the thread you linked to led mike

Hi Jon This is just a shot in the dark, but have you looked into AttributeProvider[^]? Tech, life, family, faith: Give me a visit. I'm currently blogging about: How could God prove Himself to humanity? The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

I think you should first factor in how complicated is the animation you are trying to execute. Drawing in .NET is not the fastest solution by any means, and usually its as slow as you can get. So your issue might be more related to .NET's drawing performance more than to timing issues...when you demand high frame rates maybe .NET's drawing performance just can't keep up more than the message queue not processing the paint messages (as a matter of fact Invalidate messages skip the application queue and are processed immeadiately, so queueing is not the issue). For any kind of serious animation I would rely on DirectX or OpenGL. NET Drawing namespace does and adequate job when it comes to what it was meant to do, but animation was not in the list IMHO. hope this helps P.D.1: First off, before plunging into new technology, I'd try optimising the code. Even if .NET is slow, it might be enough in your case but maybe your drawing routines are not coded well enough. Make sure you are disposing all disposable objects you "own" in your drawing implementation, you're releasing correctly any unmanaged resources you might be using, etc. Also check if maybe its worthwhile to cache any of objetcs you might be using and that way avoid creating and releasing them on every drawn frame, etc. P.D.2: If you have to rely on some other solution then you dont have to plunge into 100% native code...check out Managed DirectX. -- modified at 4:42 Thursday 5th July, 2007