Demo

Here’s a small demo where you can see the feature at work: Font List Example. The sources shown below are used in this demo.

Implementation

We need a small Flash app and some Javascript. Below is the source code for the Flash app.

Note that you don’t need the Flash authoring app from Adobe in order to compile this; you can simply use the mxmlc compiler in the Flex SDK (which is open source).

Notice how the Flash app calls a Javascript function populateFontList() via the ExternalInterface. Now we just need to implement that function in the page where we embed the Flash object:

Like I’ve mentioned before in this blog, I develop Flex applications using the Flex SDK and jEdit instead of Adobe’s Flex Builder IDE. This setup has worked very well for me but one annoying issue I’ve had to deal with because of this is the slow compilation speed: every time I make a small change into one of my projects and recompile it, the mxmlc compiler (that my build scripts are calling) has to load the JVM into memory and recompile my whole project from scratch, which obviously takes a while. Compiling things in Flex Builder is a lot faster, and the reason for that is the Flex Compiler Shell, which it uses for compilation instead of mxmlc.

The basic idea behind the Flex Compiler Shell is that it would stay in memory between compilations (thus avoiding the cost of loading up the JVM every time you want to compile something) and use a technique called incremental compilation that, as the name suggests, is based on the idea of only compiling the parts of your project that have changed since the last compilation (thus making the process a lot faster). When you run the Flex Compiler Shell executable (called fcsh), you’re thrown into an interactive shell where you can run commands in order to compile your projects and control the operation of fcsh itself.

The Problem

When I found out about fcsh, tried it out and saw how much faster it was than mxmlc, of course I wanted to immediately start using it instead in my build scripts. The biggest problem with doing this, though, is the fact that the basic operation of these two programs is fundamentally different: when you run mxmlc, it compiles the project, prints some messages to standard output and then exits (with the exit status 0 if the compilation was successful or 1 if it wasn’t), which is perfect for integrating it into build scripts. Fcsh, on the other hand, throws you into a shell of its own and expects you to essentially operate it from within itself (instead of simply calling it with some arguments and then having it return with some standard output and an exit status like mxmlc).

The other issue that makes fcsh more difficult to use in general is that in order to use the incremental compilation feature, you have to first compile your project like you normally would (using the “mxmlc” command), then make note of the “compile target id” number that fcsh then assigns to this project and specifies in its output, and for future compilations use the “compile N” (where N is the compile target id) command.

The Solution

I tried to search for a solution to this problem that somebody else might have come up with but didn’t find an adequate one (a list of the ones that I could find is further down), so I decided to give it a shot myself. My approach, called fcshctl (short for “fcsh controller”), is basically a simple bash script that:

1. starts the fcsh process if it isn’t already running
2. forwards its arguments to fcsh as commands
3. reads the output of that command from the fcsh interactive shell and prints it to the standard output
4. exits with status 0 (success) or >0 (failure)

In addition to this, I also made the script automatically and transparently invoke the incremental compilation feature whenever applicable so that I wouldn’t have to worry about keeping track of the compile target ids and using a different command for the compilation whenever one had already been assigned.

Below is a summarization of the pros and cons of this solution:

Pros:

• It’s quite simple — just one shell script (a few others are included in the .zip that are only for convenience and not required)
• It runs the fcsh instance in a GNU screen session, which means that:
• The running fcsh instance is accessible to all user processes (i.e. not just within a single shell session, for example)
• It is possible for the user to enter the running fcsh interactive shell at any time (by attaching to the screen session via the command screen -r -S fcsh) and manually interact with it
• It automatically checks whether you’ve compiled a specific file before and keeps track of the compile target ids that fcsh assigns so that it can automatically and transparently invoke the incremental compilation feature and let you access the speed gains that are fcsh’s main offering without any additional work. This feature can also be turned off by setting an environment variable.
• A proxy script (called fcshctl-mxmlc) that can be used in place of mxmlc is provided. It simply calls fcshctl with “mxmlc” as the first argument, followed by all the other arguments you specify, so that you can simply use this script as a stand-in for mxmlc in any build scripts that you may be using without having to modify them any further.

Cons:

• It uses the GNU screen logging mechanism and polling for changes in the log file in order to catch the output of commands sent to fcsh, which is not very elegant and causes a slowdown of maybe about a couple hundred milliseconds before the output is printed to stdout.
• The output of the executed fcsh command is not printed to the standard output as it comes, but instead all at once when the command finishes (this is not a problem for me personally, but others might want to fix this).
• It’s implemented as a bash script, which means that it’s not the fastest monster out there (we’re talking about milliseconds here, though, so it doesn’t bother me at all).

