How can a screen identify its parent in all cases?

[trbjr]

Here is my scenario:

Screen A ===> Screen B ===> Screen C
\\
\\
V
Screen C

What this means is that sometimes Screen A opens B that opens C; other times Screen A opens C directly and B is not used.

The question is: How does C always know who opened it -- A or B? This is essential to know for later processing.

I have tried passing an ID value from A to C and from B to C so C can know its parent, but I always run into the problem of the browser interpreter stating that the code-of-the-path-that-is-not-the-parent-this-time "has no properties" and that error causes processing to stop. So far the "try/finally" statement has not worked for me in bypassing this error.

What I really need is the ability to catch an error the interpreter identifies and let me safely defuse it so that processing continues.

If there is no such ability in Javascript, I need some fresh ideas how to do what I want without generating these processing errors.

Thanks to all who can help.

[acoder]

Why can't you just use window.opener? That should identify the parent window.

[trbjr]

Why can't you just use window.opener? That should identify the parent window.

I do use "window.opener.document.formname.field.value" for the path I am using and it works fine.

But the same code for the path that is not active for the opposite scenario is the path that the browser issues the message of "has no properties".

Screen C has code in it for both paths (opened by A; also, opened by B). It is the code for the non-active path that causes the browser to complain.

[acoder]

Screen C has code in it for both paths (opened by A; also, opened by B). It is the code for the non-active path that causes the browser to complain.

Ah, I see what you mean.

You could pass a parameter with the URL. If it's a server-side page, use GET parameter handling and if it's HTML, use location.search to parse the query string, e.g. "?pageB=1".

[trbjr]

Ah, I see what you mean.

You could pass a parameter with the URL. If it's a server-side page, use GET parameter handling and if it's HTML, use location.search to parse the query string, e.g. "?pageB=1".

That sounds interesting. I will try to remember that when I am working on a server side project. But this is all client side.

I have another idea that I am working on.

If I created a DOM object inside the body but outside the form, then the code "window.opener.document.fieldname.value", I am hoping, would work. As I see it now, there would be no unique form name that would confuse the browser. If Screen A and Screen B had the same field name, then Screen C should access that field based only on the browser knowing who the parent was (Screen A or B).

If that works, then the value in the field would tell Screen C who the parent was, because Screen A and B would place differing values in the field.

This idea hinges on being able to set up a same named field in both screens outside the form. If "window.opener" works only if a field is inside a form, then I am back to the beginning again.

I am trying to research this now using Javascript the Definitive Guide by David Flanagan.

Let me know your reaction to this tack.

[acoder]

If I created a DOM object inside the body but outside the form, then the code "window.opener.document.fieldname.value", I am hoping, would work. As I see it now, there would be no unique form name that would confuse the browser. If Screen A and Screen B had the same field name, then Screen C should access that field based only on the browser knowing who the parent was (Screen A or B).

If that works, then the value in the field would tell Screen C who the parent was, because Screen A and B would place differing values in the field.

This idea hinges on being able to set up a same named field in both screens outside the form. If "window.opener" works only if a field is inside a form, then I am back to the beginning again.

Fields should be inside forms. You can either have another form and put the field inside that form, or even better, just include it within the current form, but access by its id rather than the form notation, i.e. using document.getElementById. Then, there's no need to worry about form names.

[trbjr]

Fields should be inside forms. You can either have another form and put the field inside that form, or even better, just include it within the current form, but access by its id rather than the form notation, i.e. using document.getElementById. Then, there's no need to worry about form names.

I like the getElementById suggestion. But even using that it seems to me (without having tried it) that I would still have the same problem I have now. Screen C still has to know its parent on each usage cycle. That means I put code in C to handle both Screen A and B as parents.

Whichever parent is the real path, won't the code for the non-active, opposite path still get the "has no properties" error?

===============================================

Here's an idea that research turned up. What do you think of it?

Flanagan in Javascript the Definitive Guide (item 15.3.1) says that if two document elements have name attributes with the same value, the document property becomes an array that holds references to both elements.

Supposing I named Screens A and B with the same name. That should get rid of the interpreter's "no properties" error message. I would then have to analyze the values inside the array to determine whether A or B was the parent of C.

It sounds pretty slick, but I wonder if Flanagan is talking about naming two different screens with the same name or two elements within one screen. I suspect the latter.

