Associative arrays

Associative arrays, which are sometimes called hashes or maps, use keys instead of a numeric index to organize stored values. Each key in an associative array is a unique string that is used to access a stored value.

There are two ways to create associative arrays in ActionScript 3.0. The first way is to use the Object constructor, which has the key advantage of allowing you to initialize your array with an object literal. An instance of the Object class, also called a generic object, is functionally identical to an associative array. Each property name of the generic object serves as the key that provides access to a stored value.

The following example creates an associative array named monitorInfo, using an object literal to initialize the array with two key and value pairs:

var monitorInfo:Object = {type:"Flat Panel", resolution:"1600 x 1200"};
trace (monitorInfo["type"], monitorInfo["resolution"]);
// output: Flat Panel 1600 x 1200

If you do not need to initialize the array at declaration time, you can use the Object constructor to create the array, as follows:

var monitorInfo:Object = new Object();

After the array is created using either an object literal or the Object class constructor, you can add new values to the array using either the bracket operator ([]) or the dot operator (.). The following example adds two new values to monitorArray:

monitorInfo["aspect ratio"] = "16:10";
// bad form, do not use spacesmonitorInfo.colors = "16.7 million";
trace (monitorInfo["aspect ratio"], monitorInfo.colors);
// output: 16:10 16.7 million

Note that the key named aspect ratio contains a space character. This is possible with the bracket operator, but generates an error if attempted with the dot operator. Using spaces in your key names is not recommended.

The second way to create an associative array is to use the Array constructor and then use either the bracket operator ([]) or the dot operator (.) to add key and value pairs to the array. If you declare your associative array to be of type Array, you cannot use an object literal to initialize the array. The following example creates an associative array named monitorInfo using the Array constructor and adds a key called type and a key called resolution, along with their values:

var monitorInfo:Array = new Array();
monitorInfo["type"] = "Flat Panel";
monitorInfo["resolution"] = "1600 x 1200";
trace (monitorInfo["type"], monitorInfo["resolution"]);
// output: Flat Panel 1600 x 1200

There is no advantage in using the Array constructor to create an associative array. You cannot use the Array.length property or any of the methods of the Array class with associative arrays, even if you use the Array constructor or the Array data type. The use of the Array constructor is best left for the creation of indexed arrays.

Curious About Brady?

Macromedia just published a new Logged In article with a lot of great information on Brady, Macromedia's new Flex IDE (which just entered final beta). It contains some pretty detailed descriptions, and several good screenshots. Here's a little taste:

Brady is the Macromedia IDE for Flex application development. Designers and developers can be more productive building Flex applications through tight integration between the IDE and the server. Developers can learn MXML and type code more quickly and accurately using Brady's code hinting feature. More visually-oriented programmers can use the drag-and-drop Design view to quickly lay out Flex interfaces and style them using CSS....Check this

linkhttp://www.adobe.com/devnet/logged_in/hb_williams_brady.html

FLEX can change context.

Context is when you look at a situation from a perspective and generally fall into a predefined segment. In that, if I look at say Microsoft Word, my context of use is to read a document - yet others may use word to construct a document. So different roles play different parts, thus the segments of the technology is defined by context.

Adobe FLEX, is one of these products that can reshape and redefine context under the guise of being passive while unbeknown to others, it's quite aggressive in the way it hijacks segments of use. A year ago, I meet up with a fellow-FLEX developer, who showed me approaches to using the language that I guess challenged the way in which I've approached technology. The way in which he did this, was he showed be a before and after approach to the same software, yet one had FLEX and what had HTML. It was pretty much a straight forward deal; on one side you had an ugly HTML User Interface (UI) while on the other you had this rich vibrant UI.

The rich vibrant UI was the easier sell, as lets face it, we do tend to at times judge a book by its cover - sorry, it does happen. Yet, one thing that stood out from the start that I couldn't quite explain to others that he conveyed to me was that the perception was changed or be it, context.

