Stephen Donner's Weblog

The reason is that var, const, and function statements are "hoisted" to the top of the containing block. Although the actual initialization will not happen until line two of showScope, "scope1" is defined as a local variable right from the start, shadowing the global "scope1". This is equivilant to...

function showScope()
{
var scope;
alert("The value of scope1 is" + \n + scope1);
scope1 = "SCOPE1";
alert("The value of scope1 is" + \n + scope1);
}

You may notice the effect of function hoisting when you have a situation like...

funciton foo() { something(); }

x += 1;

function bar() { somethingElse(); }

...where x is not defined. This will generate the runtime error "x is not defined", but the script will appear to "continue" on to define bar() despite the error.

Actually, it'll give you a syntax error, because the \n needs to be inside quotes. I think what you meant is:

alert("The value of scope1 is \n" + scope1);

Okay, I just told you what Apple wants you to look out for with window positions, but in the real world, not everyone uses the hiding feature of the Dock, and it is unrealistic to be able to predict where each user will place their Dock at any given day or how large they will have it. However, you can build a feature into your application that allows spacing for the Finder. You can give users the option of where to position their windows and what area of the screen not to cross. I know that BBEdit provides me with this feature, and I wish more developers gave me more control over my windows.

For my Paint application, I created a series of icons to simulate a rendering algorithm. While the application is performing this CPU-intensive task, you can always see the status of the document by the icon changing in the Dock.

The simple fact is that, when all other factors are equal, where will consumers spend their money? I believe that in the long run, the best looking, easiest-to-use applications will also be the most successful. I think that's why Apple encourages developers to write programs that are 100 percent Aqua-compliant.

Adopt Sheets. I really like the use of Sheets in OS X. The use of Sheets lets me know which window my dialogue belongs to without hijacking my system.

For my Paint application, I created a series of icons to simulate a rendering algorithm. While the application is performing this CPU-intensive task, you can always see the status of the document by the icon changing in the Dock.

In building your amazing Aqua application, one of the most important things to consider is the Dock. There are three things your app needs to be "Dock Compliant." Now, I write this knowing that the Dock will be going through some major changes soon, but for the most part, these should still hold true.

Okay, I just told you what Apple wants you to look out for with window positions, but in the real world, not everyone uses the hiding feature of the Dock, and it is unrealistic to be able to predict where each user will place their Dock at any given day or how large they will have it. However, you can build a feature into your application that allows spacing for the Finder. You can give users the option of where to position their windows and what area of the screen not to cross. I know that BBEdit provides me with this feature, and I wish more developers gave me more control over my windows.

But limit your animations to whatever is required to communicate the necessary information. Avoid annoying animations that discourage ease of use. Ask yourself, "What do I need to show the user, and what is the cleanest way possible to achieve that?" A good example is the Mail application for Mac OS X. Whenever a new message arrives, the Dock icon changes appearance to indicate a changed state.

For example, if you see an AIM window peeking out from behind your browser and you click on it, that window will come to the front, but the main application window will not. The Mail.app/Activity Viewer is another example. The Aqua system of layers works well in many instances, but not in all. Thank goodness that the Dock is always there to come to the rescue. I know that clicking on an application icon in the Dock will always result in not only the application coming to the front, but also any non-minimized windows associated with it. And if the application is active but no windows are open, clicking on the Dock icon should create a new window in that application.

Due to the positioning of the Dock, remember that when you build an application, you have to be sure that new document window sizes and positions do not violate the Dock's space. Dock is temperamental and Dock loves his space. If you default to a window size that expands behind the dock, users will have a difficult time reaching the navigation and resize areas at the bottom of the screen. I can personally say that more than once I have been rather peeved that I couldn't get to an area of the window to resize because the default window settings always pop up behind the Dock. In addition, the new Dock in 10.1 will allow users to position their Dock location on either side of the screen as well.