Well, not a hoax but greatly exaggerated claiming IE memory leaks are gone forever. Joel Webber of the GWT team dug intot his claim to see if the “too good to be true” announcement was just that.

When I saw this article, I nearly spilled tea all over the keyboard. They really fixed this issue? You mean I can untangle all the painful code in GWT that works around this issue, diligently cleaning up all its circular DOM references under all sorts of circumstances?

Before I got too excited, I had to do a little gut-check. Did they really go back and make it possible for their garbage collector to chase references through COM objects? That would be wonderful, but I’m not holding my breath.

And it’s a good thing, because there’s basically no way in hell they did that. In fact, it turns out that all they did was write a little code to sweep the DOM on unload and clean up all the extant circular references on those elements. This means that *all elements not still attached on unload are still leaked, along with the transitive closure over all references Javascript objects*. In even marginally complex applications, that means you’re still going to leak like a bloody sieve!

Joel wrote this script to prove his claims. This was just another half-assed attempt by MS to fix a critical bug in there browser.

Jon Sykes blogged about a memory leak he happened upon that, potentially, can have huge consequences memory wise when dealing with the FORM DOM element. Jon outlines the problem and why it is a problem to developers.

What is the leak?

Apparently if you try to remove/destroy/trash a FORM dom node in IE6, it won’t delete it, instead creating a bizarre orphaned node stuck sucking up memory until the browser window is refreshed.

Why is this an issue?

If you have a “web application” that uses any form of partial page loading, and the content you are loading contains any form elements, in IE6 memory usage will climb as you use the app, leading to initially a sluggish browser and finally total terminal failure.

As many of the toolkits these days come with this style of content loading mechanism (take for example my toolkit of choice dojo, with it’s contentPanes), it’s very easy to get into a situation where your webapp will be unacceptable to folks using IE

There are occasions when you do not know what stylesheet to use at design time and must make this decision at runtime. Depending on your target audience JavaScript may be the method you wish to use to implement this.

To any developer that is familiar with JavaScript, DOM in particular, they may think this will be a simple task. Well, it should be but Internet Explorer doesn’t play nice in this case. Should we be surprised?

The logical, and standards compliant way, would be to do this.

var ss = document.createElement("link");
ss.type = "text/css";
ss.rel = "stylesheet";
ss.href = "style.css";
document.getElementsByTagName("head")[0].appendChild(ss);

Seems simple enough. Now this method will work when applying the stylesheet to the parent page but if you use this method to apply it to the head of an iframe then you will get problems in IE.

Let’s take a look at some code, assuming we have an iframe on the page witht he name “frame”:

var ss = document.createElement("link");
ss.type = "text/css";
ss.rel = "stylesheet";
ss.href = "style.css";

var iframe;
if(document.frames)
	iframe = document.frames["frame"];
else
	iframe = window.frames["frame"];
iframe.document.getElementsByTagName("head")[0].appendChild(ss);

You would expect the the above code to work, and it does in every browser except IE. Now this stumped me for quite a while. I search all over Google in search for a solution. After a lot of searching I did find the answer, Google truly is your friends. The code below will work cross browser and apply your stylesheet to your iframe.

var ss = document.createElement("link");
ss.type = "text/css";
ss.rel = "stylesheet";
ss.href = "style.css";

var iframe;
if(document.frames)
	iframe = document.frames["frame"];
else
	iframe = window.frames["frame"];
if(document.all)
	iframe.document.createStyleSheet(ss.href);
else
	iframe.document.getElementsByTagName("head")[0].appendChild(ss);

Hopefully this saves you some searching and frustration.

Steven Levithan, of RegexPal has come up with a great function for creating and destroying elements that is blazing fast compared to innerHTML.

1000 elements…
innerHTML (destroy only): 156ms
innerHTML (create only): 15ms
innerHTML (destroy & create): 172ms
replaceHtml (destroy only): 0ms (faster)
replaceHtml (create only): 15ms (~ same speed)
replaceHtml (destroy & create): 15ms (11.5x faster)

15000 elements…
innerHTML (destroy only): 14703ms
innerHTML (create only): 250ms
innerHTML (destroy & create): 14922ms
replaceHtml (destroy only): 31ms (474.3x faster)
replaceHtml (create only): 250ms (~ same speed)
replaceHtml (destroy & create): 297ms (50.2x faster)