You see, there wasn't just a sexier UI over the top, no, what was really changed was the fact that instead of seeing a HTML List of names, suddenly we were seeing a directory of documents. Yes that's right, documents which suddenly changed folk's perceptions or context of use.

Looking at a HTML list, it's vanilla and doesn't provide you much in terms of interaction. You move your mouse over it, at times there maybe style updates but other then that it's still simply a plain old list. A developer could spice things up, by allowing a context box to hover under the mouse point as one moves over the list item, giving more detailed look into what's behind this list item link which the developer may get some applause for.

Yet, what this co-flex-developer did was change the context of the data's use, by turning a list item into a document. So now, end users could be expected to now approach the exact same data set (being for this example, a persons name and say their personal information) with pre-defined expectations.

The end-user could arguably, click on the document of the persons name and then expect to carry out actions such as copy or print? The end-user could also expect to double click on the document and see a more detailed view of the end user in a report style approach. The list could go on.

So now, the context of use has changed, and it was done by trickery using technology such as FLEX.

Now, comes the AJAX zealots, I see you, sitting in the front row ready to pounce on any mention of how great FLEX is. AJAX can do the above, no question about it, but it could also be more work to get to that point and lets face it, hunting and gathering the data in an efficient timely manner with richer UI that's controlled 100% by the agent in which its viewing across all manners of operating systems - is well... harder then it looks.

To do the above, is basically really small amount of work - in fact the hardest part is deciding whether you want to use SOAP (maybe you do want to appease the AJAX zealots while giving the FLEX hand a try) or AMF as your gateway access to such data.

The overall point I have is that FLEX can really shift context into gear, it can not only provide radical adjustments to the perception of how data will be used within UI, but it can also be used as a bridge or conductor if you will over how disparate backend technologies can be bridled.

It's got an easy approach to getting the visuals out of the way, so one can focus more on data transmissions back and forth. It can work closely with DOM by not only allowing it to be overlayed on top but it can also provide a much faster turn around in injecting packets of HTML into the DOM Hierarchy given via server-side. Injecting DOM via FLEX is simple, while at the same time through E4X, flex provides a faster way to decouple portions of HTML before DOM injection occurs.

So as you can see, not only is FLEX adjusting context of visual elements within software, but it can also adjust context of how data is swapped around through different tiers. It's the filter if you will to all, and this filter has been governed by context.

Context is why FLEX should be used, not because "all the kids are doing it".

For my next pet-project, i'm looking at ways to combine Contribute and FLEX. *shrug* who knows what I can uncover in this unchartered space.

How does FLEX relate to Business Process?

If you have read my blog over the past 3 months you would of learned that I've switched from being a code monkey to being a "manager" and it's been hell let me just say that.
It's been hell for a number of reasons, mainly because I'm not allowed to code and yet there are so many things I could "fix" for my staff and the company I work for. Sadly though, the role I'm in is non-IT (Marketing) so I have to sit on my hands and let others do the "doing" while I work on the "strategy".

There is but one thing that stands out the most and its one that I can see FLEX being an amazing asset to cope with the overwhelming problems that have arisen in the past 4 years here at work.

You see, like most large enterprise organisations the company I work for has gone out and bought quite a lot of databases each with their own UI to allow folks to manage data. Most of the software in question is web-enabled ranging from $5k to $10million in price tag, yet each have their own hosting environment and equally their own "way" of presenting the UI.

In walks a guy like me, someone who's now given the task to not only manage a team to support this disparate world of pain but also to bring balance back to the force, something that could take me through to at minimum 2009 to finalise (God only knows how much money is spent in between now and then as well). I look at all the data clusters lying about the place and one thing constantly sits in the back of my mind, FLEX.

How could FLEX solve the pain points I see daily, through my co-managers or from the executive level down through to Ministers of government? I have an answer, and I could easily put that on the table and poke people in the right positions to at very least take a look. It would fail though, and it's simply due to the folks who make the "strategy" decisions don't understand what the technology in question does and how it relates to the Business and more importantly, how it can improve the business.

