Jase, While I understand the others responses to your question I think they might all be making a few assumption. (Maybe good/reasonable assumptions too, but assumptions all the same.)
Assumption #1: You did not state that "Form A" = "CHG:Task". Assumption #2: You also did not state the the dialog (Form B) is opened from an active link on "Form A". However the responses you received appear to consistently make those assumptions. So, just to be different, I will try to answer your question without those assumptions. :) I see two questions that you asked: Q1: Can anyone help me remember how to refresh a table field on Form A, when I commit changes on Form B (dialog box)? AND Q2: Can anyone help me remember how to refresh a table field on Form A, when I close window on Form B (dialog box)? These are different questions, but they interesting have a very similar answer. (kind of) Answer to Q1: This question does generally presume that the dialog (Form B) was opened from Form A via an acitve link. (Otherwise the Commit Change would not be sending data "back" to Form A. However, your user could have three, or more forms open too. Form A could be the second form and Form B could be the third form. ) The workflow on Form B has to be the place to start. If the only thing you want to do is the Commit Changes action and nothing else (and the above assumption holds true), then I think you have to accept a slight delay in the table field refresh. Here is what I would do if that is acceptable to your needs. Add a new display only field on Form A. Add to your "on close" map (of the Active link on the Form A, again assuming that it opened the Dialog) of the Window Open action to set a value into this new field on Form A. [ Ex. "RefreshTablesNow"] Then add an active link on Form A that fires "On Interval" that checks the display only field for the string "RefreshTablesNow" and does Change Field actions on any/all table fields in question. If there is a need to only refresh one table field at a time, then you can set the display only field with a string like "RefreshTable1Now" or "RefreshTable2Now". However, your going to have an issue because you will not know when the "parent form" actually fires the "On Interval" active link, so you do not know when to send the next code back to the parent. Which brings me to the suggestion that I would make for this design pattern.... Active Links Events. Using "event signaling" between the forms is the most general case and you can presume that the event is handled in a timely manor. This does however not strictly speaking tie these signals to the Commit Changes, or "Close" actions. However it should be just as effective. So this model would be implemented like so: The workflow on Form B that would do the Commit Changes, (or window closed) would instead (or just before the close action) it would do a PERFORM-ACTION-SEND-EVENT to trigger the "other form" (note I did not say "parent form") to do something with its active links that fire on "Event". There would be almost no delay in the other form processing this signal and you could send one signal then another then another and get the Event workflow on the "other form" to fire every time. Keep in mind that the PERFORM-ACTION-SEND-EVENT process allows you to send events to: @ = Parent window of current window # = All Child windows of the current window * = All windows NOTE: @ would only be the right choice when assumption #2 is correct. NOTE: # would only be correct if the dialog window opened the window in question. NOTE: * will notify all N windows that the client is managing and that is likely more Active LInk processing than you really need, but it gets the job done. And if you use $ SCHEMA $ in the EVENTTYPE string then you can also do early "on Event" processing on each form to cut short the number of active links on "wrong forms" that fire to maybe as little as one per form too. So you could issue an event like: PERFORM-ACTION-SEND-EVENT * "Form A:RefreshTable1" Then have an active link on Form A that looks for $EVENTTYPE$= $SCHEMA$+":RefreshTable1" that does a single Change Field action for the referenced table. You could even go so far as to make the EVENTTYPE string self describing (like $SCHEMA$+":RefreshTable"+<fieldID>) so that you "other" form could pull apart the EVENTTYPE string and "figure out" what table needs refreshed on the local form too. Sure it is more advanced, but once built, you can add that workflow to any form and your done implementing that UI behaviour pattern. :) RE: Q2 I think the only cautionary tail of Active Link Events on "Window Close" might be that on the Browser you _may_ not have a guarantee that the event signal will be processed before the window is closed. ( It may be browser dependent. ) So in that case I would try to not let the user use the browser "close window" button on the dialog and instead give them an ARS button. That should at least give the system a fair shot at having enough control over the order of the processing to make things happen in the proper sequence. [ Or I could be being browser paranoid and there is no issue under those conditions too. ] 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 2/22/07, Jase Brandon <[EMAIL PROTECTED]> wrote:
** Hey All, I have a dialog window, that I want to refresh a table field on CHG:Task when I close it. Can anyone help me remember how to refresh a table field on Form A, when I commit changes/close window on Form B (dialog box)? Thanks in advance, :) Jase DaVita Inc.
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
