Trying to capture video from my webcam device using Visual Studio 2012 with C++. My goal is to be able to view live feed from a USB camera for some ROV projects. I found a website (http://www.codeproject.com/Articles/559437/Capturing-video-from-web-camera-on-Windows-and) that has a Visual Studio solution. However, when I compile, I get an error that reads: "Unable to start program. VideoInputVS2012\videoInput\Debug\videoInput.lib". I tried including the library in the solution, but it didn't seem to work. Any suggestions?
What type of project are you building? If it is a static library you will not be able to run it. You may want to check your Project settings for the output target type.
-----------------------Updated Edit--------------------------------------------------
The codeproject code you downloaded has a project that generaters a static .lib file.
You will need to create a another project that references this .lib file in order to use it.
There are actually two downloads that show the .lib class being used.
TestVideoInputVS2012x86.zip - uses the OpenCV framework for presenting live video
The second example is based on the SimpleCapture example from the
Windows SDK (this code -SimpleCaptureVS2012x86.zip, application -
SimpleCaptureVS2012x86-exe.zip).
Here is also an example provided of how to call the videoInput.lib static class:
For using this library it is enough to include videoInput.h and videoInput .lib in your project. This class is made as a singleton which makes managing of resources easy.
//TestvideoInput.cpp
#include "stdafx.h"
#include "videoInput.h"
#pragma comment(lib,"videoInput.lib")
...
The codeproject being referenced and discussed was created by Evgeny Pereguda
Related
I have created a library and i get a folder called Stubs
in this folder i get a bunch of files, how can i build it and used as an interrupt on the C# code?
There is a blog post with detailed explanations on how to use Interop in .NET nanoFramework. Please see here.
Look at section "Adding the Interop library to a nanoCLR image". You have to add those files and the respective CMakelists.txt to the project folder and build a new image that includes them.
I've dynamically linked libhunspell.dll (HunSpell) to my application. It works, but there is a dumb problem which I don't know why it happens.
Even before I use LoadLibrary("path\\to\\libhunspell.dll"); to load it and use it, on the start of the application it attempts to load the library by itself. If I place the libhunspell.dll into the path where my main executable resides, it can load it, otherwise it reports an error, immediately after starting the application - This application has failed to start because LIBHUNSPELL.DLL was not found. Re-installing the application may fix this problem. and the application doesn't start.
I would understand if the LoadLibrary would use invalid path but this happens as soon as the executable runs, even before the first statement in WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int) executes (I've tried to place a breakpoint and it doesn't even reach it, so this happens before).
So, as a result, I must place libhunspell.dll in the same folder as my application executable, and not in the path I want.
This is probably easy to fix although I don't what to look for.
So the question is - how do I avoid it loading it immediately and have it wait until I use LoadLibrary call?
Here is how I linked if it can help:
1) compiled libhunspell.dll in Visual Studio 2015 (I used /MT option to link it statically so it doesn't have VC++ Redistributable as a dependency).
2) created import library (libhunspell.lib) using implib.exe -a -c -f libhunspell.lib libhunspell.dll
3) linked that to the source .cpp unit which is using it using #pragma comment(lib, "libhunspell.lib") (it is RAD Studio 2010 so the .lib is required unlike newer versions).
4) later in the same .cpp used LoadLibrary to load this library and used it.
By linking in the import stubs (libhunspell.lib) the OS will load the DLL for you as it is now a static dependency.
One approach would be specify the library as a delayload dependency: /DELAYLOAD:libhunspell.lib via the linker options. You can then call LoadLibrary on the DLL.
The only other option is to stop including the .lib in the linker step, making it truly a dynamic dependency.
I assume you did Add to project a *.lib file for your DLL. That is a kind of "static" linkage done in the App initialization (prior to your forms are created). So it has two disadvantages.
You DLL must be in the same path as the Apps EXE file
Sometimes DLL file name is locked (can not be changed)
The advantage is that you do not need to do any coding for the DLL loading as the VCL do it for you ... so your app should not contain the LoadLibrary,GetProcAddress calls you just include the *.h file with propper import declarations ...
For dynamic linkage you need to remove the *.lib from your project and use WinAPI LoadLibrary + GetProcAddress for loading your DLL as josh poley suggested. Here an example:
Builder C++ calling VC++ class
Beware there was/(is?) a bug in the GetProcAddress preventing from loading all the functions from your DLL in some cases. Especially if the DLL has old legacy mangling of names the count of functions is high and the DLL was created on compiler incompatible with the mangling in question.
My team and I are currently working on a project that involve a ST board (the STM32L072CZYxx) to create a bidirectionnal GSM-LoRa gateway.
As we've already succeeded in implementing the GSM side of the gateway, we are currently working on the LoRa part of the project. To achieve this, we're trying to use the I-CUBE-LRWAN, but can't figure out how to add this library to the STM32CubeMX project. It seems like, this library can't be added to our project through STM32CubeMX. The only solution we have is to add manually the library to the project but we can't figure out how to do it. We imported the middlewares we needed into the project however, the IDE we use (Atollic TRUEStudio or SW4STM32) detects a lot of errors in the project and we really don't understand why (the source for middlewares were coded by ST, so basically no errors).
I'm guessing that is Murata LoRa Module. First time I tried that I was not able to add library to existing project.
There is some error that occur because of length of path names -on windows- you can copy and paste the project to shorten the path name and then i was able to program the module to use it as AT command slave.
And also there is 3 target project on that project file you need to select the proper target for it.
I'm working to create an iOS static library that I wish to sell. I've walked through the steps for the initial builds and have generated the .a/.h output.
When I include these files in a separate project, I don't see any way to browse the contents on the .a file.
HOWEVER, when a line of code in my library crashes the app (like I said, it's still in development), the debugger shows the entire class (.m) file to me. What's up with this?
I don't really understand what all goes into static libraries, and I'm not sure I compiled that version for both simulator and device. Could that have something to do with it? If so, could someone explain why?
Thanks!!!
Don't worry, your source code is not included in the archive (.a) file.
Xcode is smart enough to find the source code file on your computer, based on the debugging information embedded in the file. If you build the library using the "Release" configuration (or otherwise modify the build settings so that debugging symbols are stripped) and don't have the source anywhere on the machine, a developer will have to resort to their knowledge of x86 or ARM assembly to figure out how your code works.
By the way:
Since a lot of Objective-C is handled at runtime, a lot of class names and selector names will be visible in your library. That's just how it works. You could try to obfuscate it, but I think your time is better spent writing more useful code to sell.
If you want to give people a static library for iOS development, you'll want to build versions for the iOS Simulator (x86) and the iOS Device (arm) and then use lipo to combine them into a single fat static library. Search around for "lipo xcode fat static library" for different ways to do this. Some solutions are more convoluted than others.
I had the same issue. #benzado is right about what he has mentioned. But I had to strip debugging symbols to solve the issue. To do so, I had to change Build Settings of project library before build as mentioned below.
Select your Target and go to Build Settings. Set
' Strip Debug Symbols During Copy ' to YES
' Debug Information Format ' to 'DWARF with dSYM File'
' Generate Debug Symbols ' to 'NO'
' Symbols Hidden by Default ' to 'YES'
To see what are these for, refer Apple Build Setting Reference
And build the library using the "Release" configuration. This worked for me.
If you have a project for static library with all .m files on your computer then every copy of this library (.a file) will be symbolicated with its .m file while debugging in xCode.
xCode doesn't search for appropriate .m file through all your disk. It knows the place of original project. So if you distribute only library it fully hides your initial code.
To make sure you can copy your library in some new project then clear .m file in library project.
From this moment any attempt to debug methods of library will give empty file on screen.
I have a solution in VS 2008 that creates a DLL. I then use that DLL in another application. If I go in to the DLL projects property pages and change the following configuration for a DEBUG build then the built dll no long provides the desired functionality. If I change it back and rebuild the DLL, then the DLL does provide the correct functionality:
Property Pages => Configuration Properties => C/C++ => Code Generation => Runtime Library
If set to "Multi-threaded Debug DLL (/MDd)"
then everything works as it should. I get the correct functionality from the DLL
If set to "Multi-threaded DLL (/MD)" then the DLL does not function properly...no runtime errors or anything, it just doesn't work (The DLL is supposed to plot some lines on a map but does not in this mode).
So the question is, why does using the /MDd flag result in correction functionality of the underlying code, while /MD results in incorrect functionality?
A little background...somebody else developed the DLL in C++ and I am using this DLL in a VB.net application.
All DLL's/debug code generation must match across everything that uses them. There may be another referenced library or object or dll or some code in there that is built using the wrong options; or specific options for an individual element that override the global project options.
The only way of figuring it out is to meticulously check all of the options for each file, checking the included and referenced libraries (.lib and .dll) and object files. Check the linker options too.
The reason why it doesn't work is probably because the debug version adds extra guard blocks around memory to allow detection of errors.
I had similar problems. My application which "used" a 3rd party DLL crashed when its runtime library was set to "Multi-threaded DLL (/MD)", but worked when its runtime library was set to "Multi-threaded Debug DLL (/MDd)".
It has something to do with passing std::strings and std::lists across the DLL interface.
Our guess was the low level definition of these types was somehow different in the two runtime libraries.
We solved our related problems using this rule...
The DLL and the DLL user must be build using the exact same runtime library.
The main difference between the two options is in the libraries that your code will be linked at later. for the debug version for example this will include LIBCMTD.LIB and a few others. if your library is going to be built as debug the you should always link with MDd. failing to do so will result in lots of unresolved external linker errors at best. and sometimes the code compiles normally but crashes at runtime. if this happens in vb.net then a catch can easily hide the error. I guess you should make sure you build setting is correct. for more detailed information check this.