You see, it's easy for a guy like me, with a FLEX background to walk into the room and say "I've got it; FLEX will solve it all from the UI stand point. We can use UI to bridge the gap between disparate data and combine them under the one UNIFIED VIEW". I know I can say and do this, simply because I understand the business unit I work for and have a fairly good understanding of the wider circle around my business unit - yet - how do you explain this all to someone who firstly doesn't understand what FLEX does (yet barely understands HTML - which is not a negative).

Ok, let's say they do understand FLEX, but how do you still prove FLEX is the answer? Technology has let people down time and time again, so its within reason for all to become an overnight sceptic once some lone manager throws a few buzz words around and people start to wonder "oh gee, another manager who's read an in-flight magazine has the answer" - I could point out my background, but that would be pampas and arrogant so I defer to their assumptions only.

The way to the heart of the problem is defining your business process and how it works today, so you can fix it tomorrow. Business Process Definition is the key to unlocking all problems within an enterprise environment, if you can't tell me on paper how Joe over in Marketing talks to Pete over in Production how the hell can problems between these two be solved.

So in order to prove my theory, I've got my entire team right now building our Business Process in the land of Visio, mapping is going off the charts and I've got more maps then an Atlas being defined. Yet, its now opening up more and more understanding of the world within and around me, it's now giving me evidence that there is a much bigger problem that needs solving and will provide the appropriate level intelligence to formulate an efficient strategy.

My goal is to use a technology like FLEX to provide "CONTEXT" to peoples problems through User Interface. It's not enough to build software that caters to 50% of ALL Lines of Business give or take their needs. I'm more for building a UI Console that sits in front of EACH Line of Business, yet the data between all is common, just the context of how it's used slightly differs.
FLEX or WinFX (XAML) can provide the answer to this in a more efficient and robust form then any other technology today. I could go down the AJAX path, but the problem I've seen with AJAX (especially within these four walls) is that whilst it's a novel idea, if used poorly it can be worse off then using HTML refresh equation. Large data packets at the moment get sent back and forth resulting in constant browser lockups. Its easy to point the finger at "bad programming" but to be honest, that doesn't solve the problem and so a technology that can keep at least the data transmission side of things civil, is something I'd wager is far more important.

FLEX UI Framework using Flex Enterprise Services on top of various databases can bring balance back to the force and solve a lot of problems. If a new solution is bought, and I need to use it for carrying out my business needs then I can sit down with our IT supplier and rationalise the situation with them more accurately whilst at the same time providing them with an enough information in terms of understanding our business process. They hopefully then can make an informed incision into the code bank, adjust the UI fairly easily and spit out UI that caters to the new adjustment.

It can even go further; imagine a world where you could translate business process via languages like BPEL into FLEX UI, on the FLY?

Imagine...Imagine.. Or... you could just simply email omniEffect.com now and stop with the facon bacon, and start living the dream.

The next trick I have, is convincing the seats of power within my workplace, that all their dream solutions can happen and fast, it just requires some due process in defining what their business does first - the technology will solve the rest.

I rate my chances as being more likely to get hit by a hot blonde, driving a Porsche naked then making it happen. Enough reading of dilbert.com has taught me enough that irrational thought amongst many, overrides all rational thinking.

A good RIA (Flash) prediction piece

Flash could overtake QuickTime and Windows Media player as the premier video format for Web, desktop application, and device delivery. Given that Flash video can include a level of robust interactivity that QuickTime and Windows media cannot support, along with its unique runtime alpha compositing features, it is natural that many video publishers will adopt Flash over other choices.?

Gandhi with Child

Stamp issued on International year of child 1979.

Gandhi, Man of the millenium stamp

Mahatma Gandhi, Man of the millenium released in 2001. Cost Rs/- 4

Analyzing Blog Content

