File requestor per OS?

[christianclavet]

I've been checking my editor thread and I now think the best way to use the IRRlicht library OUTSIDE a game oriented thing would be to use the OS file requestor it's been compiled for.

Since it's the open discussion thread, I'll pitch some ideas

Would it be a big thing that IRRlicht have that support for using the OS requestor for each system (LINUX/WINDOWS/MAC)? Is a requestor OS call made on Windows XP is the same for example on Windows 2000 or Vista? Or there would be need to program for each version of the OS?

My current file selector have icons filetypes but lack in features compared to the standard file selector the OS offer. (Drive selection / shortcuts, drive mapping, etc.) Why redo the wheel? It's because it's too long to program? I really don't know exactly what will be needed to implement that and if it's really hard.

Another thing that could help a lot, is having a way to change the paths inside the node of a mesh and update the mesh. This way if someone modify a mesh in their 3D software and want to check it back, there could be a quick and simple function to refresh the mesh. For me now this look beyond my current skills. Right now, If I load a mesh, then delete it, then reload a newer version, the mesh from the buffer is back.

JP is now also doing his own editor and I'm happy to see that others will try to create editors for their projects. If we have to have bigger scope project and not just demos, we'll need good editors and way to improve them (Hope Niko continue working on IRRedit!).

We could have editors based on IRRlicht that do video editing (If the H264 format could be used, it would be almost easy to create HD video editor, Effect software and not just games...) We could have even a 3D design software that could use the GPU for rendering... etc...

Another thing would be great to have is that IRRlicht device that are created in windows, could use the mininize,(in 1.4 there have been some improvements already on the windowed device creation) and that some device could be created on borderless windows.

[dlangdev]

For win32 code, I found one example...

It looks like you may have to statically or dynamically link to mfc lib/dll to get it working.


See: OPENFILENAME

See also MS Common Dialogs

For implementation, the strategy pattern may apply for this feature.

Compiling the code will probably be easy, though linking it with local libs can be messy.

Code: Select all

C_mystring* C_file_handler::LoadFileDialog(char* Path, char* Filter)
{
    char Filestring[256];
    C_mystring* returnstring = NULL;

    OPENFILENAME opf;
    opf.hwndOwner = 0;
    opf.lpstrFilter = Filter;
    opf.lpstrCustomFilter = 0;
    opf.nMaxCustFilter = 0L;
    opf.nFilterIndex = 1L;
    opf.lpstrFile = Filestring;
    opf.lpstrFile[0] = '\0';
    opf.nMaxFile = 256;
    opf.lpstrFileTitle = 0;
    opf.nMaxFileTitle=50;
    opf.lpstrInitialDir = Path;
    opf.lpstrTitle = "Open File";
    opf.nFileOffset = 0;
    opf.nFileExtension = 0;
    opf.lpstrDefExt = "*.*";
    opf.lpfnHook = NULL;
    opf.lCustData = 0;
    opf.Flags = (OFN_PATHMUSTEXIST | OFN_OVERWRITEPROMPT) & ~OFN_ALLOWMULTISELECT;
    opf.lStructSize = sizeof(OPENFILENAME);

    if(GetOpenFileName(&opf))
    {
        returnstring = new C_mystring(opf.lpstrFile);
    }

    return returnstring;
}

[JP]

I managed to put drive selection in my FileSelector, though it's a bit of a hack really. It would be nice to have it working as you'd normally expect... (check out my IrrAI WaypointLinker if you want to see what i did)