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; } } }

Using callout code now, but I can't get cgi data.

bettineski

As per suggestions from this forum, I have been going through and updating some code that a previous developer had worked on. I'm now using form api vs. less recommended practices.

Here is the code that used to be in the cfg:

[html]

[/html]

and here is the update I made:
[html]

[/html]

This then calls this in my .js file:

[html]
window.open ("/iw-bin/pge_custom/price_summaries_calendar.ipl?selected_date_format=MM/dd/yyyy");
[/html]

Here's the issue I'm having now.

Because it's a different type of callout, the child window that is being opened appears to be losing track of it's parent.

Here is a piece of the child code:
[html]
use TeamSite::CGI_lite;
use CGI qw(:standard);

$cgi = TeamSite::CGI_lite->new();
$cgi->parse_data();

my $form_name = $cgi->{'form'}{'iw_form_name'};
my $element_name = $cgi->{'form'}{'iw_callback_var'};
[/html]

$form_name is null. In fact, all the variable are null.

Is there some way I can get the value of the iw_form_name with the new call out method I'm using?

Find more posts tagged with

Comments

ISCBorisB

You do not post to the CGI in this case and therefore there is no Form to Parse. Note that call-back Functions can help you in this
case as well. Need something from the Form? Code a call-back GetItemValue in the DCT and call it from CGI. Something like that:

function getItemValue(itemName) {
   var item = IWDatacapture.getItem(itemName);
   return (item)? item.getValue() : null;
}

That said, if you yourself want to navigate DC Form from the outside, the following (or similar) *should* give you an access:
opener.top.frames.formframe.document.forms.dcreditForm ( or perhaps opener.top.frames.formframe.document.forms[0] )

bettineski

I've essentially had to revert back to having the being done via the datacapture.cfg, because it's the closest to the solution I've been able to come.

The requirement is that the date picker window (yui_calendar.ipl - attached) behave the same as it does in other areas. This means that the cgi values have to be passed in.

I tried coding it via a call-out in the .js file, but when the child window opened, I was unable to find the parent/opener window.

ISCBorisB, your suggestion was to do call backs and use IWDatacapture.getItem. I couldn't find any way of doing a call back.

I'm thinking that as the yui_calendar window is opened it doesn't keep track of the parent/opener window somehow.

With the callout being in the datacapture.cfg, the calendar application actually works quite well. The issue is not knowing which replicant it was that called it.

Does that help to explain this situation a little better? If there's more code or detail you need, please let me know. I'm getting quite desperate.

Thanks!

ISCBorisB

The way I see it, you have several options.

1. Leave the existing Calendar, call it from DCT with CGI Callout ( eg, do not use FormAPI )
Obsolete methodology or not, this one works (does it?) and nobody said that you have to convert
all of them at once.

2. Modify existing Calendar to use get / set FormAPI callouts. If you take a look at our previous
Thread, you will see that you do not need any Form whatever to get *back* to FormAPI Function
Frame. As long as you have a valid opener (eg, you did not close Parent DCR) the following will work:
window.opener.api.YourCallback(YourParameters);

3. Create / Find another Calendar that uses callbacks in the first place. Take a look at [post=92779]this[/post] sample,
note that it's a hack though.

Makes sense?

bettineski

> 2. Modify existing Calendar to use get / set FormAPI callouts.
> the following will work: window.opener.api.YourCallback(YourParameters);

This has been driving me crazy, because I've seen it work in the past, as per your suggestions.

In my .js I have a basic function that simply has an alert("It works");

Yet calling it from the .ipl like this: window.opener.api.getItemValue();

Nothing happens.

The whole time I've been working with this Calendar app, its as if it doesn't know that the DCR is the window.opener.

That's why I'm so frustrated. I learned so much from the last thread that I was ready to employ it here and 'build it correctly.' But it's not working as expected Smiley Sad

ISCBorisB

