22

In Mathematica I run this command:

Plot[Sin[x], {x, 1, 15}, GridLines -> error]

It generates a Plot with this error message:

A GridLines specification should be None, Automatic, or a list of grid line specifications.

When I run the same command via .Net Link it doesn't return the error message:

enter image description here

I've debugged the Math Kernel code and the MathKernelPacketHandler method in the MathKernel.cs class doesn't add the message.

The funny thing is if I run this command, it WILL return a message:

Plot[Sin[x], {x, 1, 15}, DateLabelFormat -> "aaa"]

Does anyone know if I can capture both failure messages?

Lastly I should point out that CaptureMessages is not used in the code. If you set it true or false it has no effect in the Kernel. Possibly a bug, but causes no problems.

Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
WolframFan
  • 1,412
  • 14
  • 21
  • 2
    You're right about the non-use of CaptureMessages (and also CapturePrint). I just fixed that, so the values of these properties are respected, and the defaults changed to True, thus preserving the current behavior. This is why it's good to give out one's source code! – Todd Gayley Jul 24 '13 at 15:43
  • 1
    I added the tags [tag:kernel] and [tag:mathlink] as this is a more general problem than [tag:.netlink]. – rcollyer Jul 24 '13 at 15:52
  • I just wanted to acknowledge all the help everyone has given on this topic. Thanks very much. I've upvoted all answers, just need a bit of time to either get this working or decide if I'll put this aside and leave it as a FrontEnd feature. – WolframFan Jul 25 '13 at 06:37

2 Answers2

26

To access the errors, you need to invoke the Front End directly from the kernel. In effect, you end up telling the kernel to tell the FE to tell the kernel to do something, so that the FE can report any errors it finds. The method I use is

ClearAll[getFrontEndErrors]; 
SetAttributes[getFrontEndErrors, HoldAllComplete]; 

getFrontEndErrors[expr_] := 
Block[{nb, pinks}, 
    UsingFrontEnd[
        nb = CreateDocument[ExpressionCell[expr, "Output"], 
            Visible -> False, NotebookFileName -> "FEMessages"]; 
        SelectionMove[nb, All, Cell]; 
        pinks = MathLink`CallFrontEnd[FrontEnd`GetErrorsInSelectionPacket[nb]]; 
        NotebookClose[nb]
    ];
    pinks
];

which only returns the FE errors. (Edit: I removed the use of Internal`WithLocalSettings as it has limitations that are counterproductive here.) Note, this creates and destroys a notebook. But, if you are posting the info to an existing notebook, you can bypass those steps and just call

MathLink`CallFrontEnd[FrontEnd`GetErrorsInSelectionPacket[nb]]

which returns an empty list if there are no errors present. (You may have to preced the above code with UsingFrontEnd.)

rcollyer
  • 33,976
  • 7
  • 92
  • 191
  • 3
    Nice. I wonder how people learn about hidden things like FrontEnd`GetErrorsInSelectionPacket. Your function didn't work for me, though, until I took out the Visible->False. It seems that because the error isn't generated until rendering time, it never occurs if the notebook is not made visible. It's not clear how to integrate this into the workflow of the original question. There is no direct indication that there is a problem with the original graphic, so you would have to perform this step as an extra test on every single image. – Todd Gayley Jul 24 '13 at 16:27
  • @JacobAkkerboom I've never been sure when to add Visible -> False or not. I do know if they are visible, you will see them blink in and out of existence. – rcollyer Jul 24 '13 at 17:09
  • @ToddGayley I cheated. I learned it from someone else because I needed it for my testing, and yes you have to run it on every single image. I'm not sure how to integrate it into the OP's workflow, either, but it is a place to start. – rcollyer Jul 24 '13 at 17:11
  • @JacobAkkerboom I've added a potential fix for the Visible -> False problem. If you would try it again, I would appreciate it. – rcollyer Oct 09 '13 at 12:57
  • @rcollyer I think it works fine now :). – Jacob Akkerboom Oct 09 '13 at 13:44
  • @JacobAkkerboom and yes, it took me that long to fix it. It has never been high priority as it always seemed to work for me, except in a few rare cases. But, those rare cases became common last week. So, I figured I needed to figure it out. :P – rcollyer Oct 09 '13 at 15:22
  • @ToddGayley I think I've fixed the Visible -> False problem. – rcollyer Oct 09 '13 at 15:23
  • @rcollyer thats the way things go, good job nonetheless :). (temporary message?) – Jacob Akkerboom Oct 10 '13 at 12:31
  • Why do you use res this way? – Sjoerd C. de Vries Oct 16 '13 at 09:50
  • @SjoerdC.deVries it's a remnant of the code I'm using. I usually perform another test on the result, so that's why I capture, res. But, yes, res is irrelevant in this case. – rcollyer Oct 16 '13 at 11:58
  • @SjoerdC.deVries removed that, made SelectionMove more robust by changing Next to All, and added the option NotebookFileName -> "FEMessages" to not blow out the untitled notebook list. No one needs an new notebook named "Untitled-1032". – rcollyer Oct 16 '13 at 12:51
  • @rcollyer Ha! Good idea. – Sjoerd C. de Vries Oct 16 '13 at 12:57
  • Why did you change Module to Block? Isn't the former more correct here? Or it is something about Front End evaluation? – Mr.Wizard Jul 16 '15 at 14:42
  • @Mr.Wizard that's a good question. I pulled this from my internal code, massaged it a bit, and put it up. I don't recall why I switched to Block, as it has been a long time. I suspect it was a desire to limit the number of symbols introduced in my tests which Block does, but I'm guessing at this point. – rcollyer Jul 16 '15 at 14:53
9

The problem here is that the Gridlines specification error message is not a kernel error message (you'll note that it is not printed with the standard Func::tag format). Instead, this warning text is generated by the front end during the rendering of the graphic. The actual generation of the gridlines values is deferred to the moment when the graphics expression created by the kernel is actually rendered into an image by the front end. From the perspective of the kernel, there is nothing wrong with your erroneous GridLines specification.

The front end does not report these errors in any way I know of, so I'm afraid I see no reasonable way of getting this information in any external program that calls Mathematica for graphics, whether it is .NET, Java, C, etc. The image you get back will have a pink error background, but I don't think there is a way to get information about the specific cause of the error.

Todd Gayley
  • 4,198
  • 20
  • 19