Command prompt in debug mode for Eclipse? (OpenCV + Eclipse + Win7) - windows

I am a beginner for Eclipse. I now have Eclipse C/C++ IDE with OpenCV library running on Windows 7. So far it works after spending hours trying to get it running. But then I realize that Eclipse does not pop up a command prompt as VS2010 does while debugging. And moreover Eclipse's debug mode is just stuck in there and refuse to output anything. But if the code doesn't involve the OpenCV things it works again.
Below is the code I use for testing. It captures images from webcam and output it to the screen. The infinite loop (until you press 'q') makes sure it constantly grabs new inputs from the camera.
I browsed through the workspace and run the exe just compiled and it worked flawlessly. So I don't think there's anything wrong in the code (it's an example code anyway
In brief, can I just pop up a command prompt window in debug mode? And why is Eclipse console stuck when the code involves some OpenCV functions?
#include <stdio.h>
#include <stdlib.h>
#include <tchar.h>
#include <cv.h>
#include <cxcore.h>
#include <highgui.h>
#include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
CvCapture *capture = 0;
IplImage *frame = 0;
int key = 0;
/* initialize camera */
capture = cvCaptureFromCAM( 0 );
/* always check */
if ( !capture ) {
printf("Cannot open initialize webcam!\n");
return 1;
}
/* create a window for the video */
cvNamedWindow( "result", CV_WINDOW_AUTOSIZE );
while( key != 'q' ) {
/* get a frame */
frame = cvQueryFrame( capture );
/* always check */
if( !frame ) break;
/* display current frame */
cvShowImage( "result", frame );
/* exit if user press 'q' */
key = cvWaitKey( 1 );
}
/* free memory */
cvDestroyWindow( "result" );
cvReleaseCapture( &capture );
return 0;
}

This is because you have already set the windows 7 system variable PATH to your MinGw/bin and compiled opencv bin directories. So when you run the program from your folder your system automatically take the required binaries from its PATH and the program runs correctly.
I don't know why but Eclipse does not take it directly from the system environment PATH variable. So we have to set it ourself.
go to Preferences > C/C++ (Expand it) > Environment > Add:
"Name:PATH"
"Value:C:\MinGW\bin;C:\opencv_MinGW\bin"
where opencv_MinGW is the folder where I compiled my opencv

Related

Cannot use system("cls"); in Xcode in mac

I tried to execute
system (cls):
in Xcode in mac, but it doesn't work.
Two problems.
1 - You didn't use quotes.
2 - The command on OS X is clear, not cls.
system("clear");
Instead of doing that, a better way is to add these #includes and also this ClearScreen function which sends the terminal a clear command directly, instead of starting a separate process. Cribbed from http://www.cplusplus.com/articles/4z18T05o/#POSIX
#include <unistd.h>
#include <term.h>
void ClearScreen()
{
if (!cur_term)
{
int result;
setupterm( NULL, STDOUT_FILENO, &result );
if (result <= 0) return;
}
putp( tigetstr( "clear" ) );
}

libiconv-2.dll error while playing video in OpenCV

I tried to play a video using OpenCV-2.4.7 in Visual Studio 2010, Win 7
Code is as follow-
#include<opencv\cv.h>
#include <opencv\highgui.h>
using namespace cv;
int main( int argc, char** argv ) {
cvNamedWindow( "Window", CV_WINDOW_AUTOSIZE );
CvCapture* capture = cvCreateFileCapture( "C:/Users/17/Desktop/Wildlife.avi" );
IplImage* frame;
while(1) {
frame = cvQueryFrame( capture );
if( !frame ) break;
cvShowImage( "Window", frame );
char c = cvWaitKey(33);
if( c == 27 ) break;
}
cvReleaseCapture( &capture );
cvDestroyWindow( "Window" );
}
Debugs is fine but on running, a waring window opens saying "The program can't start because libiconv-2.dll is missing from your computer".
I tried to download libiconv-2.dll into system package then it showed the error "C:\Windows\System32\libiconv-2.dll', Binary was not built with debug information".
Is there any possible missing setting?? what should be done to run this code?
It's an issue with opencv_ffmpeg247.dll in the latest release (2.4.7) as described here
I'm having the same issue, though with the fix earmarked for 2.4.8 I'd suggest either installing an earlier version (2.4.6) or using the latest copy from the repo here

Best way to have crash dumps generated when processes crash?