> 2. Modify existing Calendar to use get / set FormAPI callouts.
> the following will work: window.opener.api.YourCallback(YourParameters);

This has been driving me crazy, because I've seen it work in the past, as per your suggestions.

In my .js I have a basic function that simply has an alert("It works");

Yet calling it from the .ipl like this: window.opener.api.getItemValue();

Nothing happens.

The whole time I've been working with this Calendar app, its as if it doesn't know that the DCR is the window.opener.

That's why I'm so frustrated. I learned so much from the last thread that I was ready to employ it here and 'build it correctly.' But it's not working as expected

Chances are, you have JS syntax error somewhere in your DCT FormAPI. If that's the case, DCR opens all right but any call
whatever to FormAPI functions is ignored, call-backs including. Alternatively, JS that you emit from your CGI may have
syntax errors, then this code is ignored by the Browser. So...

1. Check if any FormAPI function works in your DCR. Find the one that used to work and has not been modified and use it as
a guinea pig. If it doesn't work - look for JS Syntax Error.

2. Log-out CGI-generated code for review (or simply use "View Source"). Check JS Portion, save it as a local HTML File if needed.

bettineski

Ok, I have it passing information back to the parent window. It can now see it when I have this code in the datacapture.cfg:

[html]

[/html]

But when I have the callout like this:

[html]

[/html]

and the .js code like this:

[html]
window.open ("/iw-bin/pge_custom/price_summaries_calendar.ipl");
[/html]

It doesn't see window.opener as a vaild object.

My ultimate goal is to have a function in the DCR keep track of any and all replicants where this 'date picker' button is clicked.

Doing this on a normal callout is quite simple now, but doing this on a "callout url" seems to be near impossible.

ISCBorisB

Note that the opener is a standard DOM Object, it is absolutely not IWOV invention.

It's next to impossible to believe that somehow your child (CGI) window can't see it. All that is working in another CGI, isn't it?
You may have coding issues (logic, syntax, run-time error, whatever) in either DCT, CGI-generated code or both. You'd have to debug it.

Another consideration is the usage of YUI JS Libraries. That code *may* in theory reset an opener, either directly or through (for example)
transparently opening Calendar popup. If something like that is the case, you still have an opener. Problem is that it's not pointing to the
DC Form any longer! What happens if you temporarily remove/comment-out Yahoo stuff and leave just test call-back?

bettineski

If something like that is the case, you still have an opener. Problem is that it's not pointing to the
DC Form any longer! What happens if you temporarily remove/comment-out Yahoo stuff and leave just test call-back?

That's what I was worried about, the yui script causing the child to lose the parent. Is there some way of 'scanning' for all opened windows?

I have attached the .ipl file with all the calendar code totally stripped out, and when I click the 'hello' button I still get this error: "window.opener.api is null or not an object"

Yet, this exact code calls back to the parent perfectly fine if I set the datacapture.cfg to 'callout url.'

At this point, I'm thinking I might have just two options:

1: Figure out if it's possible to 'scan' for all open windows and try to find the DCT.

2: Use that 'hack' calendar that uses call outs that you posted.

Unfortunately, #2 requires client sign-off and that is usually harder then the coding Smiley Happy

Adam Stoller

That's what I was worried about, the yui script causing the child to lose the parent. Is there some way of 'scanning' for all opened windows?

I have attached the .ipl file with all the calendar code totally stripped out, and when I click the 'hello' button I still get this error: "window.opener.api is null or not an object"

Yet, this exact code calls back to the parent perfectly fine if I set the datacapture.cfg to 'callout url.'

At this point, I'm thinking I might have just two options:

1: Figure out if it's possible to 'scan' for all open windows and try to find the DCT.

2: Use that 'hack' calendar that uses call outs that you posted.

Unfortunately, #2 requires client sign-off and that is usually harder then the coding

