1

This makes me feel bad about myself: I can't convince the MRU list to show up in my MFC app's menu despite the fact that I'm doing all the same things that I did with my last project in which I used it, that is:

(a) loading the MRU by LoadStdProfileSettings() in CWinApp::InitInstance,

BOOL CEditor::InitInstance(){
    if (!CWinApp::InitInstance()) return FALSE;
    CCommandLineInfo cmdInfo;
    ParseCommandLine(cmdInfo);
    if (!ProcessShellCommand(cmdInfo)) return FALSE;
    LoadStdProfileSettings(); // begging you, do something!
    m_pMainWnd->ShowWindow(SW_SHOW);
    m_pMainWnd->UpdateWindow();
    return TRUE;
}

and (b) adding each loaded/saved file into the MRU list in CDocument::Serialize

void CDrive::Serialize(CArchive &ar){
    // serialization
    // - add to the MRU
    CFile *f=ar.GetFile();
    CString fileName=f->GetFileName();
    extern CEditor editor;
    editor.AddToRecentFileList(fileName);
    // - i/o
    // ...do the main objective...
}

As pinpointed in the title, must be something terribly stupid which I've been overlooking.

Really many thanks for any helphing hand.

Tomas

tomascz
  • 235
  • 1
  • 13
  • If I can recall correctly, this may happen sometimes if something goes wrong with the issuing of resource IDs for your own resources and you inadvertently start issuing ids that overlap the range of ids used for the MRU file list. But it has been a long time, and I do not remember the specifics, nor can I say this with great certainty. But I do remember that some housekeeping of resource ids was necessary every now and then in MFC projects to fix various weird things. – Mike Nakis Dec 03 '15 at 20:35
  • 1
    Hi, thanks for the comment. Well, I don't know if this could happen in this case as the last auto-generated ID has the value 40034 and the first MRU item (ID_FILE_MRU_FILE1) has 57616, so there still is a huge padding between these two. I at this moment don't use any own runtime-generated IDs to interfere with the MRU... But thanks for the suggestion anyway :-) – tomascz Dec 03 '15 at 20:53
  • I've always found this to feel a bit "broken", but one thing that I now do regularly when messing with MRU issues is to manuualy delete the stored registry entries before testing any code changes. – Roger Rowland Dec 04 '15 at 07:50
  • Hi, that's clever too. But I was just enlighted by an idea - let's add the items in the resource editor manually and see what it does ("x"-"z" in http://nestorovic.hyperlink.cz/__comms__/mru_rc.PNG ). Surprisingly it does all what one wants from it :-) http://nestorovic.hyperlink.cz/__comms__/mru_app.PNG But I'm still keeping this topic open in case that someone would find where the dog lies burried. As apparent from pictures, using XP SP2, VS2010Express, VC++98 res editor, and MFC6 - deadly combination sometimes :-) – tomascz Dec 04 '15 at 08:39
  • EDIT: Well, when playing now with it, it turns out that one such item in the menu is enough to kick up MFC's functionality. The only downside remains that this item is there even when the MRU is empty. I've worked around this by giving the item some sensible text like "No recent files yet", http://nestorovic.hyperlink.cz/__comms__/mru_empty.PNG – tomascz Dec 04 '15 at 08:53
  • Two things: (1) You should NOT call AddToRecentFileList() yourself, framework does it when you `open` or `save as` a file; (2) What is stored in your app's `Recent File List` registry key? Are there any `FileN` entries? For what values of `N`? – Vlad Feinstein Dec 04 '15 at 14:22
  • Hi there, (1) thanks, at least one line of code less, (2) I don't use registry to store the settings - letting MFC to save it to an INI file (at least for now). The MRU is saved correctly and even loaded correctly (judging from the correct content of `CWinApp::m_pRecentFileList`), it just isn't shown for some strange reason. – tomascz Dec 04 '15 at 16:30

0 Answers0