viktor's profile - activity

Shlwapi.h is used for windows-based path operation. Can be quite usefull e.g. when extracting a file extension and so on. But this has nothing to do with the error.
Are you using a pre-build version? You've wrote that you are using 3.0.0, so this may be be a bug introduced in the latest commits?

By the way, I've run your example code and encountered the same error :(

Thanks for your reply.
Yes, I'm giving a name to the output file. file is a std::string I construct using code from Windows' "Shlwapi.h". I've observed that I'm able to emmit single element to the FileStorage. Only when writing sequences of mappings I trigger the warning. What OS are you running?
Good to know you are unable to reproduce that error. This is the only time I'm using FileStorage though, so I'm kind of clueless on what else could lead to this problem.

From what I've read, they are being ignored when writing XML. The 2.4.11 doc reads: When the data is written to XML, those extra ”:” are ignored. Anyway, I don't think this is the cause of my problems, since I receive the exact same error no matter if colon present or not.
Anybody able to reproduce the error?

I have tried that already. Still triggers CV_Error. Also, the docs state: To store a mapping/sequence in a compact form, put ”:” after the opening character. So the colon operator is anyway just a YAML specific thing.
Are you able to reproduce this behaviour with the latest master branch @berak?

Hallo friends,

I'm confused over how to use FileStorage in order to write a sequence of mappings to a file.
Here's an example:

vector<pair<uint, Point>> vec; // holds results of video analysis
// append pairs to vec...
FileStorage fs(file, FileStorage::WRITE);   
fs << "Positions" << "[";
    for (Result::iterator i = vec.begin(); i != vec.end(); ++i)
    {
        fs << "{" 
            << "Frame" << (int)i->first
            << "X" << i->second.x 
            << "Y" << i->second.y 
            << "}";
    }
fs << "]";

When I'm running the above code I trigger the following CV_Error (persistence.hpp:1064):

if( fs.state == FileStorage::NAME_EXPECTED + FileStorage::INSIDE_MAP )
        CV_Error( Error::StsError, "No element name has been given" );

While trying to write the first element of the mapping. Of course I've checked the docs (see: http://docs.opencv.org/modules/core/doc/xml_yaml_persistence.html) but was suprised to see, that they basically do the exact same thing there.
Have they changed the syntax in OpenCV3.0 or am I overlooking something here?

I've already recompiled the current master branch (faa6684) after cleaning the build directory.
I'm running a Win 7 x64 with VS2012 as a compiler.

Many thanks,
Viktor

Too bad :(
Thanks berak!

Hi folks,

I'm using highgui to create a new namedWindow to display an image.
I'd like to stop program execution when the user closes the window by pressing the 'x' button.
Is there a way to check if the windows was closed, apart from using cvGetWindowHandle and testing IsWindowVisible subsequently (windows only)?
I'm using v3.0-rc1 with QT5 and OpenGL support.

Many thanks,
Viktor

Darn it, must have missed that one.. Building Qt libs from source solved the issue. Many thanks for your help, berak!

Hi folks,

I'm currently trying to build revision a31b29308f with the WITH_QT CMake flag on a Windows 7 x64 machine.

I use Microsoft Visual Studio 2012 (VS11) compiler and the qt-opensource-windows-x86-msvc2012_opengl-5.4.1 package. The QT install folder is added to the path. Once I generate the cmake files i recieve a couple of 'Policy CMP0020 not set' warnings. So far so good (I've pasted the cmake log at http://pastebin.com/3kFAhzns). When I move onto building OpenCV I start to receive linker errors that look like this:

LINK : fatal error LNK1104: cannot open file '..\..\lib\Debug\opencv_highgui300d.lib'
(I've pasted the entire log here: http://pastebin.com/PL3wq6EN)

No wonder, when the error occurs, there's no such *.lib file present!
But when I don't use the WITH_QT flag, everything works fine.
Any suggestions why?

Many thanks, best regards,
Viktor

Edit:
Building Qt from source instead of using pre-build x86 ones resolved the issue.