I have a form with some views that I’ve surfaced in a tabbed interface through the use of a content control. The content control makes tasks like these super easy, but it comes at a price.
Pickers are rather odd controls in that they appear much like a textbox but can behave like a choice control. As such, one can’t simply use a “transfer data” rule action to populate them.
I’m supporting an application that has a large number of rules inside the SmartForms. My task is to change some text. Instead of combing through all of the views and forms to find the text I need to change, I thought I’d try to work a little smarter.
I was having trouble with a SmartForm view recently — I couldn’t figure out why execution of this SmartObject method was taking so long! I could execute the SmartObject from within the SmartObject Services Tester and it would complete in less than a half-second; I even went down further and ran the procedure directly from SQL Management Studio… everything at the data layer looked “clean and green.”
This post is all about saving you time by telling you where to best implement an auto-save capability on a SmartForm or editable view. An auto-save capability would mean removal of a Save button or toolbar button from the form in favor of Save rules being executed from some other rule, providing a seamless experience for the user.
This is an enhancement I’ve really wanted to see: SmartForms Rules in version 4.6.9 now have name and description properties. Much like comments in code, these should be immensely helpful for developers new to a project who have to figure out what rules do what.