Suppose that we bloggers, collectively, wanted to migrate toward HTML coding and CSS styling conventions that would make our content more interoperable. Since none of us is starting from a clean slate, we'd need to analyze current practice. Well, now we can. Here, for example, is a concordance of use cases for HTML elements with class attributes, drawn from the database I'm building: 1. OLDaily: Theory in Chaos 1. Kingsley Idehen's Blog: Enterprise Databases get a grip on XML 1. Erik Benson: Pat Coa 1. Erik Benson: Pat Coa 1. Jeroen Bekkers' Groove Weblog: Groove and Weblogs 2. Kingsley Idehen's Blog: Enterprise Databases get a grip on XML 1. Seb's Open Research: Mario dans Le Devoir

1. McGee's Musings: Russell Ackoff resources on systems thinking

1. Clemens Vasters: Indigo'ed: Back to Business

1. s l a m: Countering The Bush Doctrine

1. McGee's Musings: Russell Ackoff resources on systems thinking

1. Joi Ito's Web: With bloggers inside, Davos secrets are out - IHT article 2. Windley's Enterprise Computing Weblog: Toysight

1. Organic BPEL: Avalon is NOT representing the convergence between the Web and GUI!

1. Comments for Jon's Radio: None

1. Joi Ito's Web: With bloggers inside, Davos secrets are out - IHT article 2. Windley's Enterprise Computing Weblog: Toysight

1. s l a m: Countering The Bush Doctrine

1. Joi Ito's Web: With bloggers inside, Davos secrets are out - IHT article

1. McGee's Musings: Russell Ackoff resources on systems thinking ·

1. Hillel Cooperman: None 2. Rob Howard's Blog: Continued... 3. cbrumme's WebLog: Memory Model

1. Telematique, water and fire.: Server vendors launch management initiative

1. Luann Udell / Durable Goods: Myth #3 about Artists 2. Clemens Vasters: Indigo'ed: Back to Business 3. Rob Howard's Blog: Last post on the topic -- at least for now! 4. cbrumme's WebLog: Memory Model

1. McGee's Musings: Russell Ackoff resources on systems thinking

1. Duncan Wilcox's weblog: Tag Soup

1. MobileWhack: Z600 Accessories, Accessories, Accessories

1. Kevin Lynch: Intel Centrino

1. McGee's Musings: Russell Ackoff resources on systems thinking

1. Duncan Wilcox's weblog: Trusting Corporations

1. Hillel Cooperman: None

1. Telematique, water and fire.: Metro AG and their RFID Plan 1. Kingsley Idehen's Blog: Enterprise Databases get a grip on XML 1. Seb's Open Research: Kottke: Guidelines for learning

1. McGee's Musings: Russell Ackoff resources on systems thinking 1. s l a m: Countering The Bush Doctrine 1. Kevin Lynch: Adam Bosworth on Service Architecture 1. darcusblog: Names (again) 1. darcusblog: Names (again) 1. darcusblog: Names (again) 1. darcusblog: Names (again)

1. darcusblog: Names (again) 1. darcusblog: Names (again) 1. darcusblog: Names (again) 1. ongoing: Genx 1. Seb's Open Research: None 1. Blogging Alone: None 1. Jeroen Bekkers' Groove Weblog: Disruptive in no small measure 1. s l a m: Countering The Bush Doctrine 1. Blogging Alone: None 1. Dive into BC4J: BC4J Mentioned in the Latest Article in the OTN Architecture Series