Download

You can download fcshctl here:

• fcshctl-v0.5.1.zip (latest)
• fcshctl-v0.5.zip
• fcshctl-v0.4.zip
• fcshctl-v0.3.zip

fcshctl has been tested with fcsh versions 3.0.0 build 477 and 3.1.0 build 2710 on Mac OS 10.5.5. It is licensed under the MIT License.

The script requires the following to be in your $PATH: rm, mv, cat, ps, sleep, tail, head, grep, awk, screen, xargs and basename. You also need to have the FLEX_HOME environment variable set to point to the Flex SDK root path.

Example of use

fcshctl $ export FLEX_HOME=/Users/username/code/SDKs/flex_sdk_3.1
fcshctl $
fcshctl $ ./fcshctl

Usage: fcshctl <commands>

  Substitute <commands> with any commands you
  would like to send fcsh, just like you would
  enter them in the interactive fcsh shell
  session.

  To get a list of the available commands, run:

    fcshctl help

fcshctl $
fcshctl $ ./fcshctl help
List of fcsh commands:
mxmlc arg1 arg2 ...      full compilation and optimization; return a target id
compc arg1 arg2 ...      full SWC compilation
compile id               incremental compilation
clear [id]               clear target(s)
info [id]                display compile target info
quit                     quit
fcshctl $
fcshctl $ ./fcshctl mxmlc ~/code/Flex/projects/testbed/testbed.mxml
Loading configuration file /Users/username/code/SDKs/flex_sdk_3.1/frameworks/flex-config.xml
Recompile: /Users/username/code/Flex/projects/testbed/testbed.mxml
Reason: The source file wasn't fully compiled.
Files changed: 0 Files affected: 1
/Users/username/code/Flex/projects/testbed/testbed.mxml(28):  Error: Incorrect number of arguments.  Expected 2.

    func1("toka");

fcshctl $ echo $?
1
fcshctl $
fcshctl $

Other similar solutions

Below is a list of other approaches to the problem of integrating fcsh to non-standard (i.e. non-Flex Builder) workflows (roughly in order from most promising to least promising), and short lists of reasons why I personally didn’t want to use them. If my solution doesn’t seem good to you, you should maybe check some of these out.

fcsh tools by Mike Rowe

• Runs fcsh in a daemonized process, which means you won’t be able to enter the interactive shell of a running fcsh process and manually interact with it
• You can only specify the filename to compile; has no support for additional mxmlc arguments
• For GNU/Linux (but seems to work just fine on OS X as well)

flex-compiler-shell-daemon by Leonardo Soto Muños (also see his blog post about it)

• I couldn’t get it to work out of the box on OS X
• Runs fcsh in a daemonized process, which means you won’t be able to enter the interactive shell of a running fcsh process and manually interact with it

FCSH Wrapper by Mihai Vasilache

• For Windows
• Designed to be used with Ant
• A bit complicated

http://code.google.com/p/fsch/ by nimrod97

• For Windows

BigSource Zarkov by BigSource GbR

• For Eclipse & Ant

1. I notice a bug in an application that only occurs when running it on the server
2. I debug the application, find the bug and issue a fix
3. I deploy the new version that contains the fix onto the server
4. I empty the browser cache and run the app on the server again, noticing that the bug seems to persist
5. I wonder if the version I’m seeing is indeed the version that has the fix, or an older build served to me by some cache server between my workstation and the server
6. I have to resort to stupid trickery (comparing md5 hashes of .swfs or something) in order to find out

The obvious solution to this problem is to make some sort of version information (that changes on each build) accessible to the application itself so that it can print it into the log or display it in the UI. As of Flex 3, this is quite easy to do with the conditional compilation feature in the mxmlc compiler.

Due to the kinds of problems I’ve described above, I’ve taken up the practice of injecting a specific kind of string into my Flex apps at compilation time, containing the date and time of when it was compiled, as well as the hostname of the computer where it was compiled (and even though I only started this practice due to this specific problem that I was trying to solve, I believe saving version information into the build product should be standard practice for all kinds of software). An example of how I do this follows:

1. Compile the binary with the conditional compilation parameter:

/path/to/mxmlc -define+=DEBUG::compiled,"Fri_Sep_12_17:26:13_on_Alis-MacBook.local" -strict=true /path/to/myApp.mxml

2. Print out the “compiled” value in the application code:

