L. J., Ok.. Now I am really confused...
This makes no sense to me: "
I'm performing my push to the child with a `! and then sending an event to the parent.
" Active Links (AL) do not have phases. The `! at the end of an AL name makes no difference to how the AL works. NOTE: The "on open" mapping for the Window Open action populates the dialog with data. The "on close" mapping defines the data that is returned from the dialog to the parent window when a commit is issued on the dialog window. (NOT just when the dialog is closed.) What I think I understand is this progression of UIs.... 1) User has "Form A" open (lets call this the parent window) 2) User does something that opens a dialog window (Form B). 3) Form B does it's thing and creates a child (maybe with User interaction) AND also needs to add data to the parent window to indicated that the child was created. Even if the parent window has not yet been saved by the user. I would suggest that in Step 3 the dialog does a commit action. This sends the data to the parent window based on the "on close" mapping, or that it just keeps track of all of the data it wants to dump back to the parent window until it is closed. If the dialog stacks up all of the data until it is closed following a commit action, then other workflow that opened the dialog gets control in the parent window and "appends" stuff returned from the dialog (via a commit action in the Dialog window) to the parent Window diary field. If the dialog is closed between every child create. (And not Event logic is needed.) OR If the parent window needs to know about the child ASAP then you can do a commit action and then trigger an event to the parent window to "append" the data into the diary if any was sent. The Event AL's on the parent window will append the "on close" mapping fields (display only temp fields) into the real "diary" field(s) of interest. Is that what your trying to do? HTH -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 9/24/06, L. J. Head <[EMAIL PROTECTED]> wrote:
** Yea...I'm actually trying to work around a problem that has been fixed in 7.x. The problem is this. I am doing an audit of child entries into a diary field on the parent form. I would normally just do this as a push to the parent form from the child, this however presents two difficulties. 1 is that the push causes the error 'this record has been updated by another user since retrieval' (I was told by Doug that this behavior changes in 7.x if the person that does the update is you..it doesn't give you the error)...and 2 sometimes the parent record has not yet been submitted to the DB...so a push to the parent would do no good as it doesn't yet exist. So what I'm trying to do is send an event to the parent window to tell it to update the audit trail with the child information added. I'm performing my push to the child with a `! and then sending an event to the parent. That event AL then does a setfield from the child form using lastid keyword to get the information that was added and sets it into my audit trail diary. Within that same add button I am performing another event that causes a separate AL to do a refresh on the table I'm pushing to. As soon as I press the button I see the table refresh and I see the 'Save' button un-grey itself which indicates to me that the actions I have requested are in fact taking place....all except the Save. On a separate note I realize the down side of doing Audit trails in Diary fields and alternative options I have to doing it this way but I chose this direction for simplicity sake based on the users requirements. L. J. Head Software Engineer Remedy Approved Consultant ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Casey Civ Andreas Sent: Friday, September 22, 2006 4:01 PM To: arslist@ARSLIST.ORG Subject: Re: Commit Changes on Dialog Parent ** hmmm... interesting. So the data you're trying to commit to the DB on the parent form is different than the 'child' record that is created in the table on the parent form? I'm just trying to get a picture of the functionality you're building. As for the EVENT I'm definitely open to discussion about the topic. From my painful experiences trying to pass data to a dialog box that was already open with an event that fired on the parent form, I still think EVENTs don't run until a dialog is closed. From my experience a dialog box will hold the processing of everything external to it until it (the dialog box) is closed. Again I'm happy to learn something new if I'm interpreting things the wrong way. Anybody else have any experiences with dialog boxes and workflow they can add? Andreas Remedy Developer United States Marine Corps ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of L. J. Head Sent: Friday, September 22, 2006 14:14 To: arslist@ARSLIST.ORG Subject: Re: Commit Changes on Dialog Parent ** Actually Events occur on the parent window while the dialog is still open. I use them when using a dialog to add 'child' entries to a table and send an event to the parent to refresh the table..it refreshes while the dialog window is still open. I have the Commit Changes running in the AL on the parent window that is capturing the event. Everything except the commit is happening L. J. Head Software Engineer Remedy Approved Consultant ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Casey Civ Andreas Sent: Friday, September 22, 2006 2:59 PM To: arslist@ARSLIST.ORG Subject: Re: Commit Changes on Dialog Parent ** Where do you have the commit changes running? In another AL before you close the dialog window, or the AL that captures the event? Dialog boxes are modal, so if you're sending an event from within the dialog box the AL that captures that event isn't actually running until after the dialog box closes. Also keep in mind that a commit changes from a dialog box only sends the data to the parent, it does not push anything to the database. I beat my head against a wall for 3 days trying to figure this out. Check out the Basic Guide Appx B pg 632 for an example of EVENTs and Dialog boxes. Hope this helps. Just out of curiosity why not use the "On Close" functionality and then a either a push fields or a commit changes after the dialog closes? Andreas Remedy Developer United States Marine Corps ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of L. J. Head Sent: Friday, September 22, 2006 10:51 To: arslist@ARSLIST.ORG Subject: Re: Commit Changes on Dialog Parent ** That may be the route I end up taking but I was looking for someone with experience of why the commit that I have in place isn't doing what it's supposed to be doing L. J. Head Software Engineer Remedy Approved Consultant ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Roney Samuel Sent: Friday, September 22, 2006 11:43 AM To: arslist@ARSLIST.ORG Subject: Re: Commit Changes on Dialog Parent ** Dear L. J. Head, A simple workaround for this situation would be to set a temp field with a value "Yes" on Commit Action on the Dialog form. Then write another AL on the same action that you performed to invoke the Dialog form at a later execution order and check if the temp field is set to "Yes". If it is then save the record. Hope this helps. Regards, Roney Samuel Varghese On 9/22/06, L. J. Head <[EMAIL PROTECTED]> wrote: > ** > > Here is the situation. Form A opens Dialog of Form B. On button press on Dialog B I want to set a field on Form A and Save the record of form A. > > I have the button press on Dialog B performing an Event > I have an AL retrieving that event and doing a setfield for me...this all works. When I run logging I see the 'Commit Changes' action fire...but it doesn't commit changes...anyone else experience this and know of a work around? > > AR 6.3 > > L. J. Head > Software Engineer > Remedy Approved Consultant __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
