none
Bing Maps AJAX v7.0 Control Not Working Since this Morning RRS feed

  • Question

  • Hi,
    I've been working with the Bing Maps AJAX v7 control for a few months now.
    I ran my app this morning and none of the maps appeared - just blank
    pages - my code has not changed. I even tested an old version I had deployed elsewhere which is been working for months - it's now also broken.


    Digging deeper and playing with the styling, I got the control to
    render, and it said that my key was invalid.

    Doing the same playing around with the styling on the next page made
    the control appear (wrong dimensions), but no warning about the
    invalid credentials.


    I have tried creating a new Developer key and using that but I get the
    same result.

    Kind regards,

     

    Ashley

    • Moved by Ricky_Brundritt Friday, March 9, 2012 5:43 PM (From:Bing Maps: Map Control and Web services Development)
    Thursday, May 5, 2011 11:15 AM

Answers

  • Wow - wait a go MS - fantastic community involvement, you finally get everyone's attention by blowing up their own sites.

    Who came up with the brilliant idea of in place upgrades as opposed to just releasing a 7.1 script. The early 7.0 controls are so bad you'd think you'd wanna add a minor version to get everyone excited that maybe things are looking up. That way we could at least choose to move to the new version after countless hours of work arounds to make 7.0 half work across browser - instead of bringing down 3/4 of my site without telling me.

    CAN YOU PLEASE PROVIDE AN OLD SCRIPT REFERENCE SO THAT MY SITE WHICH WAS INTENDED TO GO LIVE NEXT WEEK AND IS NOW DELAYED DOES NOT PEND ON WHETHER YOU FALL APART COMPLETELY WITH THIS CODEBASE.


    Jonathon


    Hi Jonathon -

    There are two issues reported on new release which we are tracking.

    1. when map is placed in div without height/width, map does not appears - Though the recommended way is to give the width/height, we have fixed this issue & it would be live very soon (clear the cache, if you still get old version, new version 7.0.2011050604957.71). This should fix all issues related to map not visible.

    2. Object null error in case of FF/Chrome. Again, recommeded way is to call map API on body onload http://msdn.microsoft.com/en-us/library/gg427624.aspx). this would fix all issues related to chrome/FF

    we have released new features in this reealse, check them out http://msdn.microsoft.com/en-us/library/gg675211.aspx. Hope you would be excited. In future, we would make sure we don't break exisitng customer. Thanks for feedback.

     

     

    We have added couple of new features in this release.

     

     
    • Proposed as answer by Justin_T Saturday, May 7, 2011 1:14 AM
    • Marked as answer by Ricky_Brundritt Wednesday, May 18, 2011 6:17 PM
    Saturday, May 7, 2011 1:05 AM

