nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Callout spoiling DCR

fiquebem

Setting: TS 6.5 SP2 (without Patch) on a Windows 2000 Server.

My DCT has a replicant (see the DCT attached). It also has a callout (see the script attached). I've stripped down the script in hopes of finding the problem. It seems to revolve around "opener.top.datacapture.refreshForm()." In a DCR, it seems to change the Report field of the 3rd instance of the Reports replicant to be the same as the repName of the 1st replicant instance, if I follow these steps:

1. Create 3+ Reports instances, making the 3rd Report different than the 1st Report

2. Save

3. Click the callout button

4. Click Submit in the callout window

5. Save

6. Refresh

The 3rd Report (e.g., "Round Table Quota Report") gets changed to be the same as the 1st Report (e.g., "Circle of Honor Report / Net Gain Goal Report"). See the DCR attached.

Incidentally, the 5th Report instance was being affected by this malady originally. After I removed a date field in the replicant, the 4th Report instance was being changed. Finally I removed the 1st field in the DCT (which was outside the replicant) and now the 3rd Report instance is being changed.

It's so curious. There's no FormAPI involved that I know of. Is it possible that the Save button has been customized somehow? Is there a bug
somewhere? Or is the problem between my chair and keyboard?

I suppose I could try opener.top.datacapture.refreshItem(), but I'd like to understand what's going with opener.top.datacapture.refreshForm().

Any comments will be appreciated!

S.

Find more posts tagged with

Comments

ISCBorisB

It's so curious. There's no FormAPI involved that I know of.
Is it possible that the Save button has been customized somehow? Is there a bug somewhere?

I was able to reproduce that same behavior and yes, refreshForm seems to be a culprit.

Functions "refreshItem" and "refreshForm" are documented in both

and perhaps in 4.x as well,I do not have it handy to check.I apologize for the earlier post where I indicated functions as internal.I recommend you contact support.

cbilawchuk

I had the same problem with refreshForm(). I found that using refreshItem() only updated the changed items and didn't affect the rest of the form and solved the problem. I modified the generic callout javascript to as follows:

var calloutElementFound = false;
for ( i = 0 ; i < calloutForm.elements.length ; i++ )
{
if (calloutForm.elements.name == '$element_name')
{
calloutForm.elements.value = selectedValue;
opener.top.datacapture.refreshItem(calloutForm.elements);
calloutElementFound = true;
}
}

if (!calloutElementFound)
{
return false;
}

ISCBorisB

I had the same problem with refreshForm(). I found that using refreshItem() only updated the changed items and didn't affect the rest of the form and solved the problem. I modified the generic callout javascript to as follows:

var calloutElementFound = false;
for ( i = 0 ; i < calloutForm.elements.length ; i++ )
{
if (calloutForm.elements.name == '$element_name')
{
calloutForm.elements.value = selectedValue;
opener.top.datacapture.refreshItem(calloutForm.elements);
calloutElementFound = true;
}
}

if (!calloutElementFound)
{
return false;
}

All this jazz is obsolete. IMHO unless you maintain legacy code you would be better off using *new style* FormAPI callout.
In this fashion you'll need neither refreshItem/Form nor redraw (99% of the time, anyway)

nickyboy

Just wanted to say tank you for the solution in this article. It saved me a couple of hours of head scratching and document reading. Thank you.

I will also add that legacy code is a relative concept. Most of the code I write is with the new formAPI and call back functions and it works great, we are populating records automatically from a third party tool by using call back functions so it's powerful, but apparently IW consultants still prefer the old legacy way - the code I just had to fix was written by IW consultants no longer than 6-8 months ago on a 6.5 system - go figure...

Again thanx.
DT.

BIRT2010-07-16 08-04-27.png

cliffhanger

Setting: TS 6.5 SP2 (without Patch) on a Windows 2000 Server.

My DCT has a replicant (see the DCT attached). It also has a callout (see the script attached). I've stripped down the script in hopes of finding the problem. It seems to revolve around "opener.top.datacapture.refreshForm()." In a DCR, it seems to change the Report field of the 3rd instance of the Reports replicant to be the same as the repName of the 1st replicant instance, if I follow these steps:

1. Create 3+ Reports instances, making the 3rd Report different than the 1st Report

2. Save

3. Click the callout button

4. Click Submit in the callout window

5. Save

6. Refresh

The 3rd Report (e.g., "Round Table Quota Report") gets changed to be the same as the 1st Report (e.g., "Circle of Honor Report / Net Gain Goal Report"). See the DCR attached.

Incidentally, the 5th Report instance was being affected by this malady originally. After I removed a date field in the replicant, the 4th Report instance was being changed. Finally I removed the 1st field in the DCT (which was outside the replicant) and now the 3rd Report instance is being changed.

It's so curious. There's no FormAPI involved that I know of. Is it possible that the Save button has been customized somehow? Is there a bug
somewhere? Or is the problem between my chair and keyboard?

I suppose I could try opener.top.datacapture.refreshItem(), but I'd like to understand what's going with opener.top.datacapture.refreshForm().

Any comments will be appreciated!

S.

Thanks for bringing it up here, I spent a good number of hours on this issue, and now see that I am not the only one who had this issue!! It confirms that I am not going nuts Smiley Happy

nipper

Thanks for bringing it up here, I spent a good number of hours on this issue, and now see that I am not the only one who had this issue!! It confirms that I am not going nuts

No, you still may be going nuts, but there is a bug. :-)

Remember, just because you are paranoid, it doesn't mean they are not out to get you.