I have a form that the user is going to submit outside of Workspace. I added a submit button on the form and hooked that to a LiveCycle process to handle the submitted form (in this case, saving the whole form in a database). However, once the form is submitted, it will be view-only elsewhere in the application, so I want to remove the submit button from the PDF. Is there a way to remove fields/buttons from a PDF in a LiveCycle process?
One way to handle this is to set a hidden field in the form that contains a 'Form State' indicator.
This is a simple number value that relates to the different stages the form goes through.
'1' might be open for entry,
'2' might be submitted.
'3' might be validated, etc.
Then it is a simple process to set a button ( or any other form object ) to be shown or hidden based on the value in the form-state field.
Remember to either set a default value, or initialize the form-state field before first use, and update it as the form moves from state-to-state.
In your case, the code you fire either just prior to the submit, or as soon as your back-end process receives the form can bump it to the value that would hide your button.
Hope this helps
Thanks for the response.
I was hoping to have a simpler solution. I added a preSubmit event to my button to set prescence property of the button to "hidden." This seems to work on the open instance of the form, but it doesn't affect the version that gets submitted and saved in my database. Are these types of properties not maintained? This is essential to my solution, because I'm storing the forms in a database, and they will later be accessed directly from the database outside of LiveCycle.
I'm going to try using an underlying hidden field to control the button, but I feel like there has to be an easier way to do this. In simple terms, I want the user to be able to submit the form once (outside of workspace), at which point they will only be able to access it as read-only (hence no more submit button). I'm a LC noob, but I feel like this is a very basic solution and shouldn't require creative workarounds.
So a lot depends on the internal structure, and how you are or are not bonding data.
The short answer, is no - setting a button property to hidden, when the default property is visible, will only persist for the time you have the form open.
Once you re-open the form, the default is used again.
This is why setting the formula to reference a data item that is saved with the form makes it easier to control the hide-when actions.
If you do not want to add an additional field - use an existing one.
Do you have a status field that shows the form has been submitted, or a date-time that is set when submitted, or any other value that can be examined to determine if the form has been submitted or not?
In general - hide when properties are usually defaulted to visible, and then set as hidden as objects get initialized.
This works wherever/whenever the form is opened.
If I understand correctly, this can't really be done "dynamically." The presence property of my submit button has to be set each time the form is initialized (based on a hidden "form status" field), and changing the value of the hidden field through a LiveCycle process won't actually fire the change event, so I'd have to manually change the presence of the button for that instance of the form. Can properties such as presence be accessed through a LiveCycle process, or would I need to create a script and execute it?
On top of that, the change event doesn't seem to work in a meaningful way. It appears to fire post-change, but accessing the value in the event gives you the pre-change value. Maybe I'm missing something, but that seems useless.
Your form objects have a default visibility - visible or hidden, based on how they are defined.
You can override the default behavior in a number of different events.
Initialize events fire when the form is first loaded, and when the form recalculates. Initialize can fire many times during a single session depending on the level of the object.
There are charts out there that show the relationship between forms/subforms/objects, and when the various events fire.
If the 'Submit' action was a watershed event that would change the look of the pdf - such that if it was not closed, but left open for the current user ou would want material changes to the appearance -
Then the form can be told to recalculate, or remerge - so that the initalize events now react to the current state ( data values ) in the form.
This way, if that form was not left open, but had been saved to the file system, and opened at a later time - the 'Submit' button would be hidden by the code in it's initialize event that evaluated a data element and told it to set presence = 'hidden'
There are also multiple ways to examine the value of an object pre and post change depending on the type.
For text, there is '.value' and '.rawValue'. there are different properties for dropdowns, etc.
In the change event for text, I believe '.value' will give you the old value, and '.rawValue' will give you the UI value.