Brahma Kamal

To see one is lucky, I saw 24 at a time in my building. Brahma Kamal known as king of Himalayan flower. Its botonical name is Saussurea obvallata. It is a species of flowering plant named after Brahma, the Hindu god of creation. It is native to the Himalayas, India, Northern Burma and South-West China.

The Bramha Kamal is a rare lotus named after lord Brahma, the creator in Indian Mythology. It is considered very lucky to see it bloom and blooms around midnight. White it blooms the buds emit a strong fragrance. The buds start late evening after sunset and reach full bloom by midnight. This bloom only survives for that single night.

The Crimson Room Cheat Solution

I cheated and solved
the Crimson Room
and I don't care.
Want to solve it too?
brought to you by b-sting.nl

moock.org>> asdg>> technotes>> skinning the V2 ProgressBar component

moock.org>> asdg>> technotes>> skinning the V2 ProgressBar component

Creating Components

Creating Components

Mastering the Array

Mastering the use of Arrays is important in any programming language. But it's especially important in ActionScript. The skills you learn by commanding arrays can easily be applied to just about every object in Flash.

Everything in Flash is an Object. And, an Object can also be treated as an associative array. For example, we can use dot-syntax to access an object's property or method as in: myObject.property. Or, we can use array brackets as in: myObject[“property”].

When I'm trying to learn about a new object, an easy way to see what properties and methods it exposes is to loop through the object and trace out the properties and methods it contains. I use this simple script to explore an object:

exploreObject = function (o) {

for (var i in o) {

trace (i + ": " + o[i]);

}

}

exploreObject(button_mc);

In this example, you could take a button component and place it on the stage. Give it an instance name of button_mc, and run the script. This will trace out all of the properties and methods of a button component. You can then look through it to find the property or method you are looking for. Sometimes you'll find additional objects as properties of the first object you are exploring. You can easily loop through them by passing them into the same function as in: exploreObject(button_mc.textStyle);

Strings are another object in Flash that can be thought of as an array. Although they are also an Object they can also be thought of as an array of characters. Strings and Arrays both have length properties, allowing you to loop through them and evaluate their contents. You can easily convert a string to an array and vice-versa. This trick is useful if you are loading external data into flash. You could load a delimited list of data into Flash as a string, and then split it into a data array by the delimiter, as in: var myArray = myString.split(“,”);

Being able to easily split strings into arrays and then back into strings also makes for a simple and elegant way of creating a String replace function. If we write this using the String.prototype, all Strings every in our Flash movie will be able to use this replace function.

String.prototype.replace = function(replaceString, withString) {

var myArray = this.split(replaceString);

return(myArray.join(withString));

};

When we call this function, we'll pass two parameters into it. The first is the substring we want to replace and the second is the string we want to put in its place. When this function is called, it uses the String.split() method to break the string into an Array, called myArray. The split method uses a string that is passed into it, in this case our replaceString, and everywhere this string is found, it breaks the original string into a new element in the array, removing the delimiter.

The Array.join() method does the same thing, but in reverse. It takes each item in the array, converts it to a string and inserts a specified delimiter, in this case withString, in between each array element, creating a single String. Here is an example of how it is used:

var s = "The red dog ate the red frog";

trace(s.replace("red", "green"));

These are two very simple examples, but they illustrate the power of understanding how to manipulate objects as if they were arrays. In my next tutorial, we'll build further on Arrays, exploring multi-dimensional arrays and ways that we can use them to store complex data.

Flash & FSCommand

Hi,
If you have worked with Flash & FSCommand, you must have been frustrated with its dodgy behavior. That’s because FSCommands have a MAJOR drawback.

The Flash player runs FSCommands asynchronously, after all Action Script in the frame is completed. And this limitation forces you into a complex web of work arounds. For example, let's say your application needs to check for a net connection and download a file. Using FSCommands, you might write the following code. You'll find it does NOT work. Can you figure out why?

FSCommand ("checkconnection", "connectionIsAvailable");
if (connectionIsAvailable == "true") {
// download file
} else if (connectionIsAvailable == "false") {
// do something else
}

The code fails because connectionIsAvailable does not exist. The Flash player executes the FSCommand after the native ActionScript completes (after the IF statement) and returns a value to connectionIsAvailable only after the movie advances a couple of frames.
To make this simple example work using an FSCommand-based solution, you are forced to split the code into two frames -- running the FSCommand in frame 1 and the IF statement in frame 3.

