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.
Here’s the scenario: A user closes a subview by clicking on the “X” button its window, messing up your order of rule execution AND the demo of your work to the client.
Not that that really happened (oh yes it did).
Well, I’m not angry about it or anything (oh yes I am).
I spent several hours running through the entire chain of events and possible actions. And all of them worked correctly in EVERY instance — before I thought to test what would happen if the user closed the subview using that blasted “X” button in its window.
And what I found were three things: (1) clicking on that “X” control will abort normal rule execution, which (2) reproduced the behavior we saw during the demo, and (3) the window controls’ events are not captured by K2 SmartForms.
Well. Not without a little help.
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.”
Now that we have successfully implemented the Set Language control on a form, and figured out a means of passing the selected language to a subform, it’s time to explore how well the Set Language control performs in translating text on an editable view (a datagrid).
I was recently tasked with creating a series of editable SmartForm views based on some that already existed elsewhere in the application. One of the views was based on a SmartObject that contained a series of ID’s pointing to other database tables. The task was to have the list view list the text of the records the ID’s pointed to — not the actual ID’s. Makes sense – to display a value of “1” probably isn’t going to mean anything to the user, but a value of “ALL” will.
Doing this in the list view is the job of the List Display control. The List Display lets one configure the relationship between the SmartObject value and another value in a different SmartObject.
I had thought that my task should be relatively easy — save the original view as the view I was creating, change a little wiring, and I’d be good to go. Not so. For reasons I don’t understand, I simply could NOT make the the properties of my “new version” of the old list view resemble what I needed for the List Display to work.
In my case, it was just easier to start over.
And I found that starting over was exactly what I needed — everything fell in line effortlessly — so much so that I’m a little mad at myself for spending so much time yesterday on trying to make my former approach work.
All to your benefit — because I’m about to walk you through using a List Display object in an editable SmartForms View.