I placed a button onto a kinetic dashboard. I want that button to check a box that is also on the dashboard that is being monitored by a data directive in order to print a label. So first of all i cannot figure out what onclick event or any event for that matter I use to trigger the clicking of the button to check the box. Second, I then need the checkbox to be cleared after. Lastly, i do not know why the data directive is not firing even if i manually check the box, it should be writing a file to a folder that bartender is monitoring. Any and all help would be greatly appreciated!
You can define the button behavior by clicking in Properties > Behavior > On Click.
The resultant event is where you can use a row-update widget to set the check box to true.
What is the condition for setting the check box back to false?
I believe you will have to save (call the Update method - or another method that performs an Update) for a data directive to fire. Until then, the data is sitting on the client side and is temporary.
Or possibly, I don’t know if Kinetic has this ability, but in classic, if the baq was set up for single row update, save would fire after the row change (if dirty). Anyone know if this is still possible?
It is true that the setter (=) is implied in a row-update widget … but that’s not the Update I was talking about - it should be a call to update your data (save changes) row-update is for updating the data in data views on the client side (which is already done when you check the box)
Is this a updatable dashboard like @klincecum was suggesting? how do you trigger that update - or what’s the BO method to call to make it do the update? can you set it to update onRowChange?
This is not an updateable dashboard. The print button that checks the hidden box is on the subcontractor shipment entry screen. I would like it to update onClick of the print button and save all in the same event. I can then use a row rule to clear the check box.
Assuming the subcontractor data is already a data loaded view with a valid save event in that dashboard and not custom made:
You would go to the Behavior of the button and into the onClick event, then you would do the following widgets more or less.
widget 1: row-update (set the Parameters → Columns → Ep Binding to your desired Table.FieldID and then value to “true” with quotes) → on success →
widget 2: event-next (set Event ID to the screen’s base Save event for that dataview. Can usually find this by going to the page and to the action on the grid and see what it calls, or just browse through the list of events if the screen is small enough)
Then a few options, but I’d recommend unsetting the flag in the BPM that prints and refresh the dataview
widget 3: event-next (calling the refresh event for the page so you don’t get a weird row modified by another user issue and so it pulls in that you cleared the flag in the bpm)
row-update alone does not save the view. It only changes the data loaded in the view in the screen in runtime. Remember javascript is a runtime language so we have a lot of flexibility in the screens. All the changes we make to the view is only an object in runtime and not pointing back to the db directly. To save it back to the db, you have to run the save event of the screen the same way we used to use reflection in c# to do. Or I believe you can probably flag it dirty if the underlying view is set up for that in the views section but I haven’t played around with that myself.
Ok, now why would you recommend unchecking the flag in the BPM vice a data rule or continuing with the same (or different) event? Does it just get too messy?
Really just a personal preference of mine - if anything is happening to data that the user isn’t aware of I like to do it in a BPM and depending on what it is, I may even show a message back to the user to explain what occurred. As long as your solution matches your business needs and doesn’t break any base functionality, I would consider it a win.
This does two things - one, it makes sure that it accounts for unexpected user input / behavior on the screen. We are only human, we can’t test every possible combination of page switches and button presses. For this instance, it may not matter, but if it’s for something more complex where order of operations matter it might.
Two, if gives you control over the record being dirty or not. If you can capture it pre-process, you don’t even have to save a change to the table. If you know you are going to be using it as an indicator only for printing it gives you flexibility for if you want to run a pre-process bpm to unset it immediately and not have any changes occurring at the db level; but still fire a printing method or business logic. This could avoid the “row was modified by another user” and you may not even need to refresh the screen afterwards with that last widget.
And 3, but less likely to matter for a long while since Kinetic is the new way of the world, it makes one less thing for you to uplift if there are major user interface changes again.
A data rule might work fine, but definitely not continuing with the same event, as it would take 2 distinct “save” events which the second one would almost definitely run into a “row was modified by another user” error.
Another path I didn’t mention is you could also not flag anything on the record and instead handle passing the data and process calling in a function. But that is a little more nuanced to set up and would take some time to learn it. I am tending to favor functions more and more as a means to handle button actions in screens now though.
Below is the custom code in order to write the bartender label. What and where do i add the additional needed code to set the print flag back to false?
Just a quick in-trans data directive that unchecks the box from whatever table it’s on before the save even completes - probably in the same BPM you’re creating the bartender file from. You’d use a set-field widget for that.
Unless you’re meaning it’s just a checkbox on a screen with no binding in which case I would instead bind it to the callcontextbpmdata to checkbox 01 or something, then do a row-update after the widget 2 on callcontextbpmdata after it prints to unflag it. Or a row-rule, whatever you find easier.