All replies

  • Well,

    I did noticed a new bug on the control today. It seems that if you rely on a parent container for the map dimension,  something like:

     

    <div id='mapContainer' style="width:xx; height:xx">

          <div id='map'></div>

    </div>

     

    it no longer "stretches" to the parent container like it used to. Now you have to put the size on the map div itself.

    Thursday, May 5, 2011 11:54 AM
  • Hello,

    I too am experiencing the blank map effect in my application.  At first I thought it was something I did, but now I am thinking that there was an update.


    derek
    Thursday, May 5, 2011 12:06 PM
  • It looks like there has been a recent update. If you're experiencing any problems then I suggest posting a link to the URL of your map to let others help to reproduce/diagnose what's wrong.
    twitter: @alastaira blog: http://alastaira.wordpress.com/
    Thursday, May 5, 2011 12:14 PM
    Moderator
  • Indeed, there was a new version but it seems to be a minor update, so it's more a bug-fix version that might not impact any code if you respect what is recommended in the MSDN or official documentation.

    It seems to be compiled on April 26th (as far as it is described in the source), see the reference to the script:

    7.0.20110426171249.81

    A couple of new things are inside it, but I don't have the time to make a kind of change list.
    I also notice the change in the behaviour while panning the map (inertia) and it fix the scroll bug.

    It seems to have information about blockview and other things about streetside, but we will wait for more official information.


    MVP - Bing Maps - My blog (FR): http://blogs.developpeur.org/nicoboo/ Twitter: http://twitter.com/nicolasboonaert/
    Thursday, May 5, 2011 12:19 PM
    Moderator
  • We also found some issues with our app this morning, there were intermittently errors due to functions being undefined at the time we tried to use them. e.g. calling the Microsoft.Maps.Map function would work but then trying to use Microsoft.Maps.Location immediately afterwards would fail. We've made some changes to try to ensure all the Bing Maps functions have loaded before using them and this has got things working again but everything was working reliably before today.
    Thursday, May 5, 2011 1:03 PM
  • I am also getting a lot of intermittent errors this morning that seem to be related to bing map functions not being fully loaded.

     

    Something as simple as:

    var MM = Microsoft.Maps;

    var mapType = MM.MapTypeId.aerial;

     

    Throws Uncaught TypeError: Cannot read property 'aerial' of type undefined.

    The application was function perfectly before this morning.

     

    Assuming that going forward you will not be able to rely on the Map functions being fully loaded after including in the mapcontrol.ashx script, how would you determine that the functions are completely finished?


    Thursday, May 5, 2011 1:20 PM
  • They should add a callback (jsonp) method that we can set on the url like we had on v6 during a time.
    In this way the callback would be fired once all dependencies would be loaded. We asked for this feature.
    MVP - Bing Maps - My blog (FR): http://blogs.developpeur.org/nicoboo/ Twitter: http://twitter.com/nicolasboonaert/
    Thursday, May 5, 2011 1:25 PM
    Moderator
  • I've always found it slightly odd that the v7 library doesn't include a onLoadMap property as v6.3 did, which might help alleviate some of these timing issues if they relate to trying to use methods on the map before it's fully initialised etc. <touch wood> I've never actually experienced these myself, but it certainly seems from the feedback here that there is the potential for timing issues to affect the v7 control. We really don't want people inserting setTimeOuts everywhere to arbitrarily wait for a time when they think it's safe to execute the next line of code!

    @Matt - could you describe in any more detail the changes that you made which fixed the intermittent problems you were having? I'm sure others might find them helpful, and intermittent errors are always the tricksiest to diagnose and fix ;)


    twitter: @alastaira blog: http://alastaira.wordpress.com/
    • Proposed as answer by Hemant Goyal Friday, May 6, 2011 12:56 AM
    Thursday, May 5, 2011 1:27 PM
    Moderator
  • I wouldn't describe any of our changes as reliable or particularly nice but added together they seem to have at least stopped the errors in the vast majority of cases. We haven't seen them internally since and we've had no error reports from our users since implementing them either.

    All the changes have been to allow as much time as possible for the Maps code to load. As part of fixing the IE issue we were having we have swtiched to using $(window).load instead of $(document).ready, as this was originally just to fix IE we were only going to use it for that but switched to using it for all browsers today as it gives a bit more time before running our scripts.

    Normally we load all scripts at the bottom of the page so as to optimise page load/render. We have now moved the load of the Bing Maps API as high up the page as possible with all other scripts (i.e. the ones that then use it) still loaded at the bottom.

    We also wrapped up some functions we were running that used the API so that we could call them after the map has been added to the page, again with the plan of leaving interacting with the API as late as we could by doing as much as we could before this.

    So none of this is a reliable fix but it seems to be working for now and is giving us time to look at this further and try to come up with a reliable, long term fix.

    Thursday, May 5, 2011 1:39 PM
  • Update:

     

    Moving any calls to Map functions into jQuery's (document).ready or (window).load functions seems to (for the moment) fixed the issues I was seeing.

     

    Of course a callback method would be the most helpful solution :)

    EDIT: Matt beat me to it :)
    Thursday, May 5, 2011 1:41 PM
  • Hi,

    I also experienced the problem on my application. Actually the easiest fix for this issue is move all of your initialisations (any map related variables) in/after document ready. I could fix all my issues by doing this. Hope this helps. Thanks. 


    Regards, Uday
    • Proposed as answer by denduluri Friday, May 6, 2011 9:34 AM
    • Unproposed as answer by Ricky_Brundritt Wednesday, May 18, 2011 6:16 PM
    Thursday, May 5, 2011 2:13 PM
  • Perhaps someone can help me out w/ this.  I was using a map div tag w/ out any reference to width or height (e.g. <div id="MainMap"></div>

     and it was working find until this morning.  My reasoning for doing this was that I am defining all of the position in css and I want to be able to print very large poster size maps.  Is it the case that we now have to define a width and height for the map div tag?

     

    Thanks for any feedback,


    derek
    Thursday, May 5, 2011 3:00 PM
  • Yeap... receiving tons of complains from users that it's not loading.

    Experiences with this control just get better and better.


    Jonathon
    Thursday, May 5, 2011 3:55 PM
  • Same issue here, we resolved by explicitly providing the map size during creation of the control. Not the best solution as it prohibits many other capabilities but at least our users are now able to see the map again...
    Thursday, May 5, 2011 5:58 PM
  • I am not sure how to work around this in my case.  I was relying on the map sizing up to the size of 100% per the css

    @media print {

     #MainMap {

      height:100%;

     }

    }

    So that I could fit it to a much larger print paper size (poster size).  It was working great.  Now I find if I provide a map div height and width it only prints what is on the screen.  Whereas before I was able to print parts of the map that exceeded the size of the screen.  I hope this makes since to someone who may be able to help.

     

    Thanks,


    derek
    Thursday, May 5, 2011 8:41 PM
  • Today's patch that further delayed loading has broken a lot of sites, in some really inconsistent ways.  Is this change going to stay live? Is there no alternative but to delay my own initialization?

    This is really, really disappointing.

    Thursday, May 5, 2011 10:04 PM
  • Thanks for reporting this issue.  We have been able to reproduce this and are activing investigating the issue.  Please keep reporting any issues that you  see as we really appreciate the feedback from the community.

     

    Thanks,

     

    Justin

    Bing Maps Team

    Friday, May 6, 2011 12:49 AM
  • As of 5 May 2011, I am seeing couple of issues.

    1) JS error : Microsoft.Map.Location is not a constructor. This was working fine before but from 5th may i am seeing this error. The map doesnt render and give this error. But interestingly this doesnt happen all the time, it works if page is refreshed few times.

    Workaround: We have delayed any call to map untill Microsoft.Map.Location is made available.

    2) Infobox html gets unstyled. Html placed in infobox works fine with the style defined, but as soon i pan the map, the styling goes out and html is displayed in a single line. After further investigation, line-height goes 0 and white-space goes nowrap.

    Workaround: line-height changed to some pixels and white-space to normal.

     

    But all of these workarounds are so frustrating, why do we need to do them? So many bugs.

     

     

    Friday, May 6, 2011 7:33 AM
  • Just trying to establish some common facts... it sounds like all those users who experienced a "Undefined" constructor - type error:

    1.) Had code in either the <head> of the document directly or in a jQuery $(document).ready callback

    2.) In all cases, have been able to fix the issue by moving the offending code to a $(window).load callback or into a function called from the <body onload=""> callback.

     

    So, is there anybody who is experiencing "undefined" errors in v7 from code that is called from the body onload="" callback or from $(window).load? If not, is it safe to recommend these as consistent solutions to the issues (at least, as far as can be confirmed so far)? I notice that all the MS samples continue to place the map initialisation function in the body onload event handler.

     

     

     


    twitter: @alastaira blog: http://alastaira.wordpress.com/
    Friday, May 6, 2011 9:04 AM
    Moderator
  • But I have only the following simple sample: this is working in IE 8 but not in Firefox 4.0.1. Here I am getting the error "MM.Location is not a constructor":

     

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
       <script charset="UTF-8" type="text/javascript" src="http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0&mkt=de-DE">
        </script>
    </head>
    <body>
       <div id='myMap' style="position: absolute; z-index: 0; width: 1000px; height: 600px;"></div>
       <script type="text/javascript">
          new Microsoft.Maps.Map(document.getElementById("myMap"), {height: 600, width: 1000, credentials: "BING MAPS KEY"});
       </script>
    </body>
    </html>

    Friday, May 6, 2011 11:24 AM
  • Hello,

    Even with using onload="" within the <body> tag e.g. <body onload="GetMap();">

    I still receive a blank map unless I provide a style="height:#px;width:#px;


    derek
    Friday, May 6, 2011 12:29 PM
  • Hello,

    Even with using onload="" within the <body> tag e.g. <body onload="GetMap();">

    I still receive a blank map unless I provide a style="height:#px;width:#px;


    derek

    Those are different issues:

    One is related with map divs without width and height specified (yours), and then there's another regarding the initialization of the map and specific actions being executed before it's completely loaded.

    Friday, May 6, 2011 12:52 PM
  • @Heiko2233 - are you absolutely sure that's the error that you're getting from that code listing? I can't see any reference to MM.Location in your code, so I'm very surprised at that error - "Microsoft.Maps.Map is not a constructor" could be explained...It sounds like it still relates to the same problem anyway - can you confirm that it can be resolved by moving the map constructor into a function that is called in the onload event of the body as per the example at http://msdn.microsoft.com/en-us/library/gg427624.aspx

    @jderikito - it's expected behaviour to have to explicitly specify a height and width for the map. From http://msdn.microsoft.com/en-us/library/gg427624.aspx: "The size of the map is defined by the height and width of the DIV element" - so, if these are undefined, the map height and width will also be undefined.


    twitter: @alastaira blog: http://alastaira.wordpress.com/
    Friday, May 6, 2011 1:02 PM
    Moderator
  • @Heiko2233 - are you absolutely sure that's the error that you're getting from that code listing? I can't see any reference to MM.Location in your code, so I'm very surprised at that error - "Microsoft.Maps.Map is not a constructor" could be explained...It sounds like it still relates to the same problem anyway - can you confirm that it can be resolved by moving the map constructor into a function that is called in the onload event of the body as per the example at http://msdn.microsoft.com/en-us/library/gg427624.aspx

    @jderikito - it's expected behaviour to have to explicitly specify a height and width for the map. From http://msdn.microsoft.com/en-us/library/gg427624.aspx: "The size of the map is defined by the height and width of the DIV element" - so, if these are undefined, the map height and width will also be undefined.


    twitter: @alastaira blog: http://alastaira.wordpress.com/


    Alastair, that's true, but the previous version allowed you to create a div without size, and it would stretch to the parent container. It was probably just a suitable side-effect, but it has indeed been modified in this version. Anyway, it is now perfectly clear in the reference that one should always specify the size of the map, so I guess this will be filed as a non-issue. I'm not exactly sure that that paragraph existed before this release though :P

    Friday, May 6, 2011 1:15 PM
  • @Heiko2233 - are you absolutely sure that's the error that you're getting from that code listing? I can't see any reference to MM.Location in your code, so I'm very surprised at that error - "Microsoft.Maps.Map is not a constructor" could be explained...It sounds like it still relates to the same problem anyway - can you confirm that it can be resolved by moving the map constructor into a function that is called in the onload event of the body as per the example at http://msdn.microsoft.com/en-us/library/gg427624.aspx


    1. Sorry, the correct Error was: "Microsoft.Maps.Map is not a constructor"
    2. Yes, it works, when I am moving the map constructor into a function like deskribed here: http://msdn.microsoft.com/en-us/library/gg427624.aspx

    Thanks.

    Heiko

    Friday, May 6, 2011 1:21 PM
  •  I'm not exactly sure that that paragraph existed before this release though :P

    Good point - isn't it a shame that you don't get source control on MSDN pages ;)

    However, it was always a requirement to set height, width and position on the container div for a v6.3 map, so it was probably just by chance that it worked in the first release of v7 without.


    twitter: @alastaira blog: http://alastaira.wordpress.com/
    Friday, May 6, 2011 2:08 PM
    Moderator
  • If not, is it safe to recommend these as consistent solutions to the issues (at least, as far as can be confirmed so far)? I notice that all the MS samples continue to place the map initialisation function in the body onload event handler.

     

    No, it is not safe to recommend delaying until $(window).load fires for two reasons:

    1. Previous versions of the map control were stable when injected into the page *after* the document is loaded (e.g. UpdatePanels); now, it's impossible to know when it's safe to use the Microsoft.Maps namespace after loading the map script.

    2. Load may not fire for many seconds after the document is interactive.  load doesn't fire until all images are ready, for example; it certainly fires after the initial paint of the page, which means that maps initialized then paint *after* the rest of the page.

    Friday, May 6, 2011 4:42 PM
  •  I'm not exactly sure that that paragraph existed before this release though :P

    Good point - isn't it a shame that you don't get source control on MSDN pages ;)

    However, it was always a requirement to set height, width and position on the container div for a v6.3 map, so it was probably just by chance that it worked in the first release of v7 without.


    twitter: @alastaira blog: http://alastaira.wordpress.com/
    Has Microsoft ever put forth an early-access or versioning policy for the map control? Is there some way for me to be notified on the release of a new version of the map control other than checking the 'What's New' MSDN page regularly?
    Friday, May 6, 2011 4:56 PM
  • Wow - wait a go MS - fantastic community involvement, you finally get everyone's attention by blowing up their own sites.

    Who came up with the brilliant idea of in place upgrades as opposed to just releasing a 7.1 script. The early 7.0 controls are so bad you'd think you'd wanna add a minor version to get everyone excited that maybe things are looking up. That way we could at least choose to move to the new version after countless hours of work arounds to make 7.0 half work across browser - instead of bringing down 3/4 of my site without telling me.

    CAN YOU PLEASE PROVIDE AN OLD SCRIPT REFERENCE SO THAT MY SITE WHICH WAS INTENDED TO GO LIVE NEXT WEEK AND IS NOW DELAYED DOES NOT PEND ON WHETHER YOU FALL APART COMPLETELY WITH THIS CODEBASE.


    Jonathon
    Friday, May 6, 2011 8:25 PM
  • ...now, it's impossible to know when it's safe to use the Microsoft.Maps namespace after loading the map script..

    except it appears that the onscriptload parameter has been re-introduced into version 7:

    http://alastaira.wordpress.com/2011/05/06/bing-maps-v7-lazy-loading-and-the-onscriptload-parameter/


    twitter: @alastaira blog: http://alastaira.wordpress.com/
    Friday, May 6, 2011 9:16 PM
    Moderator
  • I agree that it would be great to have a way to reference the pre-5/5/2011 version of V7  This update has certainly put a halt to my progress in Bing Map Ajax Application development.


    derek
    Friday, May 6, 2011 9:21 PM
  • ...now, it's impossible to know when it's safe to use the Microsoft.Maps namespace after loading the map script..

    except it appears that the onscriptload parameter has been re-introduced into version 7:

    http://alastaira.wordpress.com/2011/05/06/bing-maps-v7-lazy-loading-and-the-onscriptload-parameter/

    That's a good point.  As you pointed out on your blog, though, (1) the onscriptload parameter is underdocumented (2) the timing of the availability of the API is variable based on your local browser caching policy.  So while it's always safe to use the Maps namespace during (or after) the onscriptload callback, it's *sometimes* possible to use it before that - which makes bugs difficult to find and hard to diagnose.  Besides, who likes writing asynchronous code? :)
    Friday, May 6, 2011 9:26 PM
  • Wow - wait a go MS - fantastic community involvement, you finally get everyone's attention by blowing up their own sites.

    Who came up with the brilliant idea of in place upgrades as opposed to just releasing a 7.1 script. The early 7.0 controls are so bad you'd think you'd wanna add a minor version to get everyone excited that maybe things are looking up. That way we could at least choose to move to the new version after countless hours of work arounds to make 7.0 half work across browser - instead of bringing down 3/4 of my site without telling me.

    CAN YOU PLEASE PROVIDE AN OLD SCRIPT REFERENCE SO THAT MY SITE WHICH WAS INTENDED TO GO LIVE NEXT WEEK AND IS NOW DELAYED DOES NOT PEND ON WHETHER YOU FALL APART COMPLETELY WITH THIS CODEBASE.


    Jonathon


    Hi Jonathon -

    There are two issues reported on new release which we are tracking.

    1. when map is placed in div without height/width, map does not appears - Though the recommended way is to give the width/height, we have fixed this issue & it would be live very soon (clear the cache, if you still get old version, new version 7.0.2011050604957.71). This should fix all issues related to map not visible.

    2. Object null error in case of FF/Chrome. Again, recommeded way is to call map API on body onload http://msdn.microsoft.com/en-us/library/gg427624.aspx). this would fix all issues related to chrome/FF

    we have released new features in this reealse, check them out http://msdn.microsoft.com/en-us/library/gg675211.aspx. Hope you would be excited. In future, we would make sure we don't break exisitng customer. Thanks for feedback.

     

     

    We have added couple of new features in this release.

     

     
    • Proposed as answer by Justin_T Saturday, May 7, 2011 1:14 AM
    • Marked as answer by Ricky_Brundritt Wednesday, May 18, 2011 6:17 PM
    Saturday, May 7, 2011 1:05 AM
  • I agree that it would be great to have a way to reference the pre-5/5/2011 version of V7  This update has certainly put a halt to my progress in Bing Map Ajax Application development.


    derek


    Hi Derek

    we have released a fix which would be live very soon. This should fix most of issues around map visibility. For errors, either use onscriptload or make sure to call map API in body onload. Thanks for been patient.

    Saturday, May 7, 2011 1:08 AM
  • ...now, it's impossible to know when it's safe to use the Microsoft.Maps namespace after loading the map script..

    except it appears that the onscriptload parameter has been re-introduced into version 7:

    http://alastaira.wordpress.com/2011/05/06/bing-maps-v7-lazy-loading-and-the-onscriptload-parameter/

    That's a good point.  As you pointed out on your blog, though, (1) the onscriptload parameter is underdocumented (2) the timing of the availability of the API is variable based on your local browser caching policy.  So while it's always safe to use the Maps namespace during (or after) the onscriptload callback, it's *sometimes* possible to use it before that - which makes bugs difficult to find and hard to diagnose.  Besides, who likes writing asynchronous code? :)


    Hi Dan

    It would be documented very soon in msdn. To avoid timing issues, you could either call map api body onload as mentioned http://msdn.microsoft.com/en-us/library/gg427624.aspx. Also you can also use below option with onscriptload. it should work as expected.


    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html>
    <head>
    <title></title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    </head>  
    <body>
      <div id='myMap' style="position:relative; width:500px; height:500px;"></div>  
      <script type="text/javascript">var map = null;
        var source = "http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0&onscriptload=GetMap";
        var script = document.createElement("script");
        script.setAttribute("type", "text/javascript");
        script.setAttribute("src", source);
        document.body.appendChild(script);function GetMap() {
            map = new Microsoft.Maps.Map(document.getElementById('myMap'), null);
        }    </script>   </body>
    </html>

    Saturday, May 7, 2011 1:12 AM
  • Well,

    I did noticed a new bug on the control today. It seems that if you rely on a parent container for the map dimension,  something like:

     

    <div id='mapContainer' style="width:xx; height:xx">

          <div id='map'></div>

    </div>

     

    it no longer "stretches" to the parent container like it used to. Now you have to put the size on the map div itself.


    We have reverted thebehaviour here & it would be same as earlier. Pls wait for some time & try it again. Clear cache/cookies & give a try. it should work as expected.
    Saturday, May 7, 2011 1:16 AM
  • Hemant This is great news reguarding the restoration of the ability to make maps w/ out having to specify height/width. That would put me back on track i think.

    Thanks,


    derek
    Saturday, May 7, 2011 1:38 AM
  • Is there a way to remove the "lazy load" functionality that now seems to be happening? Prior to this release, this would work correctly with $(document).ready, now it requires $(window).load.

    I've purposely included this code into the document HEAD to ensure its loaded and ready for use, i DON'T want to defer the loading of the scripts.

    Just wondering if we could get the option to remove Lazy loading.

    Thanks,

    -Brian


    Sunday, May 8, 2011 12:59 AM
  • Maybe it would be better to tag the Ajax v7 control as a "BETA". That way everyone wouldn't get so upset when you guys release silent, suprise updates that break stuff. Then when you are ready to commit to keeping it stable you could remove it from "BETA" status.

     


    Microsoft MVP - Bing Maps
    Blog: http://pietschsoft.com | Web.Maps.VE - ASP.NET AJAX Bing Maps Server Control
    Sunday, May 8, 2011 1:27 AM
  • Is there a way to remove the "lazy load" functionality that now seems to be happening? Prior to this release, this would work correctly with $(document).ready, now it requires $(window).load.

    I've purposely included this code into the document HEAD to ensure its loaded and ready for use, i DON'T want to defer the loading of the scripts.

    Just wondering if we could get the option to remove Lazy loading.

    Thanks,

    -Brian


     

    use below script to remove laxy loading issues. it uses onscriptload parameter.


    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html>
    <head>
    <title></title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    </head>  
    <body>
      <div id='myMap' style="position:relative; width:500px; height:500px;"></div>  
      <script type="text/javascript">var map = null;
        var source = "http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0&onscriptload=GetMap";
        var script = document.createElement("script");
        script.setAttribute("type", "text/javascript");
        script.setAttribute("src", source);
        document.body.appendChild(script);function GetMap() {
            map = new Microsoft.Maps.Map(document.getElementById('myMap'), null);
        }    </script>   </body>
    </html>

     


    HemantGoyal
    Sunday, May 8, 2011 1:40 AM
  • HemantGoyal,

    Yeah, i see how this allows for a callback to fire when the scripts have loaded, which is very useful.  That's not exactly, the scenario that I'm looking for.

    I'm including the mapcontrol api into the <head> of the document, its my understanding that all scripts in this section will load before the DOM is rendered.  Previous, to this release everything worked correctly.

    It seems that after this release, some version of lazy laoding was "add/fixed" such that the other apis that also get loaded are loaded asynchornisly, such that they don't block the rest of the DOM.

    I'd like to go back to the orignial way ( prior to this release ) where, upon loading the api into the <head> all the other apis would load in the <head> blocking the DOM.

    It's not a huge issue, as I have changed to the $(window).load function to run my mapping code, but its unfortunate that such a huge change in functionality was added that basicaly BROKE my current implementation.

    It seems like this might be as easy as allowing a async=false flag, that would allow loading of the additional API's synchronisly if the developer wanted.

    Would it be possible for you to provide some technical feedback as to what was changed in this release that changed the behavior, as a developer I'm just interested in what was changed or correctly to break the old functionality.

    -Brian

     

    Sunday, May 8, 2011 2:35 AM
  • I, too, am baffled by the decision to lazy-load so much of the map control script.  On most pages I use maps on, they are the primary point of interaction with the user.  (Why show a map if you're not going to use it?)  Lazy-loading allows pages to become interactive before the JS is loaded - that is, they don't slow down initial rendering.  But the map can't be rendered until its script is downloaded!  I can't imagine a scenario where I, as a developer, would want my page to be interactive while the map is still initializing.

     

    I understand that I can use the onscriptload parameter to initialize the map as soon as it's available, but still - why the complexity?  What problem are you trying to solve?

    Monday, May 9, 2011 3:40 PM
  • We released an update to the Ajax v7 control last Thursday 5/5 with some incremental feature enhancements and improvements. We did not anticipate that there would be issues with this update which is the reason it was an automatic update. Unfortunately, there were a few issues encountered.  Thanks everyone for your feedback and reporting these issues. We have been working to correct these issues as they were reported as soon as possible. We apologize for this disruption in service, and we appreciate your patience as we have worked to address them.

    As Hemant specified earlier, the first issue involved loading the map on a div without width/height specified.  Although the documentation for loading the map recommends that width/height of containing divs to be specified, we realize that some sites were not doing this, and this was a change in behavior from the previous map control before the update. So, we have corrected this issue and reverted back to the previous behavior on Friday 5/6.

    The second issue reported was on sites that expected the map control script to load synchronously.  With the 5/5 update, we added support for asynchronous loading of the control script.  This provides the ability to load map control scripts in parallel with other scripts and web pages can render faster without waiting for the map script to load. However, as pointed out by customers, this has broken some sites that expected the map control to load synchronously.  Using the map control onscriptload callback or the body onload event before calling into the map control APIs will correct this.  We are working to document this with the v7 documentation on MSDN as soon as possible.  We are also actively investigating a solution to use asynchronous loading only when the onscriptload parameter is specified and use synchronous loading when the parameter is not present. This should return the control to the previous synchronous loading behavior for those sites that continue to want to use synchronous loading. We will keep you posted as soon as we are able to roll this update out.

    Thanks again for the feedback and we apologize for the inconvenience this has caused. 

    Monday, May 9, 2011 7:21 PM
  • @DanDaviesBrackett - I agree completely. I can only imagine that the lazy-loading decision was made in some part to support the new approach to loading of custom modules, as described at http://msdn.microsoft.com/en-us/library/hh125836.aspx

    What I really can't understand is, considering both the *breaking* changes in architecture (pun very much intended) and the addition of significant new functionality in this update, why were these changes pushed out in a replacement 7.0 control rather than versioned properly as a 7.1 release. If a new, buggy v7.1 was released, nobody would have minded much - and it would have been so much easier to fix - just downgrade again to 7.0...

    It's a shame because it looks like there's actually some really interesting new features getting added to the control in the new update - we've got the framework to support streetside and blockview in the AJAX control, a first step towards the vision of the Read/Write world, new touch events, a unified framework for adding custom modular content and functionality.... but this has all been completely eclipsed by the complete balls up of the way the release was rolled out.


    twitter: @alastaira blog: http://alastaira.wordpress.com/
    Monday, May 9, 2011 7:29 PM
    Moderator
  • @tanoshimi - I completely agree with your points.

    This fiasco has made me consider rewriting some of my applications to use the older and much more stable v6 control. If I can't trust Microsoft to not break my applications when they decide to force an update to the Ajax v7 control, then I can't trust they wont tarnish my reputation and credibility to my clients.

    Bing Maps Team, Can I trust that you wont break my code with a silent, blind sided update again? Or, do you recommend that we just use the v6 control for now, until you get ready to commit full stability when updating the v7 control?


    Microsoft MVP - Bing Maps
    Blog: http://pietschsoft.com | Web.Maps.VE - ASP.NET AJAX Bing Maps Server Control
    Tuesday, May 10, 2011 1:04 AM
  • @tanoshimi - I completely agree with your points.

    This fiasco has made me consider rewriting some of my applications to use the older and much more stable v6 control. If I can't trust Microsoft to not break my applications when they decide to force an update to the Ajax v7 control, then I can't trust they wont tarnish my reputation and credibility to my clients.

    Bing Maps Team, Can I trust that you wont break my code with a silent, blind sided update again? Or, do you recommend that we just use the v6 control for now, until you get ready to commit full stability when updating the v7 control?


    Microsoft MVP - Bing Maps
    Blog: http://pietschsoft.com | Web.Maps.VE - ASP.NET AJAX Bing Maps Server Control

    We understand your frustrations, and we appreciate all the feedback.  We planned to release this as an incremental update and did not intend to break existing customers with this update.  Anytime we release large features we usually version the control to provide an opt-in approach before auto upgrade, however these updates were considered incremental and we did not expect any major issues. We are sorry that some sites were affected by the issues mentioned above, and we have and continue to work to address the concerns.  We are also looking at ways to improve this process in the future.

    Keith Kinnan, Development Lead, Bing Maps

    Tuesday, May 10, 2011 1:27 AM
  • @KeithKinnan - thankyou for taking the time to read and respond to this thread. Sometimes things don't go as planned - I'm sure all software developers appreciate that - but it's good to know that you are both listening to the problems and working to address them.

    If it's any consolation, as I said in my last post, it looks like there's some really exciting new features being added or coming just around the corner and I for one am very much looking forward to trying them out. It's just hard to become excited about (or interest clients) in new features when you haven't got a stable base to work from.


    twitter: @alastaira blog: http://alastaira.wordpress.com/
    Tuesday, May 10, 2011 5:51 AM
    Moderator
  • You know whats better than new features?

     

    A stable control that doesnt break.

     

    You know what else is better?

     

    Hearing about changes from the dev team rather than from angry clients who have a broken site.

     

     

    Just bump the version number...

    Tuesday, May 10, 2011 8:36 AM
  • @KeithKinnan - I, also, really appreciate you taking the time to read and respond to this thread. I know I was sounding a bit more negative than I may have intended, as I was really trying to get across the level of frustration around this. I love the direction the v7 control is taking and there are definitely some really exciting features being added. Lastly, I do understand the surprise issues that can come up when releasing (all devs have them.)
    Microsoft MVP - Bing Maps
    Blog: http://pietschsoft.com | Web.Maps.VE - ASP.NET AJAX Bing Maps Server Control
    Tuesday, May 10, 2011 1:16 PM
  • ALL -

    Based on feedback, we have reverted the behavior of map & map classes loading on FF/Chrome/safari & below script would work:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html>

    <head>

    <title></title>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

    <script type="text/javascript" src="http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0"></script>

    <script type="text/javascript">

    var map;

    alert('Microsoft.Maps : ' + Microsoft.Maps  + '\nMicrosoft.Maps.MapTypeId : ' + Microsoft.Maps.MapTypeId  + '\nMicrosoft.Maps.Location : ' +         Microsoft.Maps.Location + '\nMicrosoft.Maps.Color : ' + Microsoft.Maps.Color + '\nMicrosoft.Maps.Pushpin : ' + Microsoft.Maps.Pushpin + '\n Microsoft.Maps.Polyline : ' + Microsoft.Maps.Polyline + '\nMicrosoft.Maps.Infobox : ' + Microsoft.Maps.Infobox);

    </script>

    </head>

    <body>

      <div id='myMap' style="width:300px;height:300px;position:absolute"> </div>

      <script type="text/javascript">            

           map = new Microsoft.Maps.Map(document.getElementById("myMap"), null);

       </script></body>

    </html>

     

    Please make sure you are getting latest 7.0.20110509105925.41 version. As off now, both the breaking changes are reverted back. Again apologies for inconvinence. 

    Hope you would like the new features viz inertia, tilebuffer, geolocation, dynamic loading & smooth experience on most of mobile browsers. Keep the feedback coming, we are listening them, as always (silently J)


    HemantGoyal
    Wednesday, May 11, 2011 1:48 AM
  • Since we don't have any information while contacting the team directly, I'll try on this forum.
    I saw that Keith and other answered the questions here and I would like to thank MSFT for this as you've been really listening to each of customers requests and it is well appreciated.

    Hemant, we have a serious problem caused by this kind of code:

    Sample of code to reproduce the bug

     

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html>
     <head>
      <title>Map with valid credentials</title>
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
     </head>
     <body>
    		Title that should be displayed
    		<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
    		<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
    		<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
    		<br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br /><br />
      <iframe src="http://www.bingmapsportal.com/ISDK/AjaxV7" style="width: 600px; height: 500px;" />
     </body>
    </html>
      
    

     

     

    Description and effect

    So basicaly, it appears that if you set a map on a page and load it inside an iframe, it set the scroll automaticaly in order to display the map with a different behaviour depending on the browser:

    • IE9, IE8 : set the scroll in order to let the top of the map control appears at the bottom of the current window
    • FF3.6 : scroll effect, the scroll is set in order to display all the map control (top of the map control = top of the current window)
    • Not supported browser - FF4 : is okay
    • Not supported browser - Opera 11 : scroll effect, the scroll is set in order to display all the map control (top of the map control = top of the current window)

    The fact is, there is a bad scroll effect that was fixed during the 26th April version, but rolled back for some reasons.

    You can try it via this link: http://www.boonaert.net/pages/veforum/bing-v7_ScrollBug.html

    Here is the page that is loaded is the iSDK, a simple page that hosts a map control can be used and you get the same bug.

     

    Solution

    If the iframe is loaded in a different domain like in many of my cases, we cannot set the scroll of the parent page but it is what happened.

    So I've tried to set the scroll by using this kind of fix:

     

       if (window.parent != null)
        window.parent.scrollTo(0, 0);
    

     

    But you cannot do this due to security restriction if you are on different domains..

     

    Questions

    So my question is, what is up with this bug as, in many case we use this specific scenario in order to integrate Bing Maps application, we can't use another solution due to technical limitations so will it be fixed as in 26th April update?

    When can we expect a stable version of the map control in AJAX v7?


    MVP - Bing Maps - My blog (FR): http://blogs.developpeur.org/nicoboo/ Twitter: http://twitter.com/nicolasboonaert/
    Wednesday, May 11, 2011 9:01 AM
    Moderator
  • @Nicolas Boonaert - Do you have own the page that loads the map? If so, passing disableKeyboardInput = true in the map's constructor should stop the parent page from scrolling if the map is in an iframe. After the map's constructor, you can set keyboard input back to false, map.setOptions({ disableKeyboardInput: false });. Hope that workaround works for you for now.

    Wednesday, May 11, 2011 6:26 PM
  • @Derrick - It works indeed, I did not notice that it was on by default and that was this that caused this behaviour. I have control on the page that hosts the page and I can now fix this thing.
    I knew this option but not this scroll effect: http://social.msdn.microsoft.com/Forums/en-US/vemapcontroldev/thread/ad8f0949-150a-46ea-9951-d02dcc1ef16b/

    Thanks!


    MVP - Bing Maps - My blog (FR): http://blogs.developpeur.org/nicoboo/ Twitter: http://twitter.com/nicolasboonaert/
    Thursday, May 12, 2011 9:58 AM
    Moderator
  • Hello All,

    I am facing some issue while using the bing map v7 as mentioned below:-

    1) bing map v7 is not displaying properly in safari browser

    2) when we reinitialization the bing map v7 using the asynchronous request its gives the error "$lineinfo' is undefined" i am facing this problem when i have the modal popup on the aspx page and after click on the submit of the popup box bing map v7 not rendered.

    Please provide me the solution for above this ASAP

     

     

    Friday, May 27, 2011 7:01 AM
  • @Vipul - Are you looking on Safari+Windows or mac? On Safari+windows V7 is not supported http://msdn.microsoft.com/en-us/library/gg427618.aspx & you might not get some controls like checkbox

    if you are making async call, use onscriptload method to load mapcontrol though the error seems to be coming from your page.

     

     


    HemantGoyal
    Friday, May 27, 2011 11:45 PM