Gmap.addoverlay() causes map to zoom out if you've called getEarthInstance().
Using ge plugin 6.2.1.6014, Chrome/Mac OSX and {Firefox,Chrome}/Windows Vista Home Premium (Cross-posted on Google Earth API issues). See the test code here.
Shortly after the second marker appears, the maps zooms out, even though noone asked it to.
By putting an alert() in that callback and extending the timeout() interval, I'm pretty sure it's the addOverlay(), not the getEarthInstance(), where the problem occurs.
To immunize my code, I tried the commented code in the callback, but it's apparently too late by then.
So, is there any way to determine the version of the plug-in without calling getEarthInstance()? Perhaps some hacking with google.load? Without a clean way to detect the version of the plug-in, I'd have to disable the G_SATELLITE_3D_MAP as long as any of this version of the plug-in remain installed out there, which, I'm thinking, is pretty much forever?
I'm calling getEarthInstance() because I want to enable a few layers and set a click listener on the globe. Is it possible to do either of those things without getEarthInstance()?
I haven't used v2 of the Maps API extensively, so maybe this is a long-known behavior, but this does appear to be a bug. I suggest filing it on the Maps API v2 issue tracker, as the plugin itself (or the plugin API) can't really do anything to change the view of the map.
Please note that v2 of the API has been deprecated (since May 2010!), so they are only fixing regressions. Also, you should really consider switching to v3 of the API; there's even a handy library for Earth API integration.
In the meantime, there are a few approaches that might help:
Is there a reason that you're checking the version number of the
plugin? There have been some additions to the API in recent
releases, but I'm not sure what in 6.2 would be a deal-breaker. The
plugin has used the same auto-updater as Google Earth for some time
now, so the vast majority of users are on the latest version of the
plugin anyway. There are a handful of holdouts on 5.x and 6.0 for
specific reasons, but there really aren't very many. For almost
everyone that visits your site, the isSupported() check should be
sufficient, and if it isn't, they have probably purposefully opted
out and know why things aren't working.
Since you're loading the earth Javascript library anyway, you can
consider just loading an instance of the plugin without involving
the API. google.earth.createInstance will help you out there
(you can use a hidden html element if that matters, just make sure
to detach it and let it be garbage collected when you're finished).
There is some overhead in starting up a plugin instance and then
discarding it, but it's pretty minor over just starting it, which
you're already doing here. The next plugin instance will also be
created more quickly when the view is switched to 3D.
To anyone who's been hit by this bug, thanks to the suggestion in the answer by Mr. Kenny, here's some code to check the plug-in version without falling victim to the bug we're trying to avoid:
function enable_geplugin(map, div, callback) {
if (!google.earth.isSupported())
return;
var earth_div = document.createElement('div');
document.body.appendChild(earth_div);
earth_div.style.height = '1px';
earth_div.style.width = '1px';
google.earth.createInstance(
earth_div,
function(instance) {
if (!instance.getPluginVersion().match(/^6\.2\./)) {
map.addMapType(G_SATELLITE_3D_MAP);
if (callback)
map.getEarthInstance(callback);
}
earth_div.style.display = 'none';
document.body.removeChild(earth_div);
},
function(errorCode) {
// do this so user can click on map type "Earth" and see the download instructions
map.addMapType(G_SATELLITE_3D_MAP);
earth_div.style.display = 'none';
document.body.removeChild(earth_div);
}
);
}
Used, for example, here.
(On OSX/Chrome, the document.body.removeChild(earth_div) generates an Uncaught ReferenceError: NPObject deleted, but that's the least of my worries.)
So we can now effectively disable G_SATELLITE_3D_MAP for bad plug-in releases, but I still hope someone working on the plug-in fixes the bug itself.
Related
I had liferay 7.0, when you open the ispect ( Ctrl + Shift + I) then go to the console and write
for english
Liferay.Language.get('login');
"Login"
german language
Liferay.Language.get('login');
"Anmelden"
But Now when I upgraded to Liferay 7.4 , I get
for english
Liferay.Language.get('login');
"login"
german language
Liferay.Language.get('login')
"login"
The issue has been reported
https://issues.liferay.com/browse/LPS-123191?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
https://help.liferay.com/hc/en-us/articles/4403607020813-Liferay-Language-get-method-is-no-longer-working-with-string-variables-as-of-DXP-7-3
From one of the comments in the tickets that you've linked yourself:
That option was deprecated under LPS-113569 and is no longer available. You can get some extra information in the pull request deprecating such functionality:
Liferay.Language.get is replaced by the language filter and we also want to remove the AUI dependency, so in this change, we migrate the Liferay.Language.get function to frontend-js-web.
Note that the migrated version is dumbed down to just return the key: it does not preserve the dubious fallback behavior of the old implementation, that used a deprecated synchronous request to the server to fetch the value, which would produce a console warning, and very likely end up returning the key anyway (unless the corresponding value happened to be in the kernel); in short, the old implementation only wallpapered over a real problem (failure of the filter to do its actual job).
One of the linked issues is about updating the documentation, which hasn't happened yet.
Edit, following your comment:
The documentation that you link in your comment looks like the not-yet-updated documentation.
In general, I've confirmed your statement (which wasn't a question, by the way): Indeed, the feature you've been using has become less and less useful (as it was only good for a few translations from core, never from any module, and retrieved them in a performance-killing way. It's not possible to extend it to retrieve all modules' keys and do so in a performant manner, so you should use whatever technique the libraries you're using to translate your frontend are using)
In case you're building your UI with JSPs, that would be <liferay-ui:message key="your-key-of-choice"/>. In other cases, you know what you're using, and that framework definitely has means of providing localization.
yes, this is true it does not work anymore, as Olaf Kock said , you need to implement a new way to localize javascript , there is a npm tool for this #clavis/translation-transformer
I was trying to repro a tutorial about the creation of an Excel Add-in when something get wrong with the IntelliSense of Visual Studio. I was writing this code:
function updateStocks() {
Excel.run(function (ctx) {
var **range** = ctx.workbook.names.getItem("Stocks")
At this step, everything was fine, but after the getItem, I have tried to add .getRange() at which point the IntelliSense was not able to understand anything related to my variable range.
Screenshot
What is really "funny" is the fact that even if the properties are not displayed, when I write the code of the tutorial manually, the code is executed without mistake.
Why does this behavior occur and how can I correct it?
Are you able to see IntelliSense for other types within that .run? I.e., do you have everything up to the point where you get a Range from a named item? If you were to obtain the range differently (e.g., context.workbook.getSelectedRange()), do you get IntelliSense then?
This might be related to an issue (now fixed) where the CDN accidentally had the namedItem.getRange method removed (it was the only one that was affected, and we've put in measures to ensure we catch those in the future). See "Can't get range from a defined name". The CDN has been patched a couple weeks ago, but the JS IntelliSense file ("VSDOC") probably hadn't. If that's the case, it's a point-in-time issue that should resolve itself very very soon, as new deployments of the CDN will have the getRange method both in the VSDOC and everywhere else.
FWIW, you may still run into limitations of the JS IntelliSense engine (there are plenty, unfortunately: for example, trying to pass values across Promises, or passing in API objects as parameters to functions). The only true good workaround for this is using TypeScript, which allows you to declaratively assert to the compiler/IntelliSense-engine that "I know this type is an Excel.Range!") -- and offers a number of other goodies, async/await being a very major one. I personally believe that if you really want a "premier" Office.js-coding experience, TypeScript is the way to go. To that end, I describe how to use TypeScript in my book, "Building Office Add-ins using Office.js" (full disclosure, I am the author; but I've had many readers comment on how helpful of a resource it's been to them). The book is very much TypeScript-oriented, IntelliSense being one of the reasons (and async/await and let being the primary others) -- though I also offer an Appendix where I describe the JavaScript-only way of accomplishing the same Office.js tasks. It takes only a small amount of effort to get started with using TypeScript, and once you do, I don't think you'll look back.
Based on the w3schools site: "There is no public standard that applies to the navigator object, but all major browsers support it.".
I somehow see the navigator object as rather important, and with the rate at which browsers change their versions today even more so. So it rather baffles me that there is no standard for it.
What baffles me even more is that none of the browsers seem to have come up with the idea to include the two most important properties into this object:
navigator.browserName
navigator.browserVersion
We all have to parse the darn navigator.userAgent and hope from version to version that stuff in there did not change too much. Like it just did in IE11 for example...
How can one even write a W3C proposal for a new standard?
Thanks to #Alohci and some more digging, since the Navigator object has a standard, the way to go about proposing a change to it is to send an email to the public-html#w3.org
I am working through the pluralsight videos on MonoTouch. At one point, the trainer right clicks on the name of a derived class, and in the 'refactor' menu there is a function to override/implement members of that class. When I click however (latest version), I see only 'rename.'
The person in this link had the same issue some time ago and has included screenshots - but noone replied to them in the MonoTouch discussion group:
http://monotouch.2284126.n4.nabble.com/Right-Click-Class-name-gt-Refactor-gt-Override-Implement-members-tt4655504.html#none
Has anyone experienced (and resolved!) this?
Some of the refactoring features were reorganized or removed (for now) in the rewrite of the code code completion engine that took place for MD 3.0.
You can still access this particular feature two ways:
1) After typing the "override" keyword, MD offers the members you can override/implement. Selecting one will cause it to be stubbed out.
2) You can override many members at once using the "Edit->Show Code Generation Window" command in the class body. This command doesn't have a keybinding on Mac by default, but you can assign one in Preferences.
MonoDevelop 3.0 (and later) removed some features (including a few about refactoring) since they were not as stable, fully functional (complete) or buggy.
The same features (or similar ones) are likely to come back in future releases.
I want to add a calendar control to a page that already includes Prototype and Scriptaculous. Not happy with any of the Prototype ones I could find, I'm considring using the YUI Calendar widget.
I this likely to cause any problems?
We have worked hard to make sure that YUI is safe to use with any other library. We namespace everything, as HermanD says, under only one required global (YAHOO) and one optional one (YAHOO_config). We don't modify native objects. And even though Protoype does modify native prototypes, we code defensively so that this doesn't break YUI functionality.
If you find any bugs in using the two together, please let us know.
Regards,
Eric
YUI Team
By default everything in YUI is within the YAHOO namespace, so as long as you sensibly apply namespaces to anything you use from YUI, I would have thought you should be ok.
See: http://developer.yahoo.com/yui/yahoo/
I successfully used the YUI tab control in an app I was already using Prototype and Scriptaculous in and had no problem. The weight of all that is a bit much though if you're looking at a publicly available app. I wouldn't care so much about an internal app, say for a company, but you might want to think about how much JavaScript you're making end users download and the number of separate files they're having to download for the page.