/* This is much faster than using (el.innerHTML = str) when there are many
existing descendants, because in some browsers, innerHTML spends much longer
removing existing elements than it does creating new ones. */
function replaceHtml(el, html) {
        var oldEl = (typeof el === "string" ? document.getElementById(el) : el);
        var newEl = document.createElement(oldEl.nodeName);
        // Preserve the element's id and class (other properties are lost)
        newEl.id = oldEl.id;
        newEl.className = oldEl.className;
        // Replace the old with the new
        newEl.innerHTML = html;
        oldEl.parentNode.replaceChild(newEl, oldEl);
        /* Since we just removed the old element from the DOM, return a reference
        to the new element, which can be used to restore variable references. */
        return newEl;
};

Shaun Inman has demonstrated in a great article how to customize file inputs. Thought to be impossible to style, Shaun proves that with a little imagination anything is possible.

We start with a simple replacement. The custom button image is set as the background-image of our wrapper element and dimensions are set to match.

Next we set the opacity of the file input itself to zero, effectively making it invisible but still clickable (something that can’t be achieved with display: none; or visibility: hidden;).

Finally, the JavaScript keeps the button portion of the the file input underneath the pointer whenever the mouse enters the wrapper element. A class of SI-FILES-STYLIZED (also configurable) is applied to the html element of the page for use as a styling context for compatible browsers.

by Anuj

To a beginner programmer the biggest question is where to start. Which language to choose from the mighty pool of 100’s of languages.

This is was the same question I asked myself when I started writing my first program. I tried many languages but finally I came to C, the most beautiful and charming language of all. I was literally blown away by the simplicity and elegance of C.

Though C is simple it is one of the most powerful languages ever created.

In this dynamic IT world new language come every day and get obsolete, so there must be something in the C which has remained there for 3 decades and more and even today there is hardly any language which can match its strength.

90% of the starting programmer says that C has been superseded by its predecessors such as C++, Java, and C # and so on so why learn C. I don’t know why they think so but I know one thing that they will never excel the other 10% programmers who differs from this opinion. Simple reason is how could a skyscraper building stand against time if its foundation is not strong.

C was the programming language developed at AT & T’s Bell Laboratories of USA in 1972. It was written by a man name Dennis Ritchie.

Now Let us begin to analyze reason why C should be your first programming language.

1. I believe nobody can learn C++ or Java directly. To master these languages you need to have a strong concept of programming element such as polymorphism, classes, inheritance etc. Simple question is how you can learn such complicated concepts when you don’t even know about the basic elements such as block functions. C is a language which begins from scratch and it has foundational concepts on which today concepts stand on.

2. It is language on which C++ is based on, hence C# also derive its origin from the C. Java is also a distant cousin of C and share the same programming concept and syntax of C. These are the most dominant languages in the world and all are based on C. To rock the world through them you must get rocking with C.

3. C++, Java, and C # make use of OOP (Object Oriented Programming). Not all programs need it even though it is a powerful tool. Such programs are still written in C.

4. When ever it comes to performance (speed of execution), C is unbeatable.

5. Major parts of the Windows, Unix and Linux are still written in C. So if you want program these OS or create your own you need to know C.

6. Device drivers of new devices are always written in C. The reason is that C provides you access to the basic elements of the computer. It gives you direct access to memory of your CPU through pointers. It allows you to manipulate and play with bits and bytes.

7. Mobiles, Palmtops, PDA’s etc are gaining popularity every second. Also appliances such as T.V., Refrigerators, and Microwaves etc. are becoming an integral part of our daily needs. You may not know but they have a CPU with them which do need programming and the software’s written for them are known as embedded system programs. These programs have to be fast in execution but also have a very little memory. No question why C is ideally suited for embedded system programming.

8. You must have played games on your PC. Even today these astounding 3D games use C as their core. Why? The simple reason who will play the game when it takes a lot of time fire a bullet after you have given command from the console. The reply to the command should be damn prompt and fast. Reply in 1 Nano second is an outstanding game; Reply in 10 Nano seconds is crap. Even today there is no match for C.

9. C is a middle level language. There are three types of language – High Level, Middle Level & Low Level. High level languages are user oriented, giving faster development of programs, example is BASIC. Low level languages are machine oriented; they provide faster execution of programs. C is a middle level language because it combines the best part of high level language with low level language. It is both user and machine oriented and provides infinite possibilities.

