Carey you are a pure genius. I hadn't realized that the commit changes caused the push of information immediately instead of only on window close...I guess I got hung up on the fact that it was the "On Close" actions. I have been able to modify my code to do exactly what I want it to do while avoiding pitfalls that I was worried about. Thank you greatly for being so attentive to the list
L. J. Head Software Engineer Remedy Approved Consultant -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Monday, September 25, 2006 9:49 AM To: [email protected] Subject: Re: Commit Changes on Dialog Parent 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: [email protected] > 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: [email protected] > 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: [email protected] > 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: [email protected] > 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: [email protected] > 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