[acoder]

Can you post the part of the code which is causing the problem, so I can see what check you're making.

[trbjr]

Can you post the part of the code which is causing the problem, so I can see what check you're making.

When I went to show you the code for Screen 3, I found that it had changed from the time of the initial posting. Right now I cannot show the original code that caused me to make the initial posting.

What I have now is code that works for the path that goes from screen 1 to 2 to 3. When I am on the alternate path (screen 1 to 3), the code that references the first path is still in the program and the explicit reference to screen 2 generates the error, because screen 2 is not in the path used and so is not identified as the parent.

In the comments: adp2 = screen 1, adpvisa = screen 2, adp3 = screen 3
In the code below the word "visaform" is the form name of screen 2.

 
function whoIsParent() {  // determine if apd3 is opened by adp2 or by adpvisa
        try {
        f3choice = window.opener.document.visaform.visaopen.value;
        }
        finally {    
            if  (f3choice == 'V') {               //  'V' = visa authorization
                threeopenedbyvisa = "Y";    //  adp user in US via visa
                threeopenedbytwo = "N";
            }
            else {
                threeopenedbytwo = "Y";     // this means adp user not in US via visa
                threeopenedbyvisa = "N";
            }
        }
    }
 

Over the week-end I thought more about the getElementById option and am working on that now. I hope to be able to report results later today.

[trbjr]

When I went to show you the code for Screen 3, I found that it had changed from the time of the initial posting. Right now I cannot show the original code that caused me to make the initial posting.

What I have now is code that works for the path that goes from screen 1 to 2 to 3. When I am on the alternate path (screen 1 to 3), the code that references the first path is still in the program and the explicit reference to screen 2 generates the error, because screen 2 is not in the path used and so is not identified as the parent.

In the comments: adp2 = screen 1, adpvisa = screen 2, adp3 = screen 3
In the code below the word "visaform" is the form name of screen 2.

 
function whoIsParent() {  // determine if apd3 is opened by adp2 or by adpvisa
        try {
        f3choice = window.opener.document.visaform.visaopen.value;
        }
        finally {    
            if  (f3choice == 'V') {               //  'V' = visa authorization
                threeopenedbyvisa = "Y";    //  adp user in US via visa
                threeopenedbytwo = "N";
            }
            else {
                threeopenedbytwo = "Y";     // this means adp user not in US via visa
                threeopenedbyvisa = "N";
            }
        }
    }
 

Over the week-end I thought more about the getElementById option and am working on that now. I hope to be able to report results later today.

==================================================

Over the week-end I thought more about the getElementById option and am working on that now. I hope to be able to report results later today.

Referring to the code above the "====" line, here is how I changed the "try" statement in screen 3:

 
        try {
        f3parcode = window.opener.document.getElementById("parcode").value;   
               // parcode carries value indicating parent
               // parcode is set in both screen 1 and screen 2
              }
 

The above gives me the error message:

"window.opener.document.getElementById("parcod e") has no properties"

Since the error message does not mention the ".value" part of the above code, is it incorrect to use ".value" with getElementById?

Or is the error that you cannot use getElementById with window.opener to get at a field in the parent?

Or is there something not apparent to me?

TIA

[acoder]

Since the error message does not mention the ".value" part of the above code, is it incorrect to use ".value" with getElementById?

It depends on whether the element has a value attribute or not. If it doesn't, you may need to use innerHTML. How do you define the element on the two pages?

[trbjr]

It depends on whether the element has a value attribute or not. If it doesn't, you may need to use innerHTML. How do you define the element on the two pages?

Today everything is working as desired. No error messages.

The only think I can think to explain this is that the browser was accessing older, saved versions of the screens rather than the updated ones. After each update I saved everything and refreshed the screens, I thought. Since things seemed not to work, I kept trying for new ideas.

Screen 1:

 
<input type="hidden" id="parcode" name="adp2open" value="2" axlength="1">
 
 

Screen 2:

 
<input type="hidden" id="parcode" name="visaopen" value="V" maxlength="1">
 
 

Thanks very much for all your time and support. I really appreciate it. Your idea of getElementById() was the key to successful processing combined with the idea of using the same name for parent code in the two screens.

[acoder]

You're welcome. Glad you got it working.

PS. To close the code tags properly, remove the space in [ /CODE].