- May 29, 2009 at 9:33 pm #203
Is it possible to update a child form without actually opening it? I am trying to setup a form with a table where every entry in the table represents a child form. I would like to allow the user to update the fields in the table directly, and have those changes committed to the child form without having the child form open, submit, and then close.June 1, 2009 at 12:16 pm #4566
Have a look at the form connections actions where you can ‘update’ another form using the Connect actionsJune 4, 2009 at 9:32 pm #4589
I have created a connection to update the child form, and that worked as described.
Now I am wondering if there is a way to create a child form without opening the new form instance. I created an “Insert” action for the form connection, which will create a new instance without opening, but it does not have the Parent-Child relationship (even if I pass the open form’s Instance ID to the new form instance as “meta – Parent Instance ID”).June 5, 2009 at 10:05 am #4590
what you have done will have told the ‘child’ form of the ‘parent’ (ie on the child is the instance id of the parent). Do a similar thing on the child in terms of storing its instance ID, and then on the parent use the ‘get field from other instance’ to return the child instance ID into the parent form and you should have the relationships you are seeking hereJune 5, 2009 at 7:56 pm #4592
Just to make sure I understand, what you are suggesting is not a genuine child-parent relationship, where the child and parent IDs are stored as meta-data, but a sort of artificial relationship where the relationship IDs are stored in fields; is that correct? Is there any disadvantage to this method as opposed to the standard child-parent relationship?June 8, 2009 at 9:04 am #4594
all a ‘parent/child’ is really is how the 2 forms are ‘linked’ behind the scenes. Doing this by physically storing the relevant form instance ID’s so each form knows about the other one is the sameJune 13, 2009 at 1:20 am #4609
I can now update an instance without having to open it, but is there a way to Submit an instance without opening it? Or is it possible to set the Instance Name and move the instance through its workflow without opening it?
Also, are the options under the “Form Field” drop down of the “Set Field in Other Instance” behavior documented somewhere? There are options such as linkID, lastDate, and InstanceGUID which are not documented in the User Guide, and are not present in other parts of perfectforms.June 15, 2009 at 8:55 am #4614
It sounds like you need to be looking at the API for these to programatically handle such events without them being opened.
have to ask though, what is the reasoning behind having a seperate form that you want to update silently but still then want to invoke routing ? if an action on your ‘parent’ form is to trigger an action to involve someone else, then why not run it all from this form? I’m sure there may be valid reasons for you wanting to do this, but it could also be that there is a different way to approach the overall process and there may be a lot simpler way to achieve what you are after here. perhaps contact us via the support ticket and we can open a conversation to try to help you find a more effective way of acheiving your aims
as to the options in the form field, these are ‘variables’ and as such have no bearing on how you need to define the form field to need to define. Technically they could be removed from this area but as they are ‘shared’ with other application functions it helps the overall product where a seperate control just for Set/Get Field instance isn’t then neededJune 17, 2009 at 8:56 pm #4623
I am trying to create a form that keeps track of time-off requests and approvals. The original idea is to have a single form where each request is handled as a line in a table, and that has worked well but I have encountered some limitations.
Specifically, the system needs to allow users to have multiple requests, but the amount of time requested impacts the amount of time one can use in later requests. It is a reasonable assumption that users will be requesting time in both long-term and short-term time-frames.
As a practical example: I request a week off in September, at which time I will have earned at least 40-hours of time off. Then, after the September request is approved, I need to request two-days off in August, but by taking those two days I will no longer have enough hours for the requested time in September. The ideal goal is to create a system that will warn a user if a new request in the short-term impacts the predicted balance for the future request.
All of this spanning multiple form instances. The idea was, instead of tracking requests in tables in form instances, each request would be a form instance that is then referenced by the “Parent Form” and displayed in a table (thus looking and acting the same for the end user).
If each request is an individual form, the system can then use a workflow to track the state of each instance, notifications, approvals, changes, etc.
Also, I see this as an exercise in understanding the system.June 18, 2009 at 9:04 am #4625
If your underlying concept is for the ‘parent’ form to be the ‘summary’ if you like of all previous requests and then from there you users can then raise more requests for time off, you could also look to use a REPORT instead of the parent to present previous information and where they can then initiate a new ‘child’ form if required. There wouldn’t then need to be any parent/child… just the main form the users complete to book time off
But taking this either as a FORM instead of a report, I would perhaps consider the parent form as the ‘summary’ where there is a form connection that returns to the table all the details from the child for that user (as the form is opened, and you can have a ‘refresh’ button that uses the ‘submit and reopen instance’) using form connections as opposed to the get/set field can give you more functionality (have a look at how the ‘connect’ and even ‘connect and search’ behaviour works especially perhaps in terms of how the ‘send parameters’ can be used to filter your connection information.
But then you can have form scripting/behaviours that can work on that table data to present to the user information relevant to your goal (ie time left you can take off etc) and within that could be showing/hiding the ability for them to initiate a new child (ie book more time off).
Then they can initiate a new child form which is the actual ‘time off request’ form, completing all the required information and submit it, and that then follows its own routing path. You could then use the parent/child (or form connection) methods to prepopulate the child form with the users information from the parent so the user doesn’t have to re enter lots of information manually, so in practical terms would then just be entering information for that specific request
Separate reports can then be set up on the child forms to present other information not only to the user, but also to management as well as they may require different information (ie more of a ‘summary of all my staff’)
and I would see that being a much simpler process to get what you are looking for here.
You must be logged in to reply to this topic.