🚀 go-pugleaf

I just added a note to your earlier posting .. I think that you need to resolve your problems there before trying to migrate to FM8 .. most likely you'll see the same error in FM8.

To answer your questions ..
- yes, FM7 books/files can be opened in FM8 without problems
- yes, FM7 books/files should look the same when printed from FM8
- you *may* be able to compile your FDK7 API with the FDK8 libraries .. in general it works, but you may need to make some tweaks. The bigger issue will be problems that arise from the compiler version .. FDK8 requires that you use VS 2005. However, you should be able to load your FDK7 DLLs directly in FM8 without recompiling .. in general, this can be done without problems. The main reason to recompile using the new libraries is if you want to take advantage of new features (such as Unicode).

You can download the FM8 trial and give it a whirl. But .. I do think that you'll need to resolve the fundamental reason for the crash before it'll work in FM8 .. unless it was an actual bug that was fixed in FM8.

...scott

Hi again!

I downloaded the FM8 trial and gave it a try. Nothing changed, it still crashes, but I didn't recompile with the new FDK8, so if the problem is in the FDK7 API it continues to affect my application.

I'll manage to get a VC2005 and to try a re-compilation, with FM8 and FDK8.

Do you know if the new FDK8 dropped support for the old FDK7 APIs call format? I hope this has a chance of success without the need to change the application code, do you think it has?

Please, any hint is appreciated!
Thanks,
n3u.

As far as I know, all FDK7 functions are supported in FDK8.

...scott

Well,
I managed to get a VC2005 and to fierce fight to get my application recompiled with FDK8.
Then, to let it run, I had to face funky errors like missing icuuc28.dll, icudt28l.dll, icuin28.dll that are actually shipped with FM8 but not into the right place (system32). I wonder if that files will have to be copied inside the system32 directory for each workstation that will need to run my application!

Besides this, the application finally run and in a certain way it worked! What's shocking is that after the PDF creation the FM8 crashes abruptly giving a nice set of new errors:
1 - The font information for your system has changed. This change may affect the format and output of your document(s);
2 - Internal Error: 8004, 6343724, 8484240, 0;
3 - The function XXXX referenced memory that was "read" (or something like that).

I wonder what's going on!
Of course the fact that the PDF is created until the last page it's a good new, but all that bunch of errors are quite scaring and however not quite a sign of stability.

Do you know the new error I am getting?
There's something that can be done to further inspect the problem?

Thanks alot,
n3u.

Sorry .. I've got nothing new to offer. Hopefully someone else will have some suggestions.

Good luck!

...scott

I also posted this in your first thread:

n3U,
I hate to state the obvious, but you've updated software. And if there's still a crash on the same page, there's something physically wrong on the page or in that file.
You could try printing it, or that chapter separately... but I think you need to start by making backup copy of the problem file and then saving the file, manually, as a MIF file, opening that in Frame, and saving over your other file. This should clean up any file corruption, stray characters, and malformed tags.
If the file still triggers a crash, you need to deconstruct it, piece by piece or condition by condition until you find out what content is causing the problem.

Cheers,
Art

n3u,

I don't know what the problem is and I don't think I could figure it out from here. No one asked this yet, though... what happens when you try to make a PDF manually? If you replicate the exact steps that your API code is doing, does it still crash? If you haven't already, you should do this to determine whether it is your code or a FrameMaker problem. FrameMaker is well-known for crashes when printing/PDFing with conditional text. If it is a FrameMaker problem, you'll need to troubleshoot your document(s), not your code.

Russ

Hi!

I already did that test, selecting manually the exact conditionals patten that causes the FrameMaker crash. It works and creates a PDF without problems.

Keeping in mind that there's the chance that, cause I don't know how to use the FrameMaker directly, I'm not reproducing a sequence of actions that equals what my application does, the result of the test tends to make me think that:
- the document is good in itself;
- considering that my application works well with other conditionals patterns and that works also well if I produce a MIF instead of a PDF with the same pattern, I tend to believe that my application is always doing the same (good) work;
- there's only one actor left that has to be considered: the FDK API layer.

I'm open to your considerations about my logic.

Thanks alot for your attention,
n3u.

n3u,

I'm afraid I have to echo Scott's sentiment that I don't know what else to add, other than to be sure you are replicating the manual steps accurately and that your code is clean. I've seen crashes before that were my fault but didn't show up until later in the processing. It's possible that you have violated the integrity of the memory somewhere but it doesn't get "stepped on" until Frame does the PDF step. Be sure that you have allocated and deallocated everything carefully.

Russ