In Windows environments (XP and Win 7):
What is the best way to automatically have a crash dump generated when processes crash on the system?
Can an installer (MSI) package do this?
One of the best way to have an automatic dump for any/specific process on Windows is to configure a set of entries in the registry. I tried the below on Windows 7 64 bit.
Open notepad.exe, paste the below entry and save it as "EnableDump.reg". You can give any name you wish.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
"DumpFolder"=hex(2):44,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,00,00
"DumpCount"=dword:00000010
"DumpType"=dword:00000002
"CustomDumpFlags"=dword:00000000
Double click the "EnableDump.reg" and select 'Yes'. I have given the dump folder as 'd:\dump'. You can change it to whatever folder you wish.
Try to execute a crashing application, Windows will display the error dialog. Choose 'Close the Program' option. After that you will see the dump in the configured folder. The name of the dump file will be .exe..dmp.
For more details, you can refer the below link.
http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx
Below explanation is based on another answer, but the logic is mine (without attribution need, as said on my profile);
Having your own dump generation framework which automatically creates a process dump when any Unhandled exception is encountered, would avoid clients having to install WinDbg.
At the application start up use SetUnhandledExceptionFilter(...) Win32 API to register a callback (i.e. application level exception-handler).
Now the registered callback function is called whenever there is any exception which is not handled. You may then create the process dump using MiniDumpWriteDump(...) API from DbgHelp.dll.
C++ Sample (unicode-enabled)
header-file
#ifndef CRASH_REPORTER_H
#define CRASH_REPORTER_H
//Exclude rarely used content from the Windows headers.
#ifndef WIN32_LEAN_AND_MEAN
# define WIN32_LEAN_AND_MEAN
# include <windows.h>
# undef WIN32_LEAN_AND_MEAN
#else
# include <windows.h>
#endif
#include <tchar.h>
#include <DbgHelp.h>
class CrashReporter {
public:
inline CrashReporter() { Register(); }
inline ~CrashReporter() { Unregister(); }
inline static void Register() {
if(m_lastExceptionFilter != NULL) {
fprintf(stdout, "CrashReporter: is already registered\n");
fflush(stdout);
}
SetErrorMode(SEM_FAILCRITICALERRORS);
//ensures UnHandledExceptionFilter is called before App dies.
m_lastExceptionFilter = SetUnhandledExceptionFilter(UnHandledExceptionFilter);
}
inline static void Unregister() {
SetUnhandledExceptionFilter(m_lastExceptionFilter);
}
private:
static LPTOP_LEVEL_EXCEPTION_FILTER m_lastExceptionFilter;
static LONG WINAPI UnHandledExceptionFilter(_EXCEPTION_POINTERS *);
};
#endif // CRASH_REPORTER_H
source-file
#include "crash-report.h"
#include <stdio.h>
LPTOP_LEVEL_EXCEPTION_FILTER CrashReporter::m_lastExceptionFilter = NULL;
typedef BOOL (WINAPI *MiniDumpWriteDumpFunc)(HANDLE hProcess, DWORD ProcessId
, HANDLE hFile
, MINIDUMP_TYPE DumpType
, const MINIDUMP_EXCEPTION_INFORMATION *ExceptionInfo
, const MINIDUMP_USER_STREAM_INFORMATION *UserStreamInfo
, const MINIDUMP_CALLBACK_INFORMATION *Callback
);
LONG WINAPI CrashReporter::UnHandledExceptionFilter(struct _EXCEPTION_POINTERS *exceptionPtr)
{
//we load DbgHelp.dll dynamically, to support Windows 2000
HMODULE hModule = ::LoadLibraryA("DbgHelp.dll");
if (hModule) {
MiniDumpWriteDumpFunc dumpFunc = reinterpret_cast<MiniDumpWriteDumpFunc>(
::GetProcAddress(hModule, "MiniDumpWriteDump")
);
if (dumpFunc) {
//fetch system time for dump-file name
SYSTEMTIME SystemTime;
::GetLocalTime(&SystemTime);
//choose proper path for dump-file
wchar_t dumpFilePath[MAX_PATH] = {0};
_snwprintf_s(dumpFilePath, MAX_PATH, L"crash_%04d-%d-%02d_%d-%02d-%02d.dmp"
, SystemTime.wYear, SystemTime.wMonth, SystemTime.wDay
, SystemTime.wHour, SystemTime.wMinute, SystemTime.wSecond
);
//create and open the dump-file
HANDLE hFile = ::CreateFileW( dumpFilePath, GENERIC_WRITE
, FILE_SHARE_WRITE
, NULL
, CREATE_ALWAYS
, FILE_ATTRIBUTE_NORMAL | FILE_ATTRIBUTE_HIDDEN
, NULL
);
if (hFile != INVALID_HANDLE_VALUE) {
_MINIDUMP_EXCEPTION_INFORMATION exceptionInfo;
exceptionInfo.ThreadId = GetCurrentThreadId();
exceptionInfo.ExceptionPointers = exceptionPtr;
exceptionInfo.ClientPointers = NULL;
//at last write crash-dump to file
bool ok = dumpFunc(::GetCurrentProcess(), ::GetCurrentProcessId()
, hFile, MiniDumpNormal
, &exceptionInfo, NULL, NULL
);
//dump-data is written, and we can close the file
CloseHandle(hFile);
if (ok) {
//Return from UnhandledExceptionFilter and execute the associated exception handler.
// This usually results in process termination.
return EXCEPTION_EXECUTE_HANDLER;
}
}
}
}
//Proceed with normal execution of UnhandledExceptionFilter.
// That means obeying the SetErrorMode flags,
// or invoking the Application Error pop-up message box.
return EXCEPTION_CONTINUE_SEARCH;
}
usage
#include "3rdParty/crash-report.h"
int main(int argc, char *argv[])
{
CrashReporter crashReporter;
(void)crashReporter; //prevents unused warnings
// [application main loop should be here]
return 0;
}
Windows XP:
The following steps enable automatic crash dumps:
1) Open a command prompt, running as administrator
2) Run drwtsn32 -i. This will install Doctor Watson as the default debugger when something crashes
3) Click Ok
4) From the command prompt, run drwtsn32
5) Set the Crash Dump path to your favorite directory, or leave the default.
6) Set the Crash Dump Type to mini. Note that under some circumstances, we may ask you for a full crash dump.
7) Make sure the Dump All Thread Contexts and Create Crash Dump File options are selected.
8) Click Ok
9) If a user.dmp file already exists in the Crash Dump path, delete it.
Windows 7: Location is:
C:\Users[Current User when app crashed]\AppData\Local\Microsoft\Windows\WER\ReportArchive