I think you're suffering from some short-hand exchanges - it's not window.opener.api - you need to set api to window.opener.getScriptFrame() - or you may have to play around within various dereferences through window, opener, and parent to get to the place where you can access the call to getScriptFrame() - and then you can utilize that to access your FormAPI functions.

ISCBorisB

That's what I was worried about, the yui script causing the child to lose the parent. Is there some way of 'scanning' for all opened windows?

I have attached the .ipl file with all the calendar code totally stripped out, and when I click the 'hello' button I still get this error: "window.opener.api is null or not an object"

Yet, this exact code calls back to the parent perfectly fine if I set the datacapture.cfg to 'callout url.'

At this point, I'm thinking I might have just two options:

1: Figure out if it's possible to 'scan' for all open windows and try to find the DCT.

2: Use that 'hack' calendar that uses call outs that you posted.

Unfortunately, #2 requires client sign-off and that is usually harder then the coding

My apologies. The call-back syntax I gave you was a bit of a cavalier coding. Without undue details ( when it works and
when it does not ), try the following. This is actually IWOV supported syntax.

//window.opener.api.hello(); Commented out. Instead:
var api = window.opener.top.getScriptFrame();
api.hello();

bettineski

var api = window.opener.top.getScriptFrame();
api.hello();

Oh wow, that did it. The child is now talking to the parent when using the 'callout url' method.

So, is this api object actually the formapi object for the DCT, or is it just a javascript window object?

Let me rephrase.

Would this let me, in js, get the equivalent of this:

[html]
my $form_name = $cgi->{'form'}{'iw_form_name'};
[/html]

ISCBorisB

Oh wow, that did it. The child is now talking to the parent when using the 'callout url' method.

So, is this api object actually the formapi object for the DCT, or is it just a javascript window object?

This one is a FormAPI Object ( Actually, one of the six DC Form Window Frames )

bettineski

This one is a FormAPI Object ( Actually, one of the six DC Form Window Frames )

It is working.

I will post my working code when I'm all finished up.

Wow. Thank you.

dynamic.rptdesign

bettineski

Here's how I'm solving this issue.

Since I'm not doing a callout, I can't track which replicant has made the call. That's really the key to this, figuring out which replicant has changed.

What I've done instead is create a boolean flag (dateMayHaveChanged) in the DCT code so that when the calendar window is called, it sets it to true.

This way, when the form is saved, I know that one or more dates may have changed.

At this point, I'll loop through all the replicants looking for the change (I have a hidden field that hold the old date to compare with the new date).

Looks like this is going to work.

Slight hack, but if the clients are happy then it worked, right?

Thank you so much for the help!

muksm

Did you managed to resolve this issue. If yes than can you share the code with us.

bettineski

Did you managed to resolve this issue. If yes than can you share the code with us.

The code wouldn't make much sense, but I can tell you the logic of how I did it.

price_summaries.js file
In the .js file, I set a boolean flag "dateMayHaveChanged = false" at the very top.

This means that by default the form knows that no dates have changed, so don't bother looking for the changes later on when the form is saved.

I also put this function in the .js as well:

[html]
function setDateMayHaveChangedToTrue() {
dateMayHaveChanged = true;
}
[/html]

child_window.ipl

Then what I did was in my child window script (an .ipl file) is add this code:

[html]
var api = window.opener.top.getScriptFrame();
api.setDateMayHaveChangedToTrue();
[/html]

So, when this window is opened up, it calls the function in the .js that sets the boolean to true.

Then when I close my child window and save the form, it checks the flag to see if it's set to true. If it's set to true, it loops through every replicant looking at the date fields and looking for changes.

This way I avoid having to loop through the replicants every time. It only happens if there's the possibility of a date change.

See, all I know is that the child window has opened. I don't know if the value changed or not.

So, if the child window is opened, the flag is set to true, and I do the processing to see if anything happened.

Does that make sense?

Bit of a hack, but it works perfectly.