1. Corante: Social Software: Friendster notes 2. Web Voice: And now for something different 3. Dan Gillmor's eJournal: Electronic Voting: An Insecure Mess, but Full Speed Ahead With only a few days' worth of accumulated content, I wouldn't dare to venture any recommendations about these use cases. But as the picture develops over time, we might start to see opportunities for convergence. Update: I've been hoping for some external validation of this approach, and Giulio Piancastelli provides it today. As part of a much longer posting with lots of detailed technical analysis of RDF-oriented techniques, he writes: What Jon is searching for, I think, is a good balance between the cost of providing metadata and the benefits gained by working on the provided metadata, while trying not to entirely move away from the web world as we know it. In fact, this is probably the most important characteristic of Jon's experiment: he is working with what he is able to find right now, that is lots of HTML documents, which can be converted to be well-formed XML quite easily, and then searched by means of XPath. While these are ubiquitous technologies, it's difficult to find RDF files spreaded around as such: proving that the RDF world is query-enabled, stating that the right place where to put metadata are RDF files because you can probably get higher quality and more complete results is useless if there are little or no data to query. From my personal perspective, I see those two worlds, one working with XML and XPath, the other messing around with RDF and RDQL, still very far from each other. Jon's experiment is helping us to become conscious of the fact we already are on a metadata path as far as web content is concerned: XML and XPath are probably the first steps in this journey, leading us to a more semantic web augmented with technologies which nowadays seems not to be successful, but that will hopefully prove to be useful when more complex needs arise. We can only hope the virtuous cycle will start to spin soon.

Extending the Application class in Actionscript

When creating a custom component, you can either do it mxml or Actionscript. If you want to create a component that contains a number of child components in a specific layout you?ll probably go for mxml, for creating non-visual components or components with modified behavior your best pick would be Actionscript. By adding mx:script tags in your application mxml you?re basically extending the Application class. So if you?re not planning to do much lay-out, want to alter the Applications behavior dramatically or just don?t feel comfortable writing mxml wouldn?t it make sense to just create your custom Actionscript Application component. However the Application is a top level component so you can?t just drop it on the stage or add it as a child to a Display Object Container. The most logical way would be to extend the Application in Actionscript and set it as your default application, but unfortunately Flex does some wacky stuff under the hood (who knows what) when compiling so this doesn?t work. The trick is the create an mxml file as your default application with custom Application component tags and the correct namespace as an attribute. The mxml file will serve as the application entry point and you can go ahead extending the Application class in Actionscript. XML: 1.

2.

3.


Actionscript:

1.
package {
2.
import mx.core.Application;
3.

4.
public class MainApp extends Application {
5.
public function MainApp(){
6.
super();
7.
}
8.
}
9.
}

The Blank Canvas

It just sits there and stares at you; you have Adobe Photoshop open in one window and FLEX Builder in the other. You can kind of see the vision inside your head, but just can't quite convert the "wouldn't it be cools" into PIXELS immediately.

This is something I've faced on and off as with FLEX you basically have un-restricted access to how you want your User Interface (UI) displayed on screen and in a way that can be chrome focused or simply content focused.

My mates have called FLEX the "Unified View" it's the missing link to the puzzle of joining disparate systems together under one Unified View of your choosing. It furthermore, allows folks in large companies to have quite an agile "console" to view their intended context without placing too many restrictions on them.

As of late, getting back into the design mode, I've noted that there is a lot of "Glass" or "Apple-Candy" style UI floating around the shop. I look at the upcoming Windows Vista and get a sense of "hey when did Microsoft grow up design wise?" while at the same time, still to this day enjoy the experience of using OSX.

I like to take slices from both to be honest, a bit of OSX goodness mixed with Vista and see what I can come up with in FLEX. I've taken MS OFFICE 12 menu "ribbon" and ported the same design concept into FLEX and this now has opened up a lot in terms of much needed canvas. Armed with this menu, I can hide while still be proactive in displaying a lot of menu navigational items that are still "easy" to use. It will take of course time with regards to seeing how feasible and usable this approach is, but like a lot of the menu's we see today, there was always a user resistance at first.

I typically tend to start at the chrome level when designing UI, as the rest kind of fits into place as I go. I have a lot of books open with regards to Usability and Information architecture at the ready should I come up with a design that I flag as being potentially hazardous to the end user(s).

For me, the biggest joy I can walk away with in regards to FLEX is knowing that I can build a UI to suite a person's context while still sharing similar or the same amount of information.
A project recently comes to mind, where there are about 5 Line of Businesses that need to access the same data but on different levels and in different context. Some also require additional data from 3rd Party resources but overall there needs to be an application of the same branding in place.

