[RESOLVED] Hide waitcursor when saving image to file

I have a form that has to be run hidden only - there is a save operation that is done for every n seconds and the user cannot see any flicker or wait cursor during this time.

For every n secs, it captures the current window as image and saves it to disk via a Bitmap CopyFromScreen() logic. However, a waitcursor appears everytime the save is done to the disk which can be upto 5 times an hour.

so, bmp.save(filename,Imageformat.jpeg) produces a waitcursor. I understand it happens due to the I\O op done here. But I dont want the user to see a process going on in the background - the form where this happens is hidden and is not visible in the taskbar at all, yet the waitcursor appears - coz its a system disk operation.

How to prevent the waitcursor not being shown or is there any way the image can be saved without the user interrupted by the waitcursor every now and then?

Any help appreciated. Thanks.

Pass the bitmap from the CopyFromScreen() method into a second thread and save it there. Check out QueueUserWorkItem().

Quote:

---

Originally Posted by Arjay

Copy the bitmap over to a second thread and save it there.

---

was just about to try that - but the waitcursor appears across the system, not just in the application screen - when you hover over it. I believe the user would see it regardless of it in another thread - let me try and get back to you anyway.

Quote:

---

Originally Posted by CM2013

was just about to try that - but the waitcursor appears across the system, not just in the application screen - when you hover over it. I believe the user would see it regardless of it in another thread - let me try and get back to you anyway.

---

It appears in the app because you are hanging the UI thread while copying. I doubt a waitcursor will show up when the save is in another thread.

It did not work - coz its not that the wait cursor appears on the UI screen - its across the system. The system's cursor turns briefly to a waitcursor and then comes back to default due to the I\O op. This happens in a new thread as well using a parametrized Threadstart and passing the function name that has the bmp to the thread.

Quote:

---

Originally Posted by CM2013

It did not work - coz its not that the wait cursor appears on the UI screen - its across the system. The system's cursor turns briefly to a waitcursor and then comes back to default due to the I\O op. This happens in a new thread as well using a parametrized Threadstart and passing the function name that has the bmp to the thread.

---

I'm not seeing that behavior when I create a Bitmap and call its .Save method. I/O generally doesn't cause this behavior (because if it did, you'd see a wait cursor when you copied large files). Perhaps the wait cursor you are seeing isn't because of the Save but from something else? Try saving in a test program (like I did) and you won't see the wait cursor.

you were right - the i\o copy didnt make the waitcursor - I had this lets say, Save2() functionin a timer tick. Even for a 10 sec tick, it shows the wait cursor. Do you know why or how it can be avoided pls?

maybe I'll put the timer in another thread then?

even timer in a new thread didnt help - I'll try BackgroundWorker thread.

a backgroundworker thread to do a non-async op does not work either. Timer is useless if its going to show waitcursor every few minutes even though the I\O op doesn't require that.

Have you isolated whether its' the save operation (which I don't think it is)?

More likely it's the CopyFromScreen operation. Can you comment out the Save and see if the waitcursor still appears?

Can you try another approach to grab the screen contents rather than CopyFromScreen()?

yes, the save() is isolated. Commenting that out does not show the waitcursor. So, assigning a bitmap from CopyFromScreen() to a picturebox control does not cause any waitcursor, but saving the picturebox1.Image.Save() does cause the waitcursor to show.

Rather than calling .Image.Save(), extract the stream out of .Image, send it to a second thread, then recreate it into a new Image and call save from there. I think the Image being tied to the picturebox is throwing the wait cursor.

saving the bmp to memory stream like bmp.save(memst) and then passing the memst object to another thread wherein the memst is copied to a FileStream object produces the same result - it flickers showing a waitcursor. :(

Maybe its closer related to the OS and my hardware config as it does not happen in your system?
am running a decent config - win 7, 1 GB RAM and 1.73 Ghz CPU.

a FILESTREAM WRITE COPYING THE MEMORY STREAM TO A BUFFER produces the same result.

Sorry about the caps.

Try creating a test app, zip the complete solution and post it here.

Attachment 32601

The attached project is simple - set a timer, start the timer button and watch it save in a folder. Try 10 seconds or more please. Also, you can edit the code for the 'dir' variable to set a local directory you want.

I can try AsyncCallback() for now. Another user on MSDN forum posted a solution for it in a WPF setting - he simply uses asynctask and awai - not sure how it cna be implemented in WindowsForm. This is what he says:

http://social.msdn.microsoft.com/For...=csharpgeneral

Quote:

---

Originally Posted by CM2013

Another user on MSDN forum posted a solution for it in a WPF setting - he simply uses asynctask and awai - not sure how it cna be implemented in WindowsForm.

---

As the other guy said, async is a .Net feature, not a Windows Form feature. Just use .Net 4.0 or above.

The .NET version is 4.5 - tried it in WPF and Form - didnt work - had errors. Iam thinking Action<Object> and creatign a new Task.factory.Startnew should work - but that didnt pan out as well. How can Action<Image> saveimg (Image img) function be used?

Completed it like this:

Task t2 = Task.Factory.StartNew(() =>
{
pictureBox1.Image.Save(fn, ImageFormat.Jpeg);
});

t2.wait() //to block the main thread letting this finish

NO. It did NOT resolve the issue for longer times - like a timer of 1 minute. Not even ASYNC works as it runs on the CPU anyway at the syetm-level.async Task does NOT work really.

Mod, mark it as Unresolved as it isn't.