ShellExecute print verb fails to print from 32 bit app on 64 bit windows

I have a 32 bit program that has been installed by a customer on 64 bit windows.
There appears to be a problem with using ShellExecute and the print verb in that configuration. First my test program.
// printme.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "objbase.h"
#include <windows.h>
#include <shellapi.h>
int main(int argc, char* argv[])
{
if (argc != 2)
{
printf("Usage: %s file_to_print", argv[0]);
return 0;
}
CoInitializeEx(NULL, COINIT_APARTMENTTHREADED) ; //| COINIT_DISABLE_OLE1DDE);
HINSTANCE retVal = ::ShellExecute(NULL, "print", argv[1], NULL, NULL, 0); // don't ask, as the user can always cancel...
printf("RetVal = %08x\n", retVal);
printf("LastError = %08x\n", GetLastError());
return 0;
}
This program works correctly on 32 bit windows version up to Windows 7. The program simply runs the print verb on the first argument passed on the command line.
printme Page1.htm
On the system in question, the registry is set up as follows:
HKEY_CLASSES_ROOT\htmlfile\shell\print\command
contains a default value of type REG_EXPAND_SZ containing
rundll32.exe %windir%\system32\mshtml.dll,PrintHTML "%1"
If I run the following command
rundll32 c:\windows\system32\mshtml.dll,PrintHTML “Page1.htm”
the print dialog is successfully shown.
However running my program blinks, but the print dialog never appears, and a stalled copy of
C:\Windows\sysWow64\rundll32.exe is in process manager, which never completes.
Is there a workaround, or is ShellExecute permanently broken for common verbs on common file types from 32 bit programs on 64 bit windows?
It turns out the problem is the last parameter of ShellExecute. While 0 worked for years, it now requires SW_SHOW to function correctly for the print verb in this case. Perhaps a recent windows update changed the behavior?

Keeping Console Window Open in Visual Studio (C)

I usually use XCode but was having a problem opening a file with this code:
#include "stdafx.h"
#include <stdio.h>
#include <stdlib.h>
int main(void )
{
printf("Hello");
FILE *filePtr;
filePtr = fopen( "test.txt", "r" );
if (filePtr == NULL)
{
fprintf(stderr, "Can't open \"test\"\n");
exit(EXIT_FAILURE);
}
else
{
int x;
printf("File open successful\n");
/* read one character at a time until EOF is reached */
while ((x = fgetc(filePtr)) != EOF)
{
//printf("%c", x);
fprintf(stderr, "%x\n",x);
}
}
fclose(filePtr);
system("pause");
return EXIT_FAILURE;
}
The console window closes so fast and at the bottom bar of VS it says: "'C_test.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\msvcr90d.dll'
The program '[1116] C_test.exe: Native' has exited with code 1 (0x1)."
What does that mean?
Also, can anyone point me to good VS starting points / tutorials?
See also How to keep the console window open in Visual C++?
The reason you can't see it is because there is no possibility for your program to pause during execution. In Visual Studio the typical behavior is to close the console window the second the program has completed its execution.
The bottom bar is telling you that the program complete and what the return value was (1 in this case).
What I would also do is add code right before the exit point of the program with #ifdefs:
#ifdef VS_DEBUG
fgetc(STDIN);
#endif
Now your program will pause when it's done and wait for a keypress then close the window.
I'm sure there is also a way in the project settings to prevent the closing, I've never looked myself.
I generally leave a breakpoint on the closing brace of main, so that the output of my window is visible while debugging, but Visual Studio will keep the console window open if you start the program without debugging (Ctrl+F5). Alternatively, you could simply ask for input, #MadcapLaugher's fgetc(STDIN); is probably your best bet - though I would add a prompt: "Press any key to continue... "
#include<stdio.h>
int main()
{
printf("Hello World from visual Studio \n");
//to prevent console window temination
system("pause");
return 0;
}

Resources