The first knee jerk approach was to look it from a HTML perspective. I won't have that, because I'm the resident FLEX Evangelist so I've opted for FLEX 2. Armed with FLEX one is able to then present these specialized needs to the lines of business but at the same time - here's the kicker - share the same code blocks while also allowing the same data to be shared (Flex Enterprise Services).

It's a pretty product young FLEX, and can't wait to see more applications and more importantly sexy UI on top of FLEX.

FLEX perceptions.

I sat down the other day and had lunch with a fellow Flash Developer I know about our work etc (catch-up) and we got onto the subject of FLEX and what the overall perceptions are.

Personally, from what I've read/been told I'm excited about its potential, and from what I have also read its also had a lot of negativity pinned on it, especially in regards to the effective use of it.

I for the life of me do not know why, the screenshots shown so far for FLEX are simple "hello" world forms. To me this is probably a bad mistake, as people can easily get the assumption that all FLEX is capable of, is to create Flash based forms (woopydoo). If you look deeper into the information, you will note that FLEX offers more than that, it allows you to develop and design an application much like you would with HTML, only this time its cross-platform friendly and you're not limited in browser technology.

I personally come from a CFMX/DHTML background in regards to web development, and over the last 2 years I've migrated my skills easily enough into Flash MX. Flex has answered something that I myself have been looking for and hinting towards for ages (read Macrofun.pvpers.com archives) as quite frankly, making RIA can be formulated easily enough.

I'm a big fan of XUL and how it can instruct a series of controls / components to display themselves on screen, and finally FLEX will allow this to happen with flash technology!

The best part of this is, you're not limited to the V2 component framework, as FLEX will allow you to use you're existing or custom build components, which opens up endless possibilities of branching out into the realm of RRIA (Really Rich Internet Applications) which aren't just forms and validation.

If you create a series of "Components" or Mini-Sub Applications, you could easily deploy visual effects, useful tools etc to an already plain application. One thought I had was take a simple form, render it using FLEX, mix-in some typical validation but now take it one step further, and implement Flash Communication server into the equation. Create a min recorder app, which records audio/video and describe each control inside your form (eg "Name: - please enter your name, the one you where given when you where born").

Then record this video, and then make a component that can dynamically point to the video source.

Once that's been achieved then attach a "help" icon to your form control (via FLEX) and congratulations, with minimal amount of effort, you now have a fully interactive form with rich help control points, without having to do a lot of effort (Sure the flash dev has to create the component once, and the Flashcom recorder - which is very easy thing to do - on all should take less then 4-5 hours of work imho. Once done though, it could be recycled time and time again).

This is just a simple example of a solution that FLEX can provided to the server-side architects/programmers without relying to heavily on the flash developer, as it then takes the focus off him (Furthermore, you could then outsource / delegate the recording of audio etc to others).

To me FLEX isn't just a re-creation of HTML, its more than that, its allowing both parties (Server-side monkeys and Flash Monkeys) to sort of work as a team, but also focus on specific modules rather than constant communication on how a screen by screen should be developed. As long as the flash developer creates the controls/components in an abstract fashion, and the Server-Side developer plays his/her role the end result could be an effective RIA built with less time then we would expect today.

I know speaking from experience, that RIA developer's biggest problem for me, is time. Just not enough time to implement more features that should be in-place.

Error: Branch between 7684 and 41198 around line 0 exceeds 32K span

Error: Branch between 7684 and 41198 around line 0 exceeds 32K span.

Error :

I am using Flex Builder 1.5, today when i compile a mxml file , i received the following error:
[exec] Error: Branch between 7684 and 41198 around line 0 exceeds 32K span.
If possible, please refactor this component.

Solution

This is an error that is produced in Flex 1.5 in order to alert you that
your code needs refactoring in order to decrease the number of visually
rendered mxml tags in a single file. There is more information in the FAQ
here, including how exactly to refactor your code:

http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt


