|
|
This is caused by FRED not actually checking its commandline to see if there is a file to open on startup. |
|
|
|
I'd argue that since this goes all the way back to retail, this is more of a feature request than a bug. |
|
|
|
And I would argue (as I told CommanderDJ last night) that this bug is describing something that is not working as expected so it is a bug. |
|
|
|
In ten years, how many people have expected that if you manually associate mission files with FRED, something FRED doesn't do itself for very good reason, that it would know what to do with it? First I've heard of someone trying in half that time. |
|
|
|
This is a feature request, not a bug report. As chief said, FRED does not register the .fs2 extension for the very reason that it doesn't know how to handle it. Would be nice if it did, but since for the past 12 years it didn't, a feature request it is. |
|
|
|
Personally, I did think it was odd that FRED didn't associate itself with the .fs2 files but I never investigated further because I don't use FRED to do anything other than to make a few test missions.
At that, last I talked to CommanderDJ he figured that he may have handle of fixing this bug anyway. |
|
|
|
So I've messed around with this briefly. I've got it opening a prompt to open a mission if you double-click on a file... but it's already got a mission name in the filename field that is completely unrelated to the file it's supposed to be opening. I need to find a way to access the name of the file that was double-clicked. |
|
|
|
There should be a standard method that Windows uses to pass that to the executable, whether it's command line or whatever. Should be plenty of docs on accessing that info. Might need to see how Windows sets up a file association by default if the app doesn't add itself to the registry automatically. |
|
|
|
mantis2594.patch (542 bytes)
Index: code/fred2/fred.cpp
===================================================================
--- code/fred2/fred.cpp (revision 8505)
+++ code/fred2/fred.cpp (working copy)
@@ -254,7 +254,15 @@
m_nCmdShow = Main_wnd_data.p.showCmd;
- OnFileNew();
+ //if we're opening a file, actually open it instead of just a new window
+ if(cmdInfo.m_nShellCommand == CCommandLineInfo::FileOpen)
+ {
+ AfxGetApp()->OpenDocumentFile((LPCTSTR)cmdInfo.m_strFileName);
+ }
+ else
+ {
+ OnFileNew();
+ }
if(m_pMainWnd == NULL) return FALSE;
|
|
|
|
Took a bit of digging, but I've got this working now. Patch attached. Feedback appreciated. |
|
|
|
Changing status to Code Review. Assuming the string handling is good, it looks fine to me. |
|
|
|
Fix committed to trunk@8515. |
|