What does Object-Oriented Design Mean to You?

What does Object-Oriented Design Mean to You?

In today's world, you're just as likely to see a resume that says object-oriented design as you are to see a bachelor's degree. After more than a dozen years of sitting on a shelf, it seems like suddenly people are interested in object-oriented programming. Perhaps that's because Microsoft .NET and Java languages are all purportedly object-oriented languages. It seems like everyone believes that, if they are using an object-oriented language, they're doing object-oriented design. Nothing could be farther than the truth, and here's why.

Object Oriented Languages Do Not Make Object Oriented Developers

Object oriented languages do not automatically make programmers into object-oriented developers. Saying that I'm an object-oriented developer because I've used an object-oriented language is like saying that, because I have a bottle of wine, I'm a wine connoisseur. (For the record, my knowledge of wine is red, white, and blush.)

An object-oriented language merely makes it easier for you to implement the good programming practices that you already know. You know to minimize the impact of changes through encapsulating your data and code together. You know that you should keep the code similar and minimize the dependencies between different sets of code. An object-oriented language facilitates these and other programming goals.

Becoming an object oriented developer means studying concepts and learning to apply them rather than simply learning a new language.

Objects Don't Make an Object Oriented Design

The funniest thing I have ever heard an interviewee say was, "I've created dozens of objects-yes, and I'm an object-oriented developer." It was funny because it made object-oriented programming sound like an accident. It wasn't something he thought about, but it was something that happened to him without his knowledge. That's about as far from being an object-oriented developer/designer as you can get.

In C#, it is mandatory to create objects. However, that doesn't mean that you're doing object-oriented development or design. It just means you're working within the requirements of the tool.

Object oriented design and development is a conscious thing. It's focusing on organizing information and code into meaningful objects that perform meaningful processes on data.

An Object is

One of the fundamental tenets of object-oriented programming is that an object is modeled after a real world concept. For instance, an object representing a dog might have a tail. The dog might perform the action of walking or eating. The object is modeled after its real world counterpart.

This works well with a concrete object; however, it gets more complex when dealing with abstract objects. For instance, catalog objects have products in them, they have methods that search for products, and they may also have other properties and methods that a physical catalog might not have. When you start to layer the properties and methods, the traditional physical objects begin to lose their focus and have trouble assigning those properties and methods.

One of the keys is to think of how the physical item would behave if it wasn't limited to the physical form. Focusing on the attributes it would take on in an electronic form can help you keep focus on where you put properties and methods.

Coupling and Cohesion

Two classic programming problems are coupling and cohesion. Coupling is a factor that, in general, should be minimized. Coupling refers to the interrelated aspects of different parts of code. Whenever you make one object dependent on another for its operation - or one system dependent on another for its operation, they are coupled. One problem with coupled systems or objects is that, when one changes, it exposes the other to potential problems.

When one object looks inside of another for its operation, rather than using defined interfaces, changes in the internal operation of that object can make the other object operate incorrectly. These subtle interactions between multiple objects can be difficult or impossible to locate.

The second problem is that coupled objects need to be changed together. Even if you avoid the debugging nightmare of not knowing which objects are related to one another, they must still change their function when the coupled objects change.

One obvious exception to the coupling rule is collections. Collections are necessarily coupled with the objects that they contain so that they can return specific type information. They are coupled in other ways as well, as they may need to rapidly create large numbers of instances of the objects they contain.

Like collections, there are other special situations when, used appropriately, coupling isn't a bad thing, and in ways that are clear to even the casual observer, coupling can be a necessary part of software development.

The most closely related concept to coupling is the concept of cohesion. Cohesion answers the question, should an object be one object or more than one object? A cohesive object is one that cannot easily be broken up into multiple objects. It is an object that has one clear purpose and one clear entity that it represents.

It is also applied to those situations when an underlying object is needed. For instance, if you have a dog object and a cat object, you have two objects that have many similarities. Without an underlying object that encapsulates that similar functionality, you risk rewriting the same code. Both cats and dogs are animals and mammals. As a result, a dog object may not be a cohesive object - unless it is derived from objects such as "mammal," which in turn is derived from "animal."

Conclusion

Object oriented design is more than a language. It's not some path that you can follow blindly. It's a winding road that requires concentration. However, there are rewards. Quicker development times, fewer defects in your code, and a more maintainable masterpiece can be yours if you can keep from falling off the path.