examples\3d\assimp3DModelLoaderExample\src\ofApp.cpp line 266 need to change from loadModel(dragInfo.files[0]); to loadModel(dragInfo.files[0].string());

[lvdpower]

examples\3d\assimp3DModelLoaderExample\src\ofApp.cpp line 266 need to change from loadModel(dragInfo.files[0]); to loadModel(dragInfo.files[0].string());

timur123@gmail.com

[NickHardeman]

Are you working with an up to date master? I just checked with the nightly on macOS and it compiles without the .string() appended.

[artificiel]

@lvdpower are you on windows? it may be related to recent changes with file paths. can you provide the file path you are dragging (does it contain unicode?), as well as the exact error you are getting?

[NickHardeman]

Checking on Windows 10 with VS 2022 and nightly, I can confirm the error : no instance of overloaded function ofApp::loadModel matches the argument list The loadModel function takes a string as an argument. void ofApp::loadModel( string filename );

[artificiel]

well it's a perfect example. the loadModel function is given an fs::path, which on windows implicitly turns into a wstring.

now the question is: does the underlying assimp lib support windows wide char paths? if so, the path properties should be maintained down to the underlying lib call. if not, I suggest the same pattern we just discussed here:

// pseudo, for a lib that does not support wchar
loadModel(fs::path filename) {
  if (auto name_as_string = ofPathToString(filename)) { // explicit conversion with try-catch turning into an optional
    // GOOD: the path is either native std::string, or contains no untranslatable wchar unicode
    // do the thing with *name_as_string 
  } else {
    // we're on windows, and the path contains untranslatable wchar
    // somehow inform user that the given path is not digestible by the library
  }
}

this introduces the \ pattern which is a simple and effective way of dealing with "disappointments". note that this won't work right now as the current implementation of ofPathToString is not \.

if the lib supports wchar:, presumably (invented API):

loadModel(fs::path filename) {
  auto charpath = filename.native().c_str(); // on windows auto is wchar, else is char
  LibObject object;
  #ifdef WIN32 // or maybe an if constexpr switch based on type
     LIB_loadfromwchar(charpath, &object);
  #else 
     LIB_loadfromchar(charpath, &object);
  #endif
  // object contains data
}

all this might seem a bit overkill, but if we want transparent unicode wchar support in OF it means pushing the of::path properties as down and as close to the consumer as possible.