I'm using DirectShowNet in C#. I've been developing an application to work with webcams to display video, change resolution, and take pictures (either Still pin or from the Capture stream). I've been testing it on 2 different machines (Win 7 64-bit & Win 8 64-bit) and with the internal webcams on those machines (they are laptops) and 2 other webcams, Logitech C920 and Microsoft LifeCam Studio.
One day, the LifeCam Studio stopped working on my Win 8 machine. Using GraphEditPlus, checking the VideoFormats for the Capture pin, I notice that, mysteriously, the RGB24 formats are no longer listed. I have written my application to use only 24-bit color format. Only YUY2 16-bit formats are listed. If I check the same webcam on my Win 7 machine, I see both the YUY2 and the RGB24 formats being listed. Previously, my Win 8 machine did list both of these formats.
The question is, what could cause DirectShow to change the list of VideoFormats for the Capture pin? So far, I've noticed that changing driver versions makes a huge difference for webcams in what pins they support, but I haven't seen them change video formats like this. As far as I know, I have not updated the drivers for the webcam on either machine.
Here are the driver versions for both machines.
LifeCam Studio - Windows 7 - 64-bit
LifeCam Studio - Windows 8 - 64-bit
I figured out how to get the formats back. I went into device manager and found the "Microsoft LifeCam Studio" device. I uninstalled it and hit the checkbox to "Also delete the driver for this device". After that, I refreshed device manager, and when the device was found, it had the name "Microsoft® LifeCam Studio(TM)", but then changed to "Microsoft LifeCam Studio". That made me realize that it automatically updated the driver.
As you notice in my Win 8 screenshot above, the button "Roll Back Driver" is enabled. This means that the driver was updated at some point. I proceeded to roll back the driver, which changed the name back to "Microsoft® LifeCam Studio(TM)".
Now, in GraphEditPlus, the device lists YUY2, MJPG (24-bit), and M420 (12-bit) video formats for the Capture pin. This seems to be what I have had in the past. It works properly with my application now since a 24-bit format is available.
Overall, Microsoft removed some of the DirectShow functionality of the device when they made the Windows 8 driver. This old driver is from 2006 and works fantastically with Windows 8. I'm assuming it is one built into the OS that was carryover from old Windows OS's.
Here is a screenshot of the working driver for others that would like more video formats available for the LifeCam Studio in Windows 8.
LifeCam Studio - Windows 8 - 64-bit - Original Driver
Related
Here is what I have:
Problem: Trying to connect two different 64-bit applications:
Microsoft Access 64-bit
QuickBooks Entrprise 21.0 (I'm not sure if it is actually 32-bit or 64-bit)
Using:
Visual Studio 2022 64-bit edition
VB.NET
64-bit version of QBFC15 library for QuickBooks
My thought is that when you use a 64-bit API, it would connect to a 64-bit application. I am most likely incorrect.
When I connect to MS Access in the debug 64-bit mode, it connects fine. The Intuit developer Network says you need to publish applications in the 32-bit mode. I have always used the 32-bit mode for publishing QuickBooks applications because they were 32-bit programs and, well, frankly, 64-bit applications hadn't come out yet (no old person jokes here). Anyway, I was really excited to see that the 64-bit version of a QBFC library came out (QBFC15) and they offer both 32-bit and 64-bit. So I downloaded the 64-bit version (which they recommend on their site https:\\developer.intuit.com>
So I'm thinking, hey, it's a 64-bit SDK! Yeah! So now I have this project that tells me I need to connect a 64-bit Access application to QuickBooks. When I debug, my new application connects just fine to MS Access in the 64-bit mode! Yeah! But the 64-bit Intuit SDK needs to be published in the 32-bit mode!!!! I'm confused. I know that they have put the cart before the horse and I know that they must still be running QuickBooks Enterprise in the 32-bit mode but come on. Putting out the SDK before the commercial product comes out to use it one? (I'm done whining now...got to get it out somehow!).
So how am I to connect my application to both "64-bit" programs when one errors in the 32-bit mode and the other errors in the 64-bit mode?
The programming isn't the issue, but this scenario seems really problematic. Do I tell the customer they need to downgrade their Microsoft Office to the 32-bit mode version? That would be an easy answer I guess, but it sure makes me look bad. Any other suggestions out there that could help me in this would be much appreciated.
If you running desktop edition of QuickBooks, then if you are running a x32 bit version of QuickBooks?
Then that means automation and working with the desktop edition means your software ALL MUST remain x32.
Only in 2022, have they rather recent upgraded and offer a x64 bit verison.
So, you have to check which desktop version of QuickBooks you are running. (most up to rather recent have been x32 bits - for a VERY long time).
So, what determines what QBFC library, what version of Access, and quite much vb.net?
You must continue to force your vb.net projects to run as x86, and NOT use "any" CPU and not use x64.
So, what will determine what all of your code is to run as?
It will be the desktop edition of QB that determines this.
It is of ZERO use to adopt office x64, access x64, or run your vb.net software, and the QBFC sdk and library as x64 bits if QuickBooks remains as x32.
(you using the wrong bit size and architecture here).
so, you have to be 100%, and in fact 200% sure
now, if QBFC is hitting the server database for QuickBooks, then that can be x64 bits but if you using the QB sdk and QBFC? Then that all must remain x32 bits until such time you upgrade the desktop edition of QuickBooks.
So, you have to REALLY but REALLY find out if in fact if you are running x32 QuickBooks for desktop, or x64 for desktop.
The version of QuickBooks and what version you you THEN much choose of QBFC library, vb.net, Access/office then again will have to match the bit size of QuickBooks desktop.
So from everything else from down to Access to vb.net to QBFC then all again much match the version of QuickBooks for desktop you have installed.
Now, if vb.net, Access you use is NOT to interface via the QBFC .dll and SDK? Then you don't care. But, inter process communication based on so called "windows COM objects"? And say upgrading from office x32, and the associated software systems you have? You can't just out of the blue decide to jump to office x64 without say your company and IT department not knowing the difference between x32 bit software, and that of x64 bit software.
Hint: 8 bit Apple II computer has a different architecture then a 16 bit IBM PC. And going from 16 bits to x32 bits? Again, a huge and large jump.
And from x32 bit software to x64 bit software? again a huge jump.
So, while windows can happy run x32 bit software, and it been a x64 bit OS by default for 10+ years?
Well, software packages running as x32 bits, and them interfacing to x64 bit software is a whole different matter. Such software has to remain the same bit size - and you can't have different bit size process on windows such as x32 bit COM objects (ole, COM, ActiveX = same technology stack).
So keep this basic knowledge and hallmark and pillar in our industry - different bit size software systems can't talk to each other via inter-op, or so called COM object automation.
Here's the setup:
I'm trying to connect / deploy to a Motorola Windows Embedded Compact 7 device from VS 2008. The development machine VM is Windows XP (it has tools and SDKs going back to eVC3 on it that will not run on anything newer). It is therefore running ActiveSync as opposed to WMDC. Basic RAPI seems to be working as I can browse the device file system, ect via ActiveSync. This developemnt system works successfully with dozens of other devices, but this might be the first CE 7 device. And again, the error message was simply "The bootstrap could not be loaded".
I'd appreciate any tips on getting a successful connection to the CE 7 device working.
I had exactly the same problem. The solution for me was to install the SDK for the pda. Mine was MC32N0.
You can find the sdk here
I have a program written in vb.net and compiled in Visual Studion 2005 for Windows CE 5.0. It works fine on a Windows CE device. I am trying to run it on another device which has Windows WM. It will load, but doesn't respond to any commands. My understanding is that I need to recompile it with different libraries (per Motorolla - the device manufacturer) that are compatible with Windows CM. My problem is that I am new to the mobile environment and don't know how to find what I need and set up the environment. Can anyone point me in the right direction? Thank you
I want to create a Virtual Webcam for Windows 8 and I have two choices: DirectShow or Microsoft Media Foundation. After some looking around I found out that DirectShow has much more exmples and even here on Stackoverflow it gets recommended over MMF. So I want to get started with some examples and for this I need strmbase.dll, which I need to compile myself from the BaseClass sample of the DirectShow samples.
But getting the samples seems freaking impossible on Windows 8. According to this page it should be a part of Windows 8 SDK, but this is fully installed and no folder by the name of baseclass exists anywhere on my computer. It is also part of Windows 7 sdk, but this refuses to install. I also read that it should be part of DirectX SDK, but this has, according to MS, been included into Windows 8 SDK, and thus the DirectX SDK refuses to install.
How do I install the DirectShow samples on Windows 8?
I got them, but it was through a dirty trick:
Download the Win 7 SDK ISO, extract it, go into the WinSDKSamples_amd64 folder and run the installer. All Win 7 SDK samples will now be installed to C:\Program Files\Microsoft SDKs\Windows\v7.1.
This might be a stupid question, but I couldn't find the answer anywhere. Does the Microsoft Surface SDK 2.0 only work with Microsoft Surface products, or can I use it with other touchscreens? I really just like the way the SurfaceTextBox control works (popping up a onscreen keyboard when clicked) and was wondering if I could use it in a program I'm making (which uses a Elo touchscreen monitor, not multi-touch).
Edit
Thanks for the responses. I downloaded and installed the SDK 2.0 and tried to run the sample apps that are included. They don't seem to respond to my finger touches but do work if I the included simulator. I'm running this on windows 7. Any reason why it doesn't seem to work on my touch screen?
Yes, you can use it with any touchscreen. It works on WinRT/Windows 8 as well as Windows 7. I have used it for surface, tablet (both WinRT as Win7 tablets) and touch-enabled desktop applications and it works absolutely fine.
The installer requires you to install Visual Studio 2010, but if you import the DLL's manually in the toolbox, you can also use it in both Visual Studio 2012 and 2013 preview. This is an answer on a different question, answered by one of my colleagues on how to use the Surface SDK 2.0 with Visual Studio 2012
It's a great toolkit to support touch-enabled WPF applications and can also be use as a replacement for the WinRT Metro UI, in case you cannot use that toolkit (e.g. when you interface with USB, or need desktop services).
Update:
Since you update your question to how to get the Elo Touchscreen to work with native Windows 7 touch, I suggest you download and install the latest drivers. Your touchscreen will only work with WPF touch / Surface SDK if native Windows touches are supported. Installing the latest drivers should do the job. Don't forget that you might have to enable and configure touch input in the Control Panel (Pen and Touch).
I noticed that in some cases touches are not working when you use a SurfaceWindow. Use a normal WPF Window and all the SurfaceControls should work. Thus if you want to use the sample applications on Windows 8 you need to replace SurfaceWindow with Window and remove the unavailable EventHandlers.
From Microsoft's web page:
http://msdn.microsoft.com/en-us/library/ff727815.aspx
The Microsoft Surface 2.0 SDK provides the managed APIs and the tools you need to develop Surface applications. Applications that are built using the Surface SDK can run on devices made for Surface 2.0, and on Windows 7 computers.
See also:
http://social.msdn.microsoft.com/Forums/en-US/b61c2eda-410e-4c65-9a60-b9e0a8ea11b2/windows-surface-sdk-setup-and-development-on-the-tablet-windows-rt
Surface SDK 2.0 is not dedicated to Windows RT for a Surface Tablet. it
is innitially dedicated on PIxelSense SUR40 unit or if you are bulding
windows 8 application with Pro version.
There has been a lot of confusion since the arrival of the Surface
tablet. The product name Surface before what the name of the Microsoft
Table touch table and the Samsung SUR40 device.
And that SDK was only working on those device. Then MS has release a
version (Surface SDK 2.0) which can be use also fro traditionnal Touch
PC application starting from Win 7.
Finally:
http://www.infoq.com/news/2011/07/Surface-2
With Microsoft Surface SDK 2.0 one can write applications for both
Surface and Windows Touch devices.
Surface 2.0 is not compatible with Surface 1.0 devices, and so far the
only compatible device is Samsung SUR40 [as of July 2011]...
These details have been public for a while, but Microsoft has just
made available Surface SDK 2.0. One of its key features is the ability
to target Windows Touch devices, that is Windows 7 computers with
touch input, so this SDK serves a much larger spectrum of devices. If
there are very few Surface devices out-there, there are lots of
Windows Touch ones, and their number is poised to grow.
Windows Touch applications are very similar to Surface ones, except
that the later supports full HD resolution and a multitude of touch
related inputs, such as finger and blob recognition, tagged objects,
tilted display, rotated display, etc.
At windows 8 you just need do that:
Run Microsoft Surface Input Simulater
Go to Device Manager
In Human Interface Devices, right click over Touchscreen compatible with HID and click activate.
Just that. ;)