Hi I'm very pleased with my purchase of FM Perception. I particularly  like the Call Chain Diagram. When working in new complex solutions that I did'nt write. I'd really like to take a print of it ... is there a simple way to do this. I cant find one... but that doesn't mean its not there !

 

Rs

 

Simon

So, there's a relatively simple way to do this.  I haven't directly implemented printing support yet for either OS (definitely non-trivial).  But, when generating either a call chain diagram or a Report Card, the HTML is saved out to disk each time you make one.

Windows: The file is called htmlDump.html. It's on the desktop.

Mac: The file tempDump.html and it is in the Documents directory.

So, bring up the relevant call chain diagram, and then find the exported html file on your machine.  It's not elegant, but it's there.

Good enough?

By the way, the latest version of FMPerception (16.0.7) has an option under the File menu to export the Report Card or Call Chain Diagram HTML to a place of your choosing.  While this is not directly provide print capability, it does make it easier to archive, transmit, or print (using your browser of choice).  See the release notes for the latest version for additional details.

 

Thanks!

On 11/1/2017 at 4:14 AM, Dave Ramsey said:

 

Windows: The file is called htmlDump.html. It's on the desktop.

Mac: The file tempDump.html and it is in the Documents directory.

 

I have to ask. Why different names for the same file?

Most of the "back-end" code for FMPerception is 95% the same between Mac and Windows.  Of the remaining 5%, most of that is just punctuation.  I've gotten pretty good at mapping Swift to C# and vice-versa.  When I'm doing that work, the two code bases are up side by side, and everything is named pretty much the same. 

The big difference occurs when I'm interacting with the OS or the UI.  The APIs for communicating with each are completely different, and I've taken to not looking at the code side-by side as I don't want the Mac way of doing things to hurt my Windows code.  That can lead to this kind of difference, though it's not generally visible to the user.    For that matter, this was never supposed to be visible to the user.  It was just debugging code for my own personal use that lived too long.  Normally I'd have just hidden it, but the users found it useful... and then I wanted to replace it with the menu option... so until the menu option comes in I didn't want to start renaming files that people might be making use of...

 

And now it's all better.