DisplayPropertyPage() method brings up locked properties panel

[GoogleCodeExporter]

Hi, Andrew.

I have a problem with DisplayPropertyPage for PS3 web-camera on Windows 
Vista (see more info at http://nuigroup.com/forums/viewthread/2921/).

Capture and settings work fine, when I try to use DisplayPropertyPage() 
method I receive dialog with all controls locked (see attached screenshot 
panel_locked.png). But if I try the same thing in AmCap or any other 
capture app, panel works fine (see panel_unlocked.png).

I'm using the next code to open the panel:
void buttonSetup_Click(object sender, EventArgs e) {
    captureDevice.DisplayPropertyPage(Handle);
}
It doesn't look suspicious for me, but I've tried to place it before 
capture start, after and even in the "new frame" event callback. All 
results were the same - panel was locked.

Can you give me any advice about possible error reasons or ways to fix it?

Thanks in advance.

WBR
Alex

Original issue reported on code.google.com by buryak.a...@gmail.com on 9 Feb 2010 at 9:46

Attachments:

• panel_locked.png
• panel_unlocked.png

[GoogleCodeExporter]

Hello,

It is hard to say for sure without studying the camera and debugging. The 
property 
page shows fine on all cameras I've tested.

The AForge.NET framework does not do any magic with property pages - it just 
uses 
DirectShow API. So you may check framework's sources and debug.

One thing to note. The DisplayPropertyPage() requires one parameter - window 
handle. 
I found that property page may behave differently depending on this parameter 
(if it 
is NULL or handle of form). What is your setting of this parameter?

Original comment by andrew.k...@gmail.com on 11 Feb 2010 at 9:58

[GoogleCodeExporter]

I've tried Zero and valid window handle - it doesn't make any difference.
I'll try to checkout sources and look at the code myself, may be there are some 
problems with camera drivers (they are not official or certified) - and some 
hacks will 
heal them.

Original comment by buryak.a...@gmail.com on 11 Feb 2010 at 10:05

[GoogleCodeExporter]

By the way, forgot to mention. Please, try the next article/code. We use very 
similar approach for working with USB cameras and DirectShow. If that code 
works on 
your side, I may need to investigate it in more details and compare what is the 
difference.

http://www.codeproject.com/KB/directx/directshownet.aspx

Original comment by andrew.k...@gmail.com on 11 Feb 2010 at 10:11

[GoogleCodeExporter]

Yeap, I've seen this article already and written some test code based on it - 
but 
haven't opened camera properties using DirectShow so far. I'll let you know, 
what I've 
found using DS directly.

Original comment by buryak.a...@gmail.com on 11 Feb 2010 at 10:17

[GoogleCodeExporter]

Hi again.

I've researched the problem a little and found that my ps3 webcam allows to 
change it's 
settings only during preview or capture process. And since 
DisplayPropertyPage() method 
recreates camera capture source filter using device moniker string, all 
properties are 
always locked - even after capture start.

So I've shared sourceObject from the VideoCaputreDevice's worker thread, reused 
it in 
the DisplayPropertyPage() method and the problem went away.

WBR,
Alex

Original comment by buryak.a...@gmail.com on 22 Feb 2010 at 2:11

[GoogleCodeExporter]

So, as I understood, you made a change in framework's code. Would it be better 
to 
put the fix into the library, so others will benefit as well? Can you attach a 
diff 
file or modified version?

Original comment by andrew.k...@gmail.com on 22 Feb 2010 at 2:16

[GoogleCodeExporter]

As I see from source, the DisplayPropertyPage() tries to create sourceObject on 
its 
own first and if it fails, then it passes request to the worker thread. Since 
it 
does not fail on your side, your properties are always locked for your camera.

I can suggest another fix, which we may make official:
1) If camera is running, then always pass request to the worker thread;
2) If it is not running, then create own sourceObject.

At the same time I think that driver could be fixed as well. Why not to allow 
changing properties if it is not running?

Original comment by andrew.k...@gmail.com on 22 Feb 2010 at 2:21

[GoogleCodeExporter]

Yeap, sure, see attachment.

I've also exposed capture filter object to be able to set additional settings 
(through 
IAMVideoProcAmp inteface) - I don't know if you allow such stuff in your 
library, but 
exposing capture filter, graph builder and other objects is very handy for 
library 
extending without changing it's source code.

Original comment by buryak.a...@gmail.com on 22 Feb 2010 at 2:24

Attachments:

• aforge_props.patch

[GoogleCodeExporter]

Your fix seems to be much better than mine: mine is incorrect since I've missed 
request 
passing to the worker thread. It would be even better if you add capture 
objects 
exposing into it :)

Driver is buggy, I agree with you. But I have to live with it...

Original comment by buryak.a...@gmail.com on 22 Feb 2010 at 2:28

[GoogleCodeExporter]

OK, will do the suggested fix for 2.1.2 release and expose capture object for 
hackers :)

Original comment by andrew.k...@gmail.com on 22 Feb 2010 at 2:33

• Changed state: Accepted
• Added labels: Milestone-Coming, Priority-Medium, Project-Video, Type-Enhancement

[GoogleCodeExporter]

Thanks :)

Original comment by buryak.a...@gmail.com on 22 Feb 2010 at 2:41

[GoogleCodeExporter]

Changing the way of displaying camera's property property.
1) If VideoCaptureDevice is already running, then request for property page 
displaying is passed to worker thread;
2) Otherwise local temporary source object is created to display property page.

Also exposing source COM object, so users may do some custom configuration of 
camera, etc.

Committed in revision 1186. Will be released in version 2.1.2.

Original comment by andrew.k...@gmail.com on 24 Feb 2010 at 2:48

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by andrew.k...@gmail.com on 10 Mar 2010 at 3:11

• Changed state: Released
• Removed labels: Milestone-Coming