10. Last but not least it is a block structured language. The first symbol of a modern language is that it is block structured. Each code exists in separate block and is not known to code in other block providing easy means of programming and minimizing the possibilities of undesirable side effects. C is designed from the base to top to be a block structured language. Many older languages, most popular being BASIC tried to introduce this concept but their short coming can never fulfilled as they were never built along these line.

I think I have given all reason I know why c should be your first programming language. One thing is for sure that there no other language which more reliable, simple and easy to use.

by Adam McKerlie

The C programming language was first developed between 1969 and 1973 by a team from Bell Telephone Laboratories. Many of the principles and ideas used in this language were taken from the programming language named ‘B’ (created by Ken Thompson) as well as its ancestors BCPL and CPL (Combined Programming Language and Basic Combined Programming Language respectively). Dennis Ritchie was the main person responsible for converting the C language from B but there were many others that helped such as: Ken Thompson, Alan Snyder, Steven C. Johnson, and Michael Lesk.

People soon realized C’s power and flexibility. Because of this, the Unix operating system which was originally written in assembly language, was re-written in C. Because of this popularity many colleges and universities chose to adopt this new language because of its ties to Unix and the abundant availability of compilers.

By 1983 there were many different C compilers as well as many different interpretations of the language. This lead to portability issues (the ability to use the same code on different computer systems) and by the end of the year the American National Standards Institute (ANSI) formed a committee to establish a standard specification of C. By 1989, the standard was ratified and was referred to as ANSI C, Standard C or C89.

In 1990, the ANSI C (with a few minor modifications) was adopted by the International Organization for Standardization (ISO) and became known as C90. Since then the only large revision to the standard was in 1999. This new revision was adopted by ANSI in March of 2000 and is know called C99. This is the most recent standardization of the C language and is the most commonly used.

While C hasn’t had any major revisions in almost eight years it has influenced many different languages. A few of the more notably languages include: C++, D and Objective-C.

The link included is a picture of the history of Programming.

http://www.levenez.com/lang/history.html

I find myself eagerly awaiting the beginning of each new months to see how much browser share IE6 has lost. Sadly in August IE6 only fell 0.65%. It seems we have hit a threshold of IE7 adoption.

This is of concern to me as a web developer because as bad as IE6 is and the fact that IE7 only fixed a few glaring problems having to support both, each with it’s own unique challenges, is far, far worse. Personally I have desided to stop supporting IE6 once it drops to 5% of browser share. Sadly this could take a while as it is still sitting at 44.59% and dropping agonizingly slow.

I am considering going as far as displaying a noticable but unobtrusive message on the login screen of my applications encouraging upgrading to IE7, or even better yet, Firefox.

Anyone else care to share their opinion on this?

Miguel Castro points out a problem he found in VS2008 beta that could save others some time in finding hte problem.

I started using nested Master Pages in Orcas last week and ran into a small snag. I could not get a break point to fire on the Page_Load in the child Master Page’s code-behind class. In fact I noticed that the code wasn’t running at all. After 30 minutes of beating my head against the wall, I tried changing the Page_Load method to an override of OnLoad and that worked perfectly. Then it ocurred to me to check the AutoEventWireup value in the Page directive and sure enough it was set to False. This is the first situation I’ve seen where it does not default to True so if you come across this, jump straight there and you should find the problem.

Jonathan Schemoul has released SmoothGallery 2.0

Unlike other systems out there, JonDesign’s SmoothGallery is designed from the ground up to be standard compliant: You can feed it from any document, using custom css selectors.

And even better, this solutions is very lightweight: The javascript file is only 24kb.

The major new features are:

* Back and forward buttons of your browser now controls the gallery. Moreover, you can send that url up there to a friend, he will see exactly the same slide on the gallery than you. This is called HistoryManager.

* You can have multiple galleries on one place and switch between galleries. This is called Gallery Sets.
* Tired of that smooth fade-in of pictures ? SmoothGallery now supports transitions between slides.

* Don’t want to use all of your bandwidth for some galleries ? SmoothGallery now includes a real preloader and loads only what is needed, while giving feedback to the user on the progress (Most of the time, users won’t even see a loading bar, as SmoothGallery tries to load what the user could want to see).