Loading ...
Sorry, an error occurred while loading the content.

Re: [OLmws] Re: Crossframe and XP SP2

Expand Messages
  • Foteos Macrides
    ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Monday, September 13, 2004 12:00 PM Subject: [OLmws] Re: Crossframe and XP SP2 ...
    Message 1 of 15 , Sep 13, 2004
    • 0 Attachment
      ----- Original Message -----
      Sent: Monday, September 13, 2004 12:00 PM
      Subject: [OLmws] Re: Crossframe and XP SP2
       
      --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
      I was able to access your reduced set without any problems.  My earlier problem had to do with the way that IE was set up.  I previousely had a dialup service and recently switched to a a DSL connection and the previous setup was no longer applicable with the new service.  A quick call to my ISP this morning got me straightened out and going.  I moused over all of the links in your right most frame including the bottom link which setup an exclusive popup in the second frame.  I then clicked on your link in the second frame to reload it with the second file and went back to the links in the right hand frame.  They all seemed to work except for the popups in the second frame.  They were displayed but were hidden by the select box in that frame.  Try restoring your previous setup and I'll rerun it again in IE6 on my Win XP SP2 setup and let you know the results.

      Bob
       
      I was going to restore it in stages, but OK, I restored the whole ball of wax.  If you run into problems and it's not obvious which plugin is the culprit, we can go back to restoring it one plugin at a time.
       
      Regarding principles we can draw at this point about writing javascript for IE on WinXP SP2, we indeed can test whether an old over pointer (i.e., after navigation) is equal (==) or not (!=) to a fresh pointer to the overDiv layer.  What's not yet clear is whether we can do something like if (typeof over.style == 'undefined') with the old pointer and not get a denial of access (I suspect that is a problem with IE on WinXP SP2).
       
      Fote
      --
       
    • Robert E Boughner
      ... earlier problem had to do with the way that IE was set up. I previousely had a dialup service and recently switched to a a DSL connection and the previous
      Message 2 of 15 , Sep 13, 2004
      • 0 Attachment
        --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
        > ----- Original Message -----
        > From: Robert E Boughner
        > To: overlibmws@yahoogroups.com
        > Sent: Monday, September 13, 2004 12:00 PM
        > Subject: [OLmws] Re: Crossframe and XP SP2
        >
        > --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>
        wrote:
        > <snip>
        > http://www.macridesweb.com/oltest/CrossFrame/
        > >snip>
        > I was able to access your reduced set without any problems. My
        earlier problem had to do with the way that IE was set up. I
        previousely had a dialup service and recently switched to a a DSL
        connection and the previous setup was no longer applicable with the
        new service. A quick call to my ISP this morning got me straightened
        out and going. I moused over all of the links in your right most
        frame including the bottom link which setup an exclusive popup in the
        second frame. I then clicked on your link in the second frame to
        reload it with the second file and went back to the links in the right
        hand frame. They all seemed to work except for the popups in the
        second frame. They were displayed but were hidden by the select box
        in that frame. Try restoring your previous setup and I'll rerun it
        again in IE6 on my Win XP SP2 setup and let you know the results.
        >
        > Bob
        >
        > I was going to restore it in stages, but OK, I restored the whole
        ball of wax. If you run into problems and it's not obvious which
        plugin is the culprit, we can go back to restoring it one plugin at a
        time.
        >
        > Regarding principles we can draw at this point about writing
        javascript for IE on WinXP SP2, we indeed can test whether an old over
        pointer (i.e., after navigation) is equal (==) or not (!=) to a fresh
        pointer to the overDiv layer. What's not yet clear is whether we can
        do something like if (typeof over.style == 'undefined') with the old
        pointer and not get a denial of access (I suspect that is a problem
        with IE on WinXP SP2).
        >
        Okay I'll test out the page again and let you know the results. With
        reqard to your previous comment, yes you can check whether the pointer
        is == or != to a fresh pointer to the overDiv layer but you cn't tell
        whether that layer is in the source or target frame because they'll
        both give the same result. I do not suspect that can try something
        like you suggest because it will give you an access denied error.
        However, I've tried just with if (over) alert('typeof: ' + typeof
        over) and what I got was an object for that. I'll try it again and
        make sure that was happening and let you know.

        Bob
      • Foteos Macrides
        ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Monday, September 13, 2004 4:49 PM Subject: [OLmws] Re: Crossframe and XP SP2 ...
        Message 3 of 15 , Sep 13, 2004
        • 0 Attachment
          ----- Original Message -----
          Sent: Monday, September 13, 2004 4:49 PM
          Subject: [OLmws] Re: Crossframe and XP SP2
           
          --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...>wrote:
          Fote, just before that statement that you talked about before I put in a statement to print out some things after a renavigation of my two frame setup and what I got is shown in the attached screen shot on IE6 WinXP SP2 [sent by private email because the Yahoo groups archive does not retain attachments].  As you can see over has no value but it is an object but it reports that over.style is of unknown type  (incidentally you can check for this using typeof over.style == 'unknown' and you don't get an error message and it reports true for this condition.

          Also rechecked your full crossframe page and had no problems with it at all on my IE6.0 WinXP SP2 machine.

          Bob
           
          I'm glad the access problem you had yesterday with IE on WinXP SP2 was with your ISP setup, not my code, and that there in fact are no apparent crossframe support problems for that browser and platform with the current overlibmws code set.  Thanks for checking that out.
           
          Regarding the "programming for WinXP SP2" issues, whenever the over pointer is set to o3_frame.document.all['overDiv'], it automatically has a style object associated with it, and so
           
          if (over) alert('typeof over.style='+over.style);
           
          will report 'object' normally.  That had remained so even if over were pointing to the overDiv container in a prior document, i.e., that is now gone due to navigation in the relevant frame.  The change for WinXP SP2 appears to be that it instead reports 'unknown' meaning that it has not been changed to 'undefined' but by virtue of the changes in object caching you no longer can access it and know what it is. :<)
           
          The next important question is "What about over.scroll?"  In contrast to style, our scroll object is not automatically added to over. but is an object we add programmatically to over only if the SCROLL command (for overlibmws) or the FOLLOWSCROLL command (for the "Erik and Bob" code sets) was included in an overlib function call.  So normally over.scroll has a typeof of either 'undefined' or 'object'.  But does it also become 'unknown' on WinXP SP2 for an over that has been defined but can't be accessed due to navigation?  Because I didn't yet know the answer to that question, I avoided a crossframe scrolling problem for IE on WinXP SP2 by other means, apparently successfully based your not having any problems with the test suite at the above URL.  But you would be wise to take my heads up about problems on navigation for your followscroll plugin, because it still looks to me that it could have problems.
           
          Regarding the heads up I gave you about your shadow plugin which you think you tested and ruled out, you did not test it properly, and have not in fact ruled it out.  You need to actually look at your code and think it through before designing and trying to draw any valid inferences from such tests.  Your hook in the core module's hideObject function to your shadow plugin is for a cleanup operation if SHADOWOPACITY had been set to a value for semi-transparency of the shadow.  In your test there was "no indication of any errors" because you must have left the shadow fully opaque, thereby blocking that cleanup operation.
           
          The problem is in your shadow plugin's cleanUpBrowserOpacity(lyr) function, which you created on August 13, 2004 (according to your change log:) in an effort to incorporate into the "Erik and Bob" code sets my August 9, 2004 (according to my change log: http://www.macridesweb.com/oltest/changeHistory.html) enhancements of opacity handling in the overlibmws code set.  It is obvious (at least to me :<) simply from looking at your code that if you include a SHADOWOPACITY value for semi-transparency of the shadow, then IE will give you a prominent indication of an error in your test.
           
          Also note that Jon Burke's assertion that opacity was implemented by Microsoft only for IE v5.5 or higher is not correct.  As explained at the msdn developers knowledge base, it was implemented in IE v4.0, but a different way of handling it was added as of IE v5.5.  The 'Erik and Bob" code sets are using the procedure that is specific for IE v5.5 or higher, and that is why it doesn't work for Jon's clients with v4.0.  In contrast, the handling of opacity in overlibmws is set up to work as intended for IE v4.0 and v5.0 as well as v5.5 and v6.0.
           
          I hope the above information is helpful to you, and if your can answer my question about over.scroll please do.
           
          Fote
          --
           
        • Robert E Boughner
          ... ... contrast to style, our scroll object is not automatically added to over. but is an object we add programmatically to over only if the SCROLL
          Message 4 of 15 , Sep 14, 2004
          • 0 Attachment
            --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
            <snip>
            >
            > The next important question is "What about over.scroll?" In
            contrast to style, our scroll object is not automatically added to
            over. but is an object we add programmatically to over only if the
            SCROLL command (for overlibmws) or the FOLLOWSCROLL command (for the
            "Erik and Bob" code sets) was included in an overlib function call.
            So normally over.scroll has a typeof of either 'undefined' or
            'object'. But does it also become 'unknown' on WinXP SP2 for an over
            that has been defined but can't be accessed due to navigation?
            Because I didn't yet know the answer to that question, I avoided a
            crossframe scrolling problem for IE on WinXP SP2 by other means,
            apparently successfully based your not having any problems with the
            test suite at the above URL. But you would be wise to take my heads
            up about problems on navigation for your followscroll plugin, because
            it still looks to me that it could have problems.
            >
            To answer your question here Fote, it appears that because of
            navigation in IE under Win XP SP2, the over object remains defined
            (although it has no value) and it is of type object, none of its
            properties like over.id, over.scroll, over.style have a known type at
            all. (A typeof YYYY where YYYY is one of the above all report
            'unknown'). I made use of this fact to change how I treat that now.
            Basically I changed the line if (over) cClick(); at that beginning of
            the overlib routine (at about line 250) to the following:

            if (over) {
            over = (typeof over.id != 'string') ? null : over;
            if (over) cClick();
            }

            which should only affect IE under WinXP SP2 since only that will
            report the typeof over.id in this case to be 'unknown'. Thus the over
            object is reinitialized to null just as if it is starting a new. Some
            tests in IE, Netscape 7.2, and Opera 7.54 indicate no problems with
            this approach. Incidentally when using this I've removed the line
            that I had previously inserted into the hideObject() function.
            >
            > Regarding the heads up I gave you about your shadow plugin which you
            think you tested and ruled out, you did not test it properly, and have
            not in fact ruled it out. You need to actually look at your code and
            think it through before designing and trying to draw any valid
            inferences from such tests. Your hook in the core module's hideObject
            function to your shadow plugin is for a cleanup operation if
            SHADOWOPACITY had been set to a value for semi-transparency of the
            shadow. In your test there was "no indication of any errors" because
            you must have left the shadow fully opaque, thereby blocking that
            cleanup operation.
            >
            > The problem is in your shadow plugin's cleanUpBrowserOpacity(lyr)
            function, which you created on August 13, 2004 (according to your
            change log:) in an effort to incorporate into the "Erik and Bob" code
            sets my August 9, 2004 (according to my change log:
            http://www.macridesweb.com/oltest/changeHistory.html) enhancements of
            opacity handling in the overlibmws code set. It is obvious (at least
            to me :<) simply from looking at your code that if you include a
            SHADOWOPACITY value for semi-transparency of the shadow, then IE will
            give you a prominent indication of an error in your test.
            >
            Thanks for this reminder. I had forgotten about this totally and with
            my earlier change I do get a "Permission denied" error for both the
            shadow and followscroll plugins. However, I now no longer get that
            error with the new approach to handling this case. I guess further
            testing will reveal whether it does indeed do the job.
            >
            > Also note that Jon Burke's assertion that opacity was implemented by
            Microsoft only for IE v5.5 or higher is not correct. As explained at
            the msdn developers knowledge base, it was implemented in IE v4.0, but
            a different way of handling it was added as of IE v5.5. The 'Erik and
            Bob" code sets are using the procedure that is specific for IE v5.5 or
            higher, and that is why it doesn't work for Jon's clients with v4.0.
            In contrast, the handling of opacity in overlibmws is set up to work
            as intended for IE v4.0 and v5.0 as well as v5.5 and v6.0.
            >
            > I hope the above information is helpful to you, and if your can
            answer my question about over.scroll please do.
            >
            Yes your information has been very helpful to me. The dialog these
            past few days shows that we can have some really productive and
            fruitful discourses if we both remain civil to one another and don't
            interdict one's inuendo's into the discussion.

            Bob
          • Foteos Macrides
            ... From: Robert E Boughner To: overlibmws@yahoogroups.com Sent: Tuesday, September 14, 2004 4:53 PM Subject: [OLmws] Re: Crossframe and XP SP2
            Message 5 of 15 , Sep 15, 2004
            • 0 Attachment
               
              ----- Original Message -----
              Sent: Tuesday, September 14, 2004 4:53 PM
              Subject: [OLmws] Re: Crossframe and XP SP2
               
              <snip>
              Basically I changed the line if (over) cClick(); at that beginning of the overlib routine (at about line 250) to the following:

              if (over) {
               over = (typeof over.id != 'string') ? null : over;
               if (over) cClick();
              }
               
              which should only affect IE under WinXP SP2 since only that will report the typeof over.id in this case to be 'unknown'. 
              <snip>
               
              I'm sorry to say IMHO that is a bad programming strategy.  You've created the situation in which if it is IE on WinXP SP2 and there has been navigation, you completely by-pass all of the mop-up operations in cClick(), hideObject(), and any plugins.  But for IE on earlier Wintel systems and for all the other supported browsers and platforms you still do all of the mop-up operations, including ones that involve manipulation of an obsolete over pointer.  If you have good reason to believe that it is OK not to do any of the mop-up operations (e.g., canceling any outstanding timer operations, and resetting flags that have nothing directly to do with the over pointer) when there has been navigation, then you shouldn't do it for any of the browsers and platforms.  But making such a change in a mindlessly selective way to avoid an access denied error for IE on WinXP SP2, while knowing that obsolete pointers will continue to be used for the other browsers and platforms and that other cancellations and resets will still be done for them but not IE on WinXP SP2, is the kind of "trial and error" rather than "logic and principles-based" programming strategy that already has introduced too much crapolla in the "Erik and Bob" code sets.  I say that not to offend you personally, but out of my own strong distaste for that kind of programming strategy.  In any case, that's not how I'm dealing with this issue in overlbmws.
               
              I at this point have expanded my crossframe support test suite:
               
               
              so that it uses all of the overlibmws plugins except debug and function.  Could you play with it again, and in particular try the crossframe secondary popups via the primary popups in Frame [2] and Frame [3][1] (before and after navigation)?  That's hairy enough that I'm not certain I've eliminated all access attempts for obsolete pointers.  Also, please check the consequences of navigation via the three new links at the bottom of Frame [2], using them when a popup was being displayed in Frame [2] via the links in Frame [3][0][1].  As complex as the test suite has become, it all works great with IE and other browsers on Win98.
               
              Fote
              --
            • Robert E Boughner
              ... report the typeof over.id in this case to be unknown . ... created the situation in which if it is IE on WinXP SP2 and there has been navigation, you
              Message 6 of 15 , Sep 16, 2004
              • 0 Attachment
                --- In overlibmws@yahoogroups.com, "Foteos Macrides" <fote@m...> wrote:
                >
                > ----- Original Message -----
                > From: Robert E Boughner
                > To: overlibmws@yahoogroups.com
                > Sent: Tuesday, September 14, 2004 4:53 PM
                > Subject: [OLmws] Re: Crossframe and XP SP2
                >
                > <snip>
                > Basically I changed the line if (over) cClick(); at that beginning
                of the overlib routine (at about line 250) to the following:
                >
                > if (over) {
                > over = (typeof over.id != 'string') ? null : over;
                > if (over) cClick();
                > }
                >
                > which should only affect IE under WinXP SP2 since only that will
                report the typeof over.id in this case to be 'unknown'.
                > <snip>
                >
                > I'm sorry to say IMHO that is a bad programming strategy. You've
                created the situation in which if it is IE on WinXP SP2 and there has
                been navigation, you completely by-pass all of the mop-up operations
                in cClick(), hideObject(), and any plugins. But for IE on earlier
                Wintel systems and for all the other supported browsers and platforms
                you still do all of the mop-up operations, including ones that involve
                manipulation of an obsolete over pointer. If you have good reason to
                believe that it is OK not to do any of the mop-up operations (e.g.,
                canceling any outstanding timer operations, and resetting flags that
                have nothing directly to do with the over pointer) when there has been
                navigation, then you shouldn't do it for any of the browsers and
                platforms. But making such a change in a mindlessly selective way to
                avoid an access denied error for IE on WinXP SP2, while knowing that
                obsolete pointers will continue to be used for the other browsers and
                platforms and that other cancellations and resets will still be done
                for them but not IE on WinXP SP2, is the kind of "trial and error"
                rather than "logic and principles-based" programming strategy that
                already has introduced too much crapolla in the "Erik and Bob" code
                sets. I say that not to offend you personally, but out of my own
                strong distaste for that kind of programming strategy. In any case,
                that's not how I'm dealing with this issue in overlbmws.
                >
                <snip>
                Fote, the whole purpose of this statement, as you have pointed out in
                an earlier post, was to handle the situation for popups in a
                crossframe situation. In all other statements this statement is not
                needed and its whole intent was to just set the visibility of the
                popup to hidden. The fact that it does other things too is just
                fortuitous. I just called a built in function rather than just
                turning off the visibility was to eliminate some code. If what I did
                there was offensive to you, you can change the statement:

                over = (typeof over.id != 'string') ? null : over;

                to

                over = (typeof over.id != 'string' && o3_frame != ol_frame) ?
                o3_frame.document.all['overDiv'] : over;

                and then just call cClick() after it without the check.

                But to answer your question, my rationale for going this route is
                because for this particular case where a page has been loaded into the
                frame where the popup was being shown, the popup is wiped out as if it
                had already been closed and the rest of the program functions as if
                the value of over were null just like the first time that it is
                called. All of the functions should be set up to handle this situation.

                In addition, what comes after this in the overlib code is to
                re-instanstiate a new over popup with new properties and timers as
                such. What was there before doesn't make any difference. In this
                reqard, the same approach can be taken with all of the other browsers
                but for them, I couldn't come up with a way to tell whether navigation
                has occurred. Maybe this discussion will be helpful in that regard.

                Bob
              Your message has been successfully submitted and would be delivered to recipients shortly.