with (o) {
foo = null;
}
jelentheti azt is, hogy az o.foo lesz null meg azt is, hogy a globalis foo valtozo lesz null vagy akar mindketto.
throw new Error(reason); mellett lehet object literalt is hasznalni. Pelda a Crockford videobol:
throw {
name: exceptionName,
message: reason
}
Vegig lehet menni egy object minden member-en igy:
for (var name in object) {...}
de ilyenkor vegigmegyunk azoknak az object-eknek is minden elemen amibol a mi objectunk szarmaztatva volt. Ezert Crocford szerint jobb igy megszokni meg ha csunya is:
for (var name in object) {
if (object.hasOwnProeprty(name)) {..}
}
loop: for (;;) {
...
if (...) {
break loop;
}
...
}
Egymasba agyazott ciklusoknal is mukodik.
function loadScript(src, callback) {
var node = document.createElement("script");
if (node.addEventListener)
node.addEventListener("load", callback, false);
else
node.onreadystatechange = function() {
if (this.readyState == "complete") callback.call(this);
}
node.src = src;
document.getElementsByTagName("head").item(0).appendChild(node);
node = null;
}
// load 30k script.
// Listener.cleanUp is defined at the bottom of drag.js
callback = function() {
var self = this;
alert("Loaded: " + this.src + "\nListener.cleanUp (nested):" + Listener.cleanUp);
};
loadScript("http://dhtmlkitchen.com/editor/js/drag.js", callback);
[Update]
Ahogy Jan Volter is emliti jobb vigyazni ezzel a readyState propertyvel es onreadystatechange eventtel, mert:
The “this.readyState == ‘complete’” test doesn’t actually entirely work. The readyState theoretically goes through a series of states:
0 uninitialized 1 loading 2 loaded 3 interactive 4 complete
But in fact, states may be skipped. In my experience with IE 7, you get either a loaded event or a completed event, but not both. It may have something to do with whether you are loading from cache or not but there seem to be other factors that influence which events you get. Sometimes I get loading or interactive events too, and sometimes I don’t. It’s possible the test should be “this.readyState == ‘loaded’ || this.readyState == ‘complete’“, but that risks triggering twice.
Stoyan (mar torolt) irasa szerint egy 1998-as MSDN cikkben talalkozott a readyState property-vel es azt hasznalva ez a kodreszlet IE-ben (csak ott!!) mukodik:
The idea is that after a new DOM element (a script tag) is created, you can have access to the readyState property of the element. If it says “complete”, then the new script is included and it’s OK to call functions from it. If you want to “listen” when the script download will be completed, you can attach an listener to the onreadystatechange event, just like with XMLHttpRequests.
Here’s an example:
var js;
function include_js(file) {
var html_doc = document.getElementsByTagName('head').item(0);
js = document.createElement('script');
js.setAttribute('type', 'text/javascript');
js.setAttribute('src', file);
html_doc.appendChild(js);
// alert state change
js.onreadystatechange = function () {
alert(js.readyState);
if (js.readyState == 'complete') {
// safe to call a function
// found in the new script
imready();
}
}
return false;
}
A commentek kozott Aaron Bassett egy masik megoldast javasolt, amihez modositani kell egy kicsit a betoltendo scripten (mar ha ez lehetseges), de szerinte minden browserben mukodik (bar nem probalta):
This untested but I dont see any reason why it wouldnt work, and should work across all browsers.
Right at the end of the external js file set a variable like:
var externalScriptLoaded = true;
Then in your main code you could use:
function checkScriptLoaded() {
if(!externalScriptLoaded) {
setTimout("checkScriptLoaded", 500);
} else {
// script loaded and ready to use
}
}
If you have multiple external files you want to check just make sure each has a unique variable name being set and check them accordingly.
This polling every half-second isnt perfect but it will work.
Your other option would be to create a function/method in your main script which inits the actions to perform when the external script is loaded.
Then as the very last thing in your external script you could just call that function/method
externalScripts.myScriptLoaded();
As this call would be at the end of your file it wont be run until the rest of the file ahead of it has been downloaded.
Once again this method is untested but am 99% sure will work and will be cross browser.
Safari requires dynamically created <style/> elements to be inserted into the for the rules to be applied
…
When IE encounters style.appendChild() it throws the rather obtuse and not-very-helpful error message, “unexpected call to method or property access”. Try replacing that with a call to set innerHTML, and you’ll get an equally useless error message of “unknown runtime error”. What’s going on here? It turns out that IE won’t let you manipulate <style/> elements in this way. There is, however, a different way to do the same thing. IE supports a styleSheet property on each style element that allows for the manipulation of the style sheet and the rules contained within. The styleSheet property has a property called cssText, which can be used to set and retrieve the CSS text for the style sheet.
…
This code now works in all A-grade browsers:
function addCss(cssCode) {
var styleElement = document.createElement(”style”);
styleElement.type = “text/css”;
if (styleElement.styleSheet) {
styleElement.styleSheet.cssText = cssCode;
} else {
styleElement.appendChild(document.createTextNode(cssCode));
}
document.getElementsByTagName(”head”)[0].appendChild(styleElement);
} A warning: IE only allows writing to styleSheet.cssText one time per <style> element. If you try to do it more than one time, it can crash the browser. For this reason, it’s best not to reuse <style> elements on your page. Instead, remove them or just add new ones.
…
A commentek kozul:
According to the HTML 4.01 spec section 14.2.3, style tags must be contained in the head element: “HTML permits any number of STYLE elements in the HEAD section of a document.”
Link to the spec:
http://www.w3.org/TR/html401/present/styles.html#edef-STYLE
C-grade is the base level of support, providing core content and functionality. It is sometimes called core support. Delivered via nothing more than semantic HTML, the content and experience is highly accessible, unenhanced by decoration or advanced functionality, and forward and backward compatible. Layers of style and behavior are omitted.
C-grade browsers are identified on a blacklist. Approximately 3% of our audience receives a C-grade experience.
Summary: C-grade browsers are identified, incapable, antiquated and rare. QA tests a sampling of C-grade browsers, and bugs are addressed with high priority.
A-grade support is the highest support level. By taking full advantage of the powerful capabilities of modern web standards, the A-grade experience provides advanced functionality and visual fidelity.
A-grade browsers are identified on a whitelist. Approximately 96% of our audience enjoys an A-grade experience.
Summary: A-grade browsers are identified, capable, modern and common. QA tests all A-grade browsers, and bugs are addressed with high priority.
X-grade provides support for unknown, fringe or rare browsers. Browsers receiving X-grade support are assumed to be capable. (If a browser is shown to be incapable — if it chokes on modern methodologies and its user would be better served without decoration or functionality — then it is considered a C-grade browser.)
X-grade browsers include all browsers not on the C-grade blacklist or the A-grade whitelist. Approximately 1% of our audience receives the X-grade experience.
Summary: X-grade browsers are generally unknown, assumed to be capable, modern, and rare or fringe. QA does not test, and bugs are not opened against X-grade browsers.
A bit more on the relationship between A and X grade browsers: One unexpected instance of X-grade is a newly-released version of an A-grade browser. Since thorough QA testing is an A-grade requirement, a brand-new (and therefore untested) browser does not qualify as an A-grade browser. This example highlights a strength of the Graded Browser Support approach. The only practical difference between A and X-grade browsers is that QA actively tests against A-grade browsers.
Unlike the C-grade, which receives only HTML, X-grade receives everything that A-grade does. Though a brand-new browser might be characterized initially as a X-grade browser, we give its users every chance to have the same experience as A-grade browsers.
Mert eloszor atkonvertaljak a 64 bites floating point-ban tarolt szamot 32 bites signed integerre, aztan shiftelik es utana visszakonvertaljak az eredmenyt 64 bites floating point-ba.
Tehat a shiftelgetes itt lassabb lesz mintha siman megszoroznank mondjuk kettovel az erteket.
&& operator
if (a) {
return a.member;
} else {
return a;
}return a && a.member;|| operator
var last = input || nr_items;input is truthy, then last is input, otherwise set last to nr_items.)
var a = 5
var b = “5″
Print(a == b) //True
Print(a === b) //False
Falsy values:
All other values (including all Objects) are truthy “0″, “false”
Es azzal egyutt, hogy a NaN azt jelenti, hogy Not a Number, a tipusa megis number:
Print(typeof(NaN)) // number
Tehat az Crackford tanacsa, hogy ha penzzel szamolunk akkor szorozzuk fel szazzal az operandusokat, vegezzuk el a szamitast majd az eredmenyt osszuk vissza szazzal.
When I talked to ISV, they often just want to use the .NET Framework as an implementation detail of their applications.. they don’t want their users to have to go to windows update or MSDN to download the framework, and they don’t want to have some Microsoft setup UI popping up during the install experience of their application.
For this scenario, we have a little known feature of setup where you can install it the .NET Framework silently.. that is with no-UI popping up at all. This allows you to have full control of the experience…
For .NET FX 3.0: the magic command line is: Dotnetfx3.exe /q
See this white paper for more details.
Oh, and if you are still on .NET Fx 2.0, the command is: Dotnetfx.exe /q:a /c:”install /q”
And you can find more out here.
Precisely what mathematicians mean by “lifted”.
Suppose we’ve got a function f which maps values from a set A into a set B. That is f:A→B.
Suppose further that null is not a member of either A or B.
Now consider the sets A’ = A ∪ { null } and B’ = B ∪ { null }
We define the “lifted function” f’ as
f’:A’→B’ such that f’(x) = f(x) for all x ∈ A and f’(null) = null
Similarly, if we had a two-argument function f: A × B → C, we would define f’: A’ × B’ → C’ as f’(x,y) = f(x,y) for all (x,y) ∈ A × B and null if either x or y is null.
What we’re getting at here is that “lifted” means “takes nulls, always agrees with the unlifted version when arguments are not null, maps everything else onto null”.
mature: megfontolt, atgondolt, erett
parseInt(string[, radix])
A radix-et tehat el lehet hagyni csak nem erdemes, mert ha nem adjuk meg akkor a string alapjan probalja megallapitani es ha “0″-val kezdodik akkor 8-as alapunak veszi es peldaul a “011″-bol decimalis 9 lesz, a “08″-bol pedig 0, mert ugye 8 nincs okatlis szamrendszerben.
The following controls do not conform to the standard Click event behavior:
Note The event behavior detailed below happens whether the user clicks on an item or not (that is, a mouse click or double-click anywhere within the ListBox control raises these events).
Note The event behavior detailed below happens whether the user clicks on an item or not (that is, a mouse click or double click anywhere within the ListBox control raises these events)
Note The event behavior detailed below happens whether the user clicks on the edit field, the button, or on an item within the list.
Note The event behavior detailed below happens only when the user clicks on the items in the ListView control. No events are raised for clicks anywhere else on the control. In addition to those described below, there are the BeforeLabelEdit and AfterLabelEdit events, which may be of interest to developers wishing to use validation with the ListView control.
Note The event behavior detailed below happens only when the user clicks on the items themselves or to the right of the items in the TreeView control. No events are raised for clicks anywhere else on the control. In addition to those described below, there are the BeforeCheck, BeforeSelect, BeforeLabelEdit, AfterSelect, AfterCheck, and AfterLabelEdit events, which may be of interest to developers wishing to use validation with the TreeView control.
Sometimes, when writing SELECTs, we come across situations in which we we need to write a join containing a condition of some sort. You might think to do this with either a CASE expression or with some OR boolean logic in your JOIN expression. Often, you might encounter syntax errors, performance problems, or results not being returned the way you expect when trying this. There’s a much better way to approach the problem.
Instead of trying to alter a single INNER JOIN’s relation from row to row, instead use multiple LEFT OUTER JOINS in your SELECT, one for each table or condition that you need to consider.
ISNULL(Transact-SQL): Replaces NULL with the specified replacement value.
De a lenyeg:
If you want to know whether the browser that views your page supports certain objects you want to use in your code, you should never EVER use a browser detect.
Instead, we simply look if the browser supports the object (method, array or property) we want to use. Let’s continue with the mouseover example. This script relies on the document.images array, so first and foremost we’ll have to detect if the browser supports it. This is done by
if (document.images)
{
do something with the images array
}
Another common detect is for window.focus. This is a method (a command by which you tell JavaScript to do something for you). If we want to use the method, we’ll have to check first if the browser supports it.
Note the correct way of doing this: you ask for the method without brackets. This code
if (window.focus)
means: “If the focus method is supported”, while this code
if (window.focus())
means: “If you can put the focus on the window” and assumes that focus is supported. If it isn’t, this line of code creates errors. The brackets () actually execute the focus command, which is not what we want in this case. So we check it without the brackets (see if it exists) and only when the browser passes the check we actually execute the command by adding brackets:
if (window.focus) window.focus()
So the whole point is that if you want to use the array document.images, first check if it is supported. If you want to use the focus method of the window, first check if it is supported.
If you always use object detection, your scripts will never generate any error messages, although they might not work in certain browsers.
The premise for graceful degradation is to first build for the latest and greatest, then add handlers for less capable devices.
…
Another common occurrence in sites built from the graceful degradation point of view is the noscript element. You provide some feature based on JavaScript and add a more basic version for user agents that do not support JavaScript or have client-side scripting disabled.
…
There is one problem with noscript, though. I may use a browser that supports JavaScript and has it enabled, but there could be a company firewall that strips incoming JavaScript for security reasons. In this case the noscript element will not be rendered (because my browser supports scripting) but the JavaScript code that should create the menu won’t be applied either, because it gets stuck behind the firewall.
Progressive enhancement starts at the opposite end from graceful degradation: begin with the basic version, then add enhancements for those who can handle them.
…
The most common occurrence of progressive enhancement is probably the external CSS style sheet.
…
This is progressive enhancement: it works for everyone, but users with modern browsers will see a more usable version.
Persze kell egy Print fv. is, hogy ez mukodjon.
unobtrusive: diszkret, szereny, tartozkodo, nem tolakodo, nem feltuno