Changes made by callout not recognized?

Hi there, this is with TS 6.7.1 on Solaris.

I have some required fields that are populated via a callout.
When I try to save the DCR with any of these fields being empty the DCR is not saved but a warning message appears at the bottom of my window and all missing fields are highlighted. So far this is standard TS behaviour.

However, if I now use the callout to populate the required fields, the highlighting is not removed, even though the fields are not empty anymore. Thus, I am still not able to save the DCR.
Only after I've stepped through each of the affected fields, their highlighting is being removed one by one, letting me finally save the DCR.

Is this a bug or a feature? And is there a way around it?
Thanks.

Find more posts tagged with

Comments

nipper

Are you using FormAPI ? If so, turn it off & see if this is still the case. Did you load SP1 ? I am using 6.7.1 with callouts and no trouble (on DOS however).

moonkhanna

I see a similar issue. the onchange event is not registered when you populate fields using a callout. I feel this should be a bug..

Adam Stoller

I see a similar issue. the onchange event is not registered when you populate fields using a callout. I feel this should be a bug..

This has long been the case - and while it might be nice to call it a bug, most likely IWOV will consider it a FR - so you're best bet is to call your event handler functions yourself after populating the fields via the callout.

ISCBorisB

I feel this should be a bug..

Lot's of various System Designers would disagree. Matter of fact, none of the GUI I recall fired onChange Event
when a field was changed programmatically. That includes Windows, X Window, JavaScript, Forté, VB, to name a few.
(Some systems allow you to "Force Fire" certain events programmatically. I consider that a separate issue. You still
have to code for it).

Pros and cons of such designs are debatable, my only point is that declaring it a bug (or even "IWOV Bug"!) may
be a bit premature.

tobias

so you're best bet is to call your event handler functions yourself after populating the fields via the callout.

Unfortunately there is no real event handler function attached to these fields. It's the basic the-required-field-is-not-empty-anymore-so-remove-highlighting functionality that would have to be called. But I don't think there is such a method or function, right?
Or is there something like a "re-check form validity" method? I tried to find it in the manual, but couldn't.

Anyway, since the event handler is called "onItemChange" (and not "onManualItemChange") I would indeed consider the current situation a bug.

Thanks for sharing your thoughts and experiences.

ISCBorisB

But I don't think there is such a method or function, right?

Sure is. Validity check/set is per Item, not per Form though. Error highlight and Messaging functionality is on the Form.
Take a look at IWItem.isValid(), IWItem.setValid(), IWDatacapture.setHighlightMode() and and IWDatacapture.displayMessage()

moonkhanna

Lot's of various System Designers would disagree. Matter of fact, none of the GUI I recall fired onChange Event
when a field was changed programmatically. That includes Windows, X Window, JavaScript, Forté, VB, to name a few.
(Some systems allow you to "Force Fire" certain events programmatically. I consider that a separate issue. You still
have to code for it).

Pros and cons of such designs are debatable, my only point is that declaring it a bug (or even "IWOV Bug"!) may
be a bit premature.

Good find.. Well, i agree, even I have not seen many systems recognising this and this should be considered a FR. My only point was that it is there and biting .. :-)

ISCBorisB

Good find.. Well, i agree, even I have not seen many systems recognising this and this should be considered a FR. My only point was that it is there and biting .. :-)

Shouldn't be that big of a deal. As pointed earlier:

...you're best bet is to call your event handler functions yourself after populating the fields via the callout

I did exactly that many times before, just do not forget to pass required IWItem Object as a parameter

tobias

Take a look at IWItem.isValid(), IWItem.setValid(), IWDatacapture.setHighlightMode() and and IWDatacapture.displayMessage()

Hi Boris,
I'm aware of these FormAPI functions but I don't see a way of calling any of them from my Perl callout. Since this callout generates HTML and JS out of the "regular" DCT I don't have access to these FormAPI-specific functions.
All I get when I try to call let's say setValid() is the following JS error: "calloutForm.elements.setValid is not a function"

ISCBorisB

Hi Boris,
I'm aware of these FormAPI functions but I don't see a way of calling any of them from my Perl callout. Since this callout generates HTML and JS out of the "regular" DCT I don't have access to these FormAPI-specific functions.
All I get when I try to call let's say setValid() is the following JS error: "calloutForm.elements.setValid is not a function"

The above "calloutForm.elements..." is a fragment of the legacy pre-FormAPI code for callout scripts to communicate with the opener Form.

Today you may code all your *callback* functions within DCT Form using any FormAPI method you wish. From your callout then
you use 'getScriptFrame' function to obtain a reference for the Frame that contains your Functions. Something like that:


var api = opener.top.getScriptFrame();
if (api) {
   api.YourCallback_0(...);
   api.YourCallback_1(...);
   ...
}
else {
   alert("Oh, Oh...");
}

See FormAPI Developer’s Guide for some details, note that getScriptFrame usage samples there are for the callServer and call's
syntax differs slightly (you do not have opener, etc)