var DEBUG:Namespace = new Namespace("DEBUG");
var compiledStr:String = DEBUG::compiled;
trace("SWF was compiled: "+compiledStr);

Of course, for this to actually be useful, you somehow need to be able to automate the creation of this “compiled” string value. Here are some example scripts that show how to go about doing this:

• Bourne shell script:

#!/bin/sh
#
# Compiles myApp
# 

if [ -n "${1}" ] && [ -e "${1}" ];then

	DEBUGARG=""
	if [ -n "${2}" ] && [ "${2}" == "debug" ];then
		DEBUGARG=" -compiler.debug"
	fi

	DN=`dirname ${1}`
	BN=`basename ${1}`
	MXMLC="`cd ${DN}; pwd`/${BN}"

	DN=`dirname ${0}`
	THISDIR="`cd ${DN}; pwd`"

	HOSTNAME="unknown"
	HOSTNAME="`hostname`"
	HOSTNAME=${HOSTNAME// /_}
	HOSTNAME=${HOSTNAME//\"/}
	HOSTNAME=${HOSTNAME//\'/}

	CURRDATESTR="`date`"
	CURRDATESTR=${CURRDATESTR// /_}
	MXMLC_WITH_ARGS="${MXMLC}${DEBUGARG} -define+=DEBUG::compiled,\"${CURRDATESTR}_on_${HOSTNAME}\" -strict=true"
	${MXMLC_WITH_ARGS} "${THISDIR}/myApp.mxml"

else

	echo "Usage: `basename \"${0}\"`
 [debug]"
	echo ""
	echo " The debug argument is optional. It specifies whether or not"
	echo " to compile a debug binary."
	echo ""
	exit 10

fi

• Windows batch file:

@ECHO OFF

REM check arguments -----------------
REM ---------------------------------
IF "%1"=="" GOTO ShowUsage
IF NOT EXIST %1 GOTO ShowMxmlcDoesntExistError

REM get datetime & hostname -----------------
REM ---------------------------------
For /F "Tokens=2" %%I in ('Date /T') Do Set StrDate=%%I
For /F "Tokens=*" %%I in ('Time /T') Do Set StrTime=%%I
For /F "Tokens=*" %%I in ('hostname') Do Set StrHostname=%%I

Set StrCompiled=%StrDate%_%StrTime%_on_%StrHostname%

REM compile app -----------------
REM ---------------------------------
IF "%2"=="debug" (
	@ECHO ON
	%1 -compiler.debug -define+="DEBUG::compiled,\"%StrCompiled%\"" -strict=true myApp.mxml
	@ECHO OFF
) ELSE (
	@ECHO ON
	%1 -define+="DEBUG::compiled,\"%StrCompiled%\"" -strict=true myApp.mxml
	@ECHO OFF
)

GOTO EOF

:ShowUsage
echo Usage: %0 [path-to-mxmlc] [debug]
echo.
echo  The debug argument is optional. It specifies whether
echo  or not to compile a debug binary.
echo.
GOTO EOF

:ShowMxmlcDoesntExistError
echo Error: Specified path does not exist:
echo %1
GOTO EOF

:EOF

Changelog

First, here is an itemized list of what has changed:

• Flex dependencies have been removed, which makes it possible to use this in pure AS3 projects as well

This changes the way the support is initialized in AS3, but more about that a bit later. Courtesy of Pavel Fljot.

• States of modifier keys (i.e. ctrl (or command in OS X,) alt, shift) are supported

These can be accessed via the ctrlKey, altKey and shiftKey properties in the MouseEvent object, as usual.

• The initialization of the code on the JavaScript end requires much less effort

You basically just have to include the one JavaScript file on the page and that’s it.

• An another method of determining which object on the Stage should dispatch the mouse wheel event has been added

Read more about this below. Courtesy of a similar solution from Gabriel Bucknall.

• Is enabled for Safari for Windows

For some mysterious reason the mouse wheel won’t work in Flash when accessed with the Windows version of Safari, so this solution will now enable itself for that browser. Courtesy of Pavel Fljot.

• Can be enabled for any number of different Flash objects on the same page

As long as the JavaScript file is linked on the page and the Flash apps have initialized the AS3 end of the code, they should be supported.

• The JavaScript code is encapsulated inside one top-level function

This is a much more elegant solution on the JavaScript end. Courtesy of a similar solution from Gabriel Bucknall.

• The initialization state of the mouse wheel support is exposed

You can read the value of the “initialized” property (or bind to it) to see if the mouse wheel support has been initialized.

• The concept of “registering and unregistering objects” for mouse wheel support within AS3 code has been removed

This concept is no longer useful, given the new implementation.

Determining the InteractiveObject to dispatch the mouse wheel event

Like mentioned in the changelog above, I’ve added an another method for finding the InteractiveObject on stage and under the mouse cursor that should dispatch the mouse wheel event when one is sent from the JavaScript end. This is based on the solution to this same issue Gabriel Bucknall has come up with at pixelbreaker.com. My solution basically went through the whole display list hierarcy every time a mouse wheel event had to be dispatched, trying to find mouse-enabled InteractiveObjects that were under the mouse cursor, and then asked the topmost of these to dispatch the MouseEvent. Gabriel’s solution was to attach a MouseEvent.MOUSE_MOVE event listener to the Stage and keep a reference to the object that was the target for the last such event, and then use that reference to ask this object to dispatch the mouse wheel event whenever required.

Now, the main difference between these two solutions, I’ve found, is that Gabriel’s is faster but inaccurate in some border cases, while mine is slower but more accurate. The slowness of my solution is very clear if you understand the amount of processing that goes on whenever the user starts rolling the wheel: for each event, the application needs to go through the whole hierarchy of objects on the Stage, find InteractiveObjects that are under the mouse cursor, mouse-enabled and visible, and then find the one of those that is deepest in the display list. Gabriel’s solution doesn’t need to do any of this: it already has the InteractiveObject reference it wants to use at this point. The inaccuracy, on the other hand, stems from the fact that if the user doesn’t move their mouse, the reference won’t get updated. What this means is that if the InteractiveObjects on Stage have moved (in relation to the mouse cursor,) or been added to or removed from the display list while the cursor has stayed put, the reference will not be up to date, and probably incorrect.

As you’ve probably deduced from the last paragraph, there are upsides and downsides to both of these approaches, and I at least would like to be able to choose which one to use, based on the context of what I happen to be doing at the moment. This is why I’ve added this exact feature into the code in the form of a property the value of which you can set at will:

private var _mwSupport:ExternalMouseWheelSupport = ExternalMouseWheelSupport.getInstance(stage);

_mwSupport.dispatchingObjectDeterminationMethod = ExternalMouseWheelSupport.COPY_MOUSEMOVE_EVENTS;
// or
_mwSupport.dispatchingObjectDeterminationMethod = ExternalMouseWheelSupport.TRAVERSE_DISPLAY_LIST;

You can test the differences between these two options with the demo.

Deployment and use

So like I wrote before, the process of deploying and initializing this solution has changed a bit from the last version. This is how you do it now.

1. Include the JavaScript file onto the page that embeds the Flash object(s)
<script type="text/javascript" src="./extMouseWheel.js"></script>
2. Make sure your embedded Flash objects have a parent div element
<div style="width:600px;height:600px;" id="flashContainerDiv">
  <!-- add Flash object's <object> and <embed> tags here -->
</div>
3. In your AS3 code, get a reference to the singleton instance of ExternalMouseWheelSupport in at least one place

As you can see, the singleton instance accessor is not a property anymore, but a method, so that you can pass a reference to the Stage to it. This change is because of the removal of dependencies to Flex libraries, which could be used to access the Stage instance in the previous version.

import org.hasseg.externalMouseWheel.ExternalMouseWheelSupport;
private var _mwSupport:ExternalMouseWheelSupport = ExternalMouseWheelSupport.getInstance(stage);

I generally do this in the applicationComplete event handler, but you can of course call it wherever you want, as long as you make sure the Stage reference you’re using is not null (an Error will be thrown if it is.)

…and that’s it. :)

Downloads and demo

• A Working example
• The sources (ZIP archive)
• AsDoc-generated API documentation

This code is licensed under the MIT License.

Other info

I’ve tested this solution with the following browsers (sadly, Opera on the Mac isn’t supported since ExternalInterface doesn’t seem to work in the latest version:)

• On OS X 10.5.2:
• Safari 3.1.1
• Firefox 3 beta 5
• Camino 1.6
• OmniWeb 5.7
• On Windows XP SP2:
• Internet Explorer 7.0
• Firefox 2.0
• Safari 3.1.1
• Opera 9.27

If someone could please test this on the Mac OS version of Firefox 2 and the Windows versions of Firefox 3 beta and IE 6, I’d very much appreciate it.

I Tried to implement the component so that it’ll be easy to use in both MXML and ActionScript. In the demo app there is also an example on styling the CollapsiblePanel.

• Demo: CollapsiblePanelDemo.swf
• Sources: CollapsiblePanelSources.zip

CollapsiblePanelDemo.mxml:

CollapsiblePanel.as:

Update (same day as orig. post): Added simple demo and example code on how to use the component. Added comment about using embedded fonts.

The way this works is basically by taking the TabBar component (a child of the whole TabNavigator component,) rotating it to make it vertical, positioning it to either side of the ViewStack, and making several adjustments to the component’s size to accommodate the new location of the TabBar. One thing to remember when using this is that you need to embed the font you want to use for the TabBar labels with your app, since rotated text doesn’t work in Flash player with system fonts. Also make sure that you’re embedding a bold version of the font, since text in the TabBar buttons is bold by default.

I Used Flex 2.0.1 to do this. Below you can look at the demo and see how it looks, download the zipped source, or just look at the code:

• Demo: VerticalTabNavigatorDemo.swf
• Sources: VerticalTabNavigator.zip

VerticalTabNavigatorDemo.mxml:

VerticalTabNavigator.as:

However, after starting to use the SideKick plugin with the modified, AS3-supported version of Ctags while doing my work, I found a few small rough edges in the ActionScript support he had made:

• Package names were not properly catched – only the first level was shown (e.g. “org” instead of “org.hasseg.thingamabob“)
• Todo and note names were not properly catched – it just showed “todo” or “note” instead of what comes after
• My “todo:” notes were not catched – it only supported uppercase (i.e. “TODO:“)
• Some attribute keywords (override, final, internal etc…) were not allowed on classes, functions/methods and properties, so I was missing some of these in my SideKick listings

Not big problems by any means, but for me these meant that SideKick wouldn’t display some of the stuff in my code, and if it did, not properly, so I fixed them.

Get my modified version of the AS3-supported Ctags here:

The ctags binary (zipped) (note: compiled on a rev.B MacBook (Core 2 Duo processor) with Mac OS 10.4.10)

The source code (actionscript.c)

You should refer to VeryVito’s post for more info this issue.

Update (same day as original post): Improved this a bit. Find below a complete list of changes I’ve made (taken from the source code):

Update (Oct 5, 07): Now it can search from any number of AsDoc sources
Update (Oct 8, 07): Also finds documentation for methods, changing the command for opening a file in a web browser is easier
Update (Oct 10, 07): now the script searches through files, not buffers, so you needn’t have all of your project’s files open for it to be able to search through them

The way my version works is that it gets the selection from the current buffer (or if there’s no selection made, it selects the word that the caret is on top of) and searches the Flex SDK language reference for it. The files it goes through and the regular expressions + other logic that is used to do the pattern matching are designed so that it would work for class, package and method names.

Here’s the macro code (with some unnecessary whitespace removed):

As you can see from the settings, the macro can be set to open the documentation html page in either the InfoViewer plugin in jEdit or an external web browser. I prefer to have it open up in the browser, since the formatting and styling of the Flex language reference contribute to the fact that the pages don’t really work very well in the InfoViewer plugin. The OS X open command is used to make the external browser open up the documentation, which means that if someone would want to use this in Windows or Linux, that part would have to be re-implemented. Update: Now you can simply edit the openCommand variable in the “settings” area to change the command that is run in the system shell to open up docs in the browser.

Get the script here:

Display_Flex_documentation.bsh

Update (October 5, 07): Modified the script so that it can search from any number of different AsDoc sources (which the official Flex language reference is one of)

Update (October 8, 07): Modified the script to also find documentation for methods. Made it easier to modify the command that is run in the system shell to open up documentation .html pages in an external browser.

Update (October 10, 07): Modified the script to operate on files instead of buffers so that it can also search files that are not currently open.

For a while, I had the compiler command and the parameters (i.e. the file to compile) hardcoded in my macro, but recently I changed this to a more reusable solution where you have one macro for selecting the file (“buffer” in jEdit lingo) to be compiled and another for actually running the compiler on that file. Then I simply bind keystrokes for both of them. This enables me to easily and quickly run the compiler whenever I want to, and also change the file to be compiled (and, of course, also the compiler used – automatically based on the file extension) if I switch projects.

Select_file_to_compile.bsh

First, let’s take a look at Select_file_to_compile.bsh, which is used to select the file (as you can see, it saves the file path into a jEdit property which the other script will later read):

Compile_previously_selected_file.bsh

Then there’s Compile_previously_selected_file.bsh which invokes the compiling process. Notice the displayDockedConsole parameter in the settings – a false value will make sure that the Console plugin will not open up whenever the compiling starts. I Want to keep it closed because I don’t make this macro call the mxml compiler directly, but instead through a bash shell script (compileMxml.bash – link below) that displays a Growl notification whenever the compiling finishes, telling me whether or not the application was compiled successfully. In case of errors, the notification will be sticky, so that if I leave my computer to compile and then come back later, I’ll still be able to see it.

Download scripts

• Get the jEdit macros here: jEditCompileMacros.zip

Install them by saving them to jEdit’s macros directory. Then you can go to “utilities” -> “global options” -> “shortcuts” -> “macros” to set the keyboard shortcuts. In Mac OS X, the jEdit macros folder can be found here:

~/.jEdit/macros/

Please also note that you need the Console plugin for jEdit for this to work. Go to “plugins” -> “plugin manager” -> “install” to get it.

• Get the mxml compiler shell script (+ the icon images used in the Growl notifications it displays) here: compileMxml.zip

In my current job I have been programming user interfaces for applications that display networks of data (as in nodes, links etc.) with the Adobe Flex framework, and the UI paradigm I have been utilizing is a kind of a Zoomable User Interface (ZUI). The idea there is to enable the user to view and manipulate objects on a two-dimensional plane, and navigate around that plane by zooming and panning.

Now, the easiest way (at least for me) to control the zooming is to use the mouse wheel. Mouse wheel support for Flex is implemented by registering an event listener of type MouseEvent.MOUSE_WHEEL with the DisplayObject that would dispatch the event. Sadly, mouse wheel support is not available in the Mac OS X version of Flash Player. This prompted me to create a custom solution, as my main computer is a MacBook and I would like to be able to test the mouse wheel navigation with my development machine.

Update: The javascript now works with more browsers than just Firefox 2 and Safari 2. I Tested it, in addition to those two, with Opera 9, Camino 1.5 and Omniweb 5.5, and it seems to work in all of them now.

Update #2: Changed the javascript code to also work with Safari 3 beta. When using it, small movements with the wheel do not invoke any action, so you’ll have to roll it a bit further to make the app respond.

Update #3: Added statement about licensing the code under the MIT License as per request of Philip Flip Kromer

Update #4 (feb 8, 08): If you’re looking for AS3 (not Flex) OS X mouse wheel support, check out PixelBreaker.com.

Update #5 (feb 12, 08): Fljot sent me a version of this that works also in non-Flex AS3 projects. He also fixed some issues in the code related to the automatic registration of listening objects. You can find him here.

The solution has been tested with Firefox 2 and Safari 2 Firefox 2, Safari 2, Opera 9, Camino 1.5 and Omniweb 5.5, and it is based on two main elements:

• JavaScript code that catches mouse events and sends their details through a function call to the Flash app using the ExternalInterface
• An ActionScript 3 singleton class ExternalMouseWheelSupport that registers an ExternalInterface callback for the function call and makes objects that are under the mouse cursor dispatch MouseEvents of type MouseEvent.MOUSE_WHEEL

JavaScript:

Just include the osxmousewheel.js file in your HTML and specify the ids/names of your flash object element and the div element that contains the flash object:

ActionScript:

The singleton has to be created first, and that can be done by getting a reference to the instance property in at least one place:

Then, all objects that you want to have the OS X mouse wheel support enabled for have to be registered with the ExternalMouseWheelSupport class. This can be done in two ways:

1. Manually:

This is the more foolproof way. First make sure that the registerAutomatically property is set to false (it is true by default):

ExternalMouseWheelSupport.registerAutomatically = false;

Then just register the objects one by one:

_mwSupport.registerObject(myBox);

or several at a time:

_mwSupport.registerObjects([myBox, myButton, mySlider]);
2. Automatically:

This is the easier, but more bug-prone way. Simply make sure that the registerAutomatically property is set to true (it is true by default, so you actually don’t even need to do this):

ExternalMouseWheelSupport.registerAutomatically = true;

After that, all InteractiveObjects on the stage should dispatch mouse events, so you can normally attach event listeners to them and do whatever you want in them:

myBox.addEventListener(MouseEvent.MOUSE_WHEEL, function(event:MouseEvent):void {
    t.text = ("Mouse wheel delta: "+event.delta);
});

The code could probably use some debugging and optimization, but it seems to work well if you’re not doing anything too fancy. If you take it and make any fixes, please let me know! ;)

A working example.

The source code for the example.

The AsDoc-generated API Documentation for the support library

This code is distributed under the MIT License.