This is an error that is produced in Flex 1.5 in order to alert you that
your code needs refactoring in order to decrease the number of visually
rendered mxml tags in a single file. There is more information in the FAQ
here, including how exactly to refactor your code:

http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt 4

Why cricketer's put cream on their face while match ?

Why cricketer's put cream on their face while match ?

BELIA: TO PREVENT THEMSELVES FROM UV RAYS OF SUN AS THEY R CONSTANTLY
UNDER THE SUN FOR AT LEAST 5-6 HOURS...
SILVERMAN: It's Zinc Oxide, which protects against the sun!
CARLITA: just wanna scare d bowler...matter of factly.. dey dont want
their face to get spoiled
LATESHA: I think the real question should either be:
HORNBERGER: Why is someone watching cricket?
HRUBY: or,
BARTON: Why is someone playing cricket?
BRUNO: to prevent themselves frm sun or to not show their face clearly
to others on their bad days
BASQUEZ: They put on the cream on their faces bcoz the like to prevent
their faces from the UV rays but some cricketers put on the cream for
fashion or showoff
WETZLER: Face has got delecate skin.It tend to get burnt or spoiled
easily when prolong exposed to sun/heat so inorder to avoid these
direct sunrays which spoils the skin they use cream on their face
JOSEPHS: its a sunscreen
PIETSCH: because of allergy
TARIN: To protect from Ultra Violet rays of the sun.
HACKBARTH: Because if they put it on their backs or legs the clothing
would rub it off.
MEURER: to protect his face from sun...........
CERON: they do so in order to prevent their skins from direct
sunlight.Moreover who knows how many different forms of being
fashionable are there??
CHERRY: Andrew Symonds.
BENES: Crickters use cream during match to protect their skins from sun burn.
GEIB: So that they'll not get sun burn.

Did You Know ? horses have 2 lungs like us

VERNETTA: horses have 2 lungs like us
MAGNUSON: They are the same as us - two lungs.
SIN: horses,,,like us have two lungs,,,if they only have one,,,they might not be able to get all the oxygen they need,,,
MANSELL: they have two 'lungs' each side/lung with seperate lobes, the right side having more lobes due to more space in the thoratic cavity.....
VICKNAIR: Horses have two lungs and Colic is not a lung complaint.
DIBELLA: Horse's instestines are long and can become tangled easily.
HAMILTON: The digestive process involves the production of gas through fermentation, and gas can fill loops in the intestine which if then tangled causes a blockage.
EVENS: You are right, unlike humans the horse can?t vomit to rid itself of unsuitable material.
COSENTINO: As a grazing animal a horse is used to a gentle, regular feeding pattern throughout the year, getting fat when suitable pasture is abundant, getting thin when it isn?t.
HAGA: As a quick moving animal with lots of stamina a horse can travel long distances to find the necessary diet variety it needs to thrive - but because we (humans) confine them to one area, then they are unable to travel these distances for different grazing.
KINDRA: More than one lung?
LOWN: This is ridiculous!
PIERCE: Horses have 2 lungs, just like us. When they have Colic it is life threatening because they simply can't throw up, therefore they have no way of getting rid on the poison if it is poison caused.
GATLING: One lung? All mammals have two lungs. The only creatures that dont have two lungs or highly developed second lung are snakes.
MORGAN: two and i thought that iwas dumb please tell me r u a blonde?
ECKENRODE: lol. im just joking dont take it personaly im gust f@#*ing around.lol
KIMBELL: They have 2
UNDERHILL: Horses do have two lungs, they have all the same bones and organs that people do, except no collarbone. (or appendix?)
TULLEY: They can't vomit because the epiglottis won't allow it, so anything bad they ate has to go all the way through and go whatever damage it's going to.
LINGER: They also cannot breathe through the mouth, epiglottis shape again- they can whinny through the mouth but can't really breathe in through the open mouth.
SHAWANNA: Horses can choke, but it's in just the same way as for people. Something too big can get caught in the throat and damage the trachea.