Retina Logo

SmartForm Assistant

Welcome to the first beta of the SmartForm Assistant! There are a few items we need to cover, to help you run the debugger correctly. Please read this page, it should take about five minutes.

For simplicity I will refer to forms and views simply as forms.

  1. This is a beta from a dev, dev’s are great at code but not so good at design.
    1. The UI has not had any kind of professional love, enjoy the functionality and try to cope with the UI!
    2. Under the hood, every object in the debugger is it’s own HTML span. 
      1. This allows the debugger to provide custom styling or functionality for every type of K2 object the debugger encounters.
  2. I get my best ideas as I debug forms, I am sure you will too and I’d love to hear about them, please log them here
  3. General feedback is the key to ironing out the bugs in this program. Feel free to email me.
  4. The debugger only works for forms loaded in their own Chrome tab.
    1. The debugger will not find a form in the designer at this stage.
    2. Opening the debugger on a form with a subview already open, only shows the parent information, not the subform’s. If you open a subform while on a form, the debugger will show the subform information – and remove the parent’s information. The ultimate intent of course, is to show both parent and child but good things take time.
    3. When testing forms with parameters, the easiest way is to select Run with Parameters, enter the parameters, and click the Test button. This loads the page in its own tab and the debugger works perfectly.
  5. Occasionally the SF Assist tab in Chrome Dev Tools doesn’t load and is blank when you open it. Right click the canvas and select Reload Frame.
  6. Unfortunately the SmartObject method names in XML are encrypted for most K2 installations, including the cloud and cannot be displayed.
  7. The goal was the debugger be able to run without any modification to a form but the debugger can’t load before Initialize unless a user message is added to the init event, this gives the debugger time to load the controllers and rules. I add this
  8. I have not tested with SmartBox objects. I have no idea what it will do.
  9. Press Ctrl+F to search the current pane, this allows you to search for any rule, variable or text and is a great time saver.
    1. If you reload the frame it breaks a port connection and search can’t work, just close and reopen the tab to re-enable searching.
  10. I have only tested on the forms I’ve created and a couple of other K2 forms in the system category in Management. I’ll be very interested to see what happens with other’s forms.
    1. In the inevitable event that your sublime rules or crafty controllers break the debugger, it would be very helpful for me to get a copy of the controller and rule XML. As I dont save copies, you would sending them. I don’t have a mechanism yet to automatically send them, but email will work for now.
  11. Chrome extensions, particularly custom dev-tool panels, provide amazing functionality, one major the drawback is Google must validate that the extension code in their store is not malicious and they require code they can read. Therefore there is no way to protect any IP in the extension. Extensions are frequently copied and re-posted to the store by fraudulent users and there is little an author can do.
    1. To this end I have taken the core engine and placed it in an Azure function. This means your rules (not the controllers) are sent offsite to be de-compiled. They are not stored or recorded in any fashion.
    2. As this is an Azure function, the first time you call it, you may experience a “cold start” delay of up to 10 seconds while processing your rules. Subsequent calls within 20 minutes will be substantially faster. Once in production, I will assign a higher level service to improve performance.


There are four tabs in the Assistant.


  1. Data Explorer – This shows every property in the design of the form, view and controls.
    1. For the most part, this tab is functional. You’ll probably see formatting issues with expressions and things like that but you should be able to investigate all the properties, subforms, subviews, parameters, smartObjects and fields on a form.
    2. You can edit data labels and the changes are posted to the form. Being able to edit data label values at runtime is a significant time saver. Just make sure you refresh the data explorer to get the latest values before you update.
    3. Try clicking on a blue smartObject. I think you’ll like the result.
    4. I am building context menus into the debugger. Right click objects and see what magic I’ve been able to build.
  2. Rules – A keyboard navigable list of the form or view’s rules.
    1. The most important thing to know about the debugger is this tab represents a translation of the internal XML rules back into human readable rules. This is an exceptionally tedious and detailed task.
      1. Actions in the underlying XML include a keyword that describes their function. It handles common actions but there are many actions that I have yet to decode. If you see a keyword with an * after it, it is one that I have yet to translate (and localize) but regardless, if you read a form’s rules, you’ll be able to figure out what’s been executed.
      2. The translation of actions represents the remaining bulk of the work required to release the debugger.
    2. The XML Runtime rules are not as extensive as the rules as design time. For instance they don’t contain the names of controls referred to on subforms, expression names or details about views opened by buttons.
    3. In this tab there is a settings button.
      1. Sort rules alphabetically – rather helpful. K2 should implement this in their designer.
      2. Show GUIDs. Turn on to show guids in the data explorer.
      3. You can turn on/off stack trace errors from the Azure rules engine. Kind of like CustomErrors for IIS.
      4. I can copy the output of the various stages of the debugger to the clipboard. This greatly aids debugging but is probably of limited value.
  3. Events – A runtime list of the events and actions as they are executed. This is the gold! When you run this on a complex form and see what is generated, and you’ll see why some of those forms were so hard to debug. 🙂
    1. You see the name of the action after it has executed, not the XML GUID scramble of the current logger. It also filters out the system events, which create a lot of the distracting chatter in the current logger.
    2. Double click an action or event to see the definition of that item.
    3. The SmartObject execution very useful, as it shows the parameters used in the SmartObject call.
    4. There are check boxes in the rules to enable a “breakpoint” of sorts at that action. That functionality is still in the works.
  4. Information – This tab, where I will post Information and “What’s New” details.


I hope you enjoy the debugger, please send your feedback and ideas.