Opened 8 years ago

Closed 8 years ago

#11541 closed defect (fixed)

Fix for opening of multiple document templates not working on OSX

Reported by: SnowLeopard Owned by:
Priority: normal Milestone: 2.9.1
Component: wxOSX Version: stable-latest
Keywords: OSX document templates Cc:
Blocked By: Blocking:
Patch: yes


Say that you have a program with more than one document template (e.g., files with the DOC1 and DOC2 extensions). When a wxID_OPEN event is fired, the OSX file open dialog will appear and you will be able to select any file that matches the extensions for your templates (i.e., you can select either DOC1 or DOC2). Note how this is different from Windows where you have a file filter and you need to change that filter to select different document types--this is because the OSX file open doesn't have a file filter combobox like Windows. It just clumps all allowable file types into one filter.

Here is the problem--if you select any document type other than the first one (e.g., select DOC2), then the program will always load it as a DOC1 file. The culprit is "wxDocManager::SelectDocumentPath" in docview.cpp:

if ( FilterIndex != -1 )
            theTemplate = templates[FilterIndex];

On OSX, no matter what doc type you select, "FilterIndex" will always be zero. If you wrap this logic in a "#ifndef WXMAC" block, then that fixes it because then FindTemplateForPath is called and selects the proper template (see attached patch).

Attachments (1)

update.diff download (668 bytes) - added by SnowLeopard 8 years ago.

Download all attachments as: .zip

Change History (4)

Changed 8 years ago by SnowLeopard


comment:1 Changed 8 years ago by vadz

  • Milestone set to 2.9.1
  • Status changed from new to confirmed

Thanks for finding and reporting the problem! Unfortunately I don't think the patch provides the correct solution for it. The code in docview.cpp already has provision for not using the filter index if the current platform doesn't support it, it's just supposed to remain -1 then. It's wrong that it is set to 0 by default by wxFileSelectorEx().

Could you please test if the following patch (also) fixes the problem:

  • src/common/fldlgcmn.cpp

    diff --git a/src/common/fldlgcmn.cpp b/src/common/fldlgcmn.cpp
    index f4b4e0a..adab661 100644
    a b IMPLEMENT_DYNAMIC_CLASS(wxFileDialogBase, wxDialog) 
    3737void wxFileDialogBase::Init()
    39     m_filterIndex = 0;
     39    m_filterIndex = -1; // unknown
    4040    m_windowStyle = 0;
    4141    m_extraControl = NULL;
    4242    m_extraControlCreator = NULL;
    bool wxFileDialogBase::Create(wxWindow *parent, 
    6060    m_parent = parent;
    6161    m_windowStyle = style;
    62     m_filterIndex = 0;
    6463    if (!HasFdFlag(wxFD_OPEN) && !HasFdFlag(wxFD_SAVE))
    6564        m_windowStyle |= wxFD_OPEN;     // wxFD_OPEN is the default


comment:2 Changed 8 years ago by vadz

Oops, a further grep showed that maybe changing this is not as simple as I thought... Carbon and generic implementation might be not happy with filter index being -1 by default. So maybe the best would be to just make wxFileDialog::GetFilterIndex() always return -1 in wxOSX/Cocoa? At least until Stefan ports Carbon code (which, IIUC, implements filters on its own) to Cocoa if this is possible at all?

comment:3 Changed 8 years ago by csomor

  • Resolution set to fixed
  • Status changed from confirmed to closed

was fixed in r63178, closing manually

Note: See TracTickets for help on using tickets.