FDK Problem: "Unsaved changes in file" dialog with MIFs

[eric247]

Hi there

I have a problem saving MIF files using our FrameMaker API client.

After we have written out all our content, we're getting prompted to save unsaved changes in the .MIF file.

We're not sure whether to click yes here or not.

If we click yes, we then get a save dialog which prompts for a filename,

but has the default file extension set to .FM.

When you click "save", another message box appears telling me that I'm trying to save a

.MIF file in the .FM format and that is not allowed, and asks if I want to save it

as .MIF. 

Although this is an a mere annoyance for me, it's probably very confusing for

customers who use our software, and I'm not sure whats causing it.

I've tried to address it by modifying the default save parameters within the FAPI

using this:

F_PropValsT saveParams = F_ApiGetSaveDefaultParams();

i = F_ApiGetPropIndex(&saveParams, FS_ModDateChanged);

saveParams.val.propVal.u.ival = FV_DoOK;

Needless to say, it didn't work. I'm wondering is thee another approach I should

be using?

Thanks

Eric

[Russ Ward · Accepted solution]

Hi Eric,

I'm not clear if your software is saving the file automatically, or whether the user needs to do it after your process runs. And, I'm not really clear on what exactly you want to happen after your code runs.

I do think that any open MIF file (even if in binary format, after being opened in FM) will cause that prompt when you attempt to close it manually, even if you have made no changes since the last save. My thought is that FM simply looks at the file extension and generates that behavior accordingly.

A few options you have (may be more, once I understand the situation better):

- Let the code close the file itself once it is done, using F_ApiClose(docId, FF_CLOSE_MODIFIED). This, of course, if the interactive user doesn't need to see it.

- Use F_ApiNotification() and F_ApiNotify to hijack the save request and save the file as MIF automatically, which should allow you to avoid the second prompt.

- Use notifications to hijack the document closure process itself, simply closing the doc upon request whether it has changes or not. Or, maybe you could add your own prompts. This would take consideration of whether you actually want to allow an interactive user to make changes after the code runs.

Just some ideas there. If you provide more info on what you want to happen after your code runs (presumably this is the translation thing), I might be able to help more.

Russ

[eric247]

Hi Russ

Thanks for your reply. Sorry if I wasn't clear.

F_ApiClose(docId, FF_CLOSE_MODIFIED) worked a treat as the entire save process is (or should be) automated.

Once the user clicks save in our software, that should be the last thing they need to do.

Your encyclopedic knowledge of the FAPI has saved the day once again

Thanks very much

Eric

[Russ Ward]

Good news. One thing... it is good practice to make absolutely sure that your document ID is valid before calling F_ApiClose(). If it is null (or maybe also invalid), it will shut down the entire FM session. I think you'll still get a chance to save documents with changes, but I'm sure that in any case you don't want this to happen.

A simple way to verify your document ID is with something like:

if(docId && F_ApiGetObjectType(FV_SessionId, docId) == FO_Doc)

{

  F_ApiClose(docId, FF_CLOSE_MODIFIED);

}

else

{

  ...do whatever

}

Russ

[eric247]

We actually encapsulate the close document functionality inside a function imaginatively named "CloseDocument()".

The document checks that the doc ID isn't null but from what you're telling me, a validity check is needed as well,

so I'll make the necessary changes!

Thanks

Eric

[Russ Ward]

It's possible I could be making that up, but it doesn't hurt to check. Invalid doc IDs can cause lots of problems when you invoke a function or property change that is also valid for the session.

[Van Kurtz]

I have no comments about your coding work, but just want to note that when I try to save a mif file as an fm file, the file name defaults to xxx.mif. If I select fm from the file type drop down, FrameMaker complains that it cannot save in that format. What the user has to do is DELETE the string ".mif" from the file name and then Frame will save it as a fm file. The point is, just using FrameMaker as is, without trying to manipulate things with code, it does not work as I THINK it should. Frame will happily save an fm file to mif, even if the .fm is in the file name, but not the other way around.

Van

[Russ Ward]

Van,

I don't know which version you or Eric are using, but I'm pretty sure this behavior has changed over the years. I believe that the filename used to default to .fm as well as the file type drop-down, which was even worse. Although recent changes seem to be towards improvement, I agree that it still does not work the way I want it to.

Way back, I think this behavior also applied to SGML/XML files. Thank God that was fixed.

Russ

[Van Kurtz]

Russ and Eric,

I stand a little bit corrected. Russ, I think you are correct about document files, but it does not apply to book files. If you save a book file to mif and try to save the mif file to a Frame book file, Frame will not let you unless you delete the .mif from the file name.

Van

[Russ Ward]

Either way, I think we can agree that the software could stand some correction as well