Extracting the Error Message

It’s been a while since my last meaningful post – I’ve been tied up with our DR Project (but working with some pretty funky technologies – I like Virtualisation, but now that I have been working with a Veeam Backup and Replication my love of the technology has increased substantially). On the plus side, during my break I started thinking and playing around with methods to remove some of our modifications – something that I have been preaching for over a year now but fallout from pesky national state of emergency got in the way – so I expect to be posting a few more articles over the next week or so.

One of the headaches that I’ve had with Smart Office and jscripts is handling messages that come back from the server – be they information, warnings or errors.

I’ve needed to keep track of them for GL Imports and Budget Imports and more recently my work on removing one of our modifications (which I will be discussing soon). Previously I’d walk the visual tree looking for the control which displayed the error message at the bottom of the panel – a method which works but isn’t really fantastic and encounters issues if the user has their error messages displayed in a dialog box.

The removal of one of our modifications is a panel that has been changed to remove a lot of needless fields, and change the tab-order for our forklift users. Our forklift users do tend to get a little bored at times and are more likely than most of my other staff to change settings – for example, turning dialog box notifications on :-@

So, I wanted something a little more robust, not to mention I find it a little offensive that I should have to jump through those hoops to get a simple piece of information.

Out came Visual Studios Object Browser and a search for the word “Error” – looks like there are lots of methods to retrieve various error information within Smart Office but nothing seemed to fit the bill. The few that did seemed to fail when I created a script to test them.

But fate smiled upon me – and I found something interesting. MForms.Runtime has a class called Runtime, under Runtime is a property called “Result”. Looked very promising.

So I threw together a little wee script which would query what was returned. And well, it’s a fair bit of information to be honest, but I hit pay-dirt.

The Runtime.Result property returns an xml document which provides layout information for the panel, information about the session and then ControlData. It is the ControlData element that I was interested in.

Under the ControlData element there was three elements that held information that I was looking for, <Msg> <MsgID> <MsgLvl>, ok, well it’s really only one of these that I was interested in – the <Msg> element. It contains the data / message that will be displayed to the user. If there is no error/warning/information, then the message element won’t appear at all in the response document – so you can search for the existence of the <Msg> element within the document <string>.IndexOf(“<Msg>”) and fail if it exists, or succeed if it doesn’t exist.

 

Runtime.Result property returned by MMS100 – it shows a message of “Transaction type not permitted in this function”

Runtime.Result property returned by OIS101 after adding a line – it shows no <Msg> element whatsoever as no error occurred.

And the curveball

MMS100/N Quick Entry on a lot controlled item comes up with a request to confirm before the submission of the transaction.

Below is the script that I used to extract the XMLDocument.

If you attach it to OIS101 and then add a line with an incorrect product code you’ll see the results – run the script again then try again entering a correct product code.

Oh, if anyone finds a better way then please let me know 🙂

import System;
import System.Windows;
import System.Windows.Controls;
import MForms;
import Mango.Core;
import MForms.Controls;

import Mango.UI.Services.Applications;

package MForms.JScript {
   class testResponse {
   
           var gController;
           var gDebug;
      public function Init(element: Object, args: Object, controller : Object, debug : Object) {
            gController = controller;
            gDebug = debug;
            
         var content : Object = controller.RenderEngine.Content;

         // TODO Add your code here

         gController.add_RequestCompleted(OnRequestCompleted);
      }
      
      public function OnRequestCompleted(sender: Object, e: RequestEventArgs)
      {
          if(e.CommandType == MNEProtocol.CommandTypeKey)
          {
              if(e.CommandValue == MNEProtocol.KeyEnter)
              {
                  if(null != gController.Runtime.Result)
                  {
                      gDebug.WriteLine(gController.Runtime.Result);

// remove the event handler
                  gController.remove_RequestCompleted(OnRequestCompleted);
              }
          }
      }
      
   }
}

 

 

 

This entry was posted in Development, How Far is Too Far?, M3 / MoveX and tagged , . Bookmark the permalink.

3 Responses to Extracting the Error Message

  1. Al says:

    Thanks for that Scott. I’ll need to try this approach with the issue we discussed last year for sounding a note when an error message is displayed. Does this approach deal with the situation when the user turns dialog box notifications on and thus they don’t appear in the message bar at the bottom of the panel?

    Cheers, Al.

    • potatoit says:

      Hi Al,

      in my testing, yes, it gets around the issue when the user has “Display system messages in a dialog window” turned on.

      Cheers,
      Scott

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s