Dragevent is chopping-off the driveletter

bugs, errors
#1

Hi,

I just started playing with the dragevent. But the driveletter seems to be chopped off in the paths of the dropped files.
I tested the example “of_v0.8.4_win_cb_release\examples\utils\dragDropExample” and same problem, the example doesn’t work. And you I get an opengl error “…drawing unallocated texture…”.

“C:/users/myusername/…” ends up as “/users/myusername/…”

void ofApp::dragEvent(ofDragInfo dragInfo){
    for (int i=0; i<dragInfo.files.size(); i++){
        cout << dragInfo.files[i] << endl;
    }
}

Is this a known bug?
Is there a known workaround?

I’m on Win7 with codeblocks.

#2

I have now checked the “DragDropExample” on osx and it works fine. But then again there’s no driveletters to worry about.

I’d be very grateful if someone could test on windows and report back if it works or not. So we know if it’s a proper bug or if it’s just me.

#3

I have tested this example on Win 8 (64 bit) with of_v0.8.4_win_cb_release using Code::Blocks 13.12.

I runs fine without errors. I can drag and drop images into the application, which are then displayed.

Although, when I add your cout the printed location is also without a drive letter.

#4

Thanks for the reply.
Just to make sure. Did you try dropping files that weren’t in the data folder or on the same drive as where you have openframeworks installed (not on “c:”)?

#5

Some additional info. I initially tried it from another folder on the main c:\ drive (where openFrameworks is also installed), which worked. When I try to grab an image from another drive, I run into the same ‘unallocated texture’ error you got. As found above, it seems the dragEvent currently doesn’t return the drive letter, so the example application only works when the image is on the main drive. As you said, the conclusion is that dragInfo does not return the full absolute path, indeed a bug I would say (given that the description states it should return an absolute path).

#6

Thanks for that. I’ve now reported the issue. Hope I didn’t jump the gun on this.

https://github.com/openframeworks/openFrameworks/issues/3848

#7

SOLVED

Ok, I’ve managed to get some time to further investigate this.
I have found the source of the problem and managed to fix it (atleast on windows 7 x64).

The problem is with GLFW and I have 2 fixes:

  1. Using Glut instead of GLFW solves the problem. Then driveletters aren’t chopped off. But I assume of is switching to GLFW for a reason?
    .

    ofAppBaseWindow* win;
    //win = new ofAppGLFWWindow();
    win = new ofAppGlutWindow();
    ofSetupOpenGL(win, 400, 400, OF_WINDOW);

  2. Use GLFW and modify the file “openframeworks\of_v0.8.4_win_cb_release\libs\openFrameworks\app\ofAppGLFWWindow.cpp” like below:
    .

    void ofAppGLFWWindow::drop_cb(GLFWwindow* windowP_, int numFiles, const char** dropString) {
    ofDragInfo drag;
    drag.position.set(ofGetMouseX(), ofGetMouseY());
    drag.files.resize(numFiles);
    for(int i=0; i<(int)drag.files.size(); i++){
    //drag.files[i] = Poco::URI(dropString[i]).getPath(); // COMMENT THIS LINE OUT
    drag.files[i] = dropString[i]; // ADD THIS LINE
    }
    ofNotifyDragEvent(drag);
    }

I don’t know the implications of changing:
drag.files[i] = Poco::URI(dropString[i]).getPath();
to
drag.files[i] = dropString[i];
But it seems like it should be easy to solve permanently.

What would be the next step in order to do so?

#8

this should be solved in 0.9 or the nightly build where Poco::URI is not sued any more to parse that path

#9

Perfect!
Thanks for reply.

I’m reading up on the whole Git workflow thing now. It’s all new to me and a bit confusing.

#10

you can download the nightly builds directly from the download page, below the normal downloads: http://openframeworks.cc/download