Dock and Finder frozen on MAC with fully updated SnowLeopard
From time to time I encounter some really nasty and irritating problems… most often they are illogical and typically related to conditions over which I have no control…
One such problem occurred to me today after the workshop I had together with Piotr Walczyszyn.
Triggered by something completely unapparent to me and in a way unlike something I had seen before, the Finder App and the entire Dock on my 4 days old MacBook Pro froze… but ONLY when I tried to start the build-in Mail App.
No matter how many KillAll I exposed the poor Dock to in the Terminal and no matter how many Relaunches of the Finder app, just as little did it help… there were no other solution every time I wanted to check email, but to restart… however, this didn’t solve the problem satisfactorily because every time Mail tried to spawn a Window as a response to me trying to Reply or Forward an email… nothing happened !!
After some messing around I found the “com.apple.dock.plist” system file which I tried to remove followed by what I had decided would become the very last KillAll Dock this afternoon.
Immediately following a completed KillAll (and intrinsic Relaunch of the Dock) everything just worked perfectly. I had lost my preferences for the Dock, but since it was a meager 4 days since I had bought the damn thing, not much was lost and all my Dock preferences could be recreated in less than a minute.
My next solution would have been to reinstall / repair the Operating System from System Disk, so naturally I was happy to find this solution which is why I decided to share it…
The file to delete can be found here: “[User]/Library/Preferences/” (where User should be replaced by your User’s ID).
Good luck taming your SnowLeopard !
MATE CacheSetter.. a quick and dirty introduction
One of the newer classes in the MATE Flex Framework yet to be documented is the CacheSetter.
It’s nothing overly fancy, but it does exactly what it promises… it allows you to set the Cache from an ActionTag.
Let’s examine the code below… it’s a standard MATE EventMap with a couple of eventhandlers which offers to exit an AIR application when the User clicks anywhere on it… the applications for such a feature might be quite limited, but that’s what I could think of at 4:40 AM in Bangkok after almost 2 hours of being teleconferencing with the Flex Team sitting in California and it proves the point with the CacheSetter close to a minimal implementation.
NativeSystemEventMap.mxml
<?xml version="1.0" encoding="utf-8"?>
<mate:EventMap xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo"
xmlns:mate="http://mate.asfusion.com/">
<fx:Script>
<![CDATA[
import mx.events.FlexEvent;
import flash.desktop.NativeApplication;
]]>
</fx:Script>
<fx:Declarations>
<mate:EventHandlers type="{ FlexEvent.CREATION_COMPLETE }">
<mate:CacheSetter cacheKey="{ NativeApplication }" instance="{ NativeApplication.nativeApplication }" />
</mate:EventHandlers>
<mate:EventHandlers type="{ MouseEvent.MOUSE_DOWN }">
<mate:MethodInvoker generator="{ NativeApplication }" method="exit" />
</mate:EventHandlers>
</fx:Declarations>
</mate:EventMap>
For the sake of completion, I will also bring the code to the AIR application itself…
<?xml version="1.0" encoding="utf-8"?> <s:WindowedApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" xmlns:client="org.hello.micromanager.timetracker.client.*" xmlns:local="*"> <fx:Declarations> <local:NativeSystemEventMap /> </fx:Declarations> </s:WindowedApplication>
One of the more interesting and intricate details (and eventually why this exercise is interesting), is to see that it uses the Class reference as the cacheKey and that you eventually would be able to use any class or hashable object and chain as the cacheKey. If the cacheKey is NOT set explicitly it will default to use the class type of the Generator attribute, but if you are working with MATE the Cache class is one of the classes it makes the most sense to take an extra look at…
CacheSetter (Source)
http://code.google.com/p/mate-framework/source/browse/trunk/src/com/asfusion/mate/actions/CacheSetter.as
Cache (Source)
http://code.google.com/p/mate-framework/source/browse/trunk/src/com/asfusion/mate/core/Cache.as
Cache (Documentation
http://mate.asfusion.com/api_docs/com/asfusion/mate/core/Cache.html
Invoking the Flex Compiler from Adobe AIR… with Merapi and the Flex Compiler API
As the first step in a larger effort trying to automate my Flex Application development, I have been creating a simple Adobe AIR application that through the AIR bridge from the Merapi Project invoke the Flex compiler.
The implementation is only intended as the first experiment, so currently the use case for the App is a bit farfetched… however, the offspring of this experiment and the potential implications are very strong in terms of workflow optimizations.
Anyways, lets get on with it…
I have to warn you in advance, this is not the simplest possible implementation, but originally it was not my intention to post about it. A better sample would have excluded all the didn’t relate to the central elements which in this case is the Flex Compiler API and getting in touch with it through Merapi. Anyways… after this disclaimer… let’s get on with it…
There are a number of prerequisites in order to get started.
First you need to download and familiarize yourself with the Merapi Project.
Then you need to get the Flex Compiler. The easiest way is to grab it from the Flex SDK which was installed alongside Flex Builder / Flash Builder.
You can find the JAR file in following location:
{Flash Builder Installation Directory}/sdks/{SDK Version}/lib/flex-compiler-oem.jar
On my machine the location looks like this:
Applications/Flash Builder Plugin 4 Beta 1/sdks/4.0.0/lib/flex-compiler-oem.jar
Setting up the appropriate Java project is an exercise I will leave for you to accomplish on your own as out of scope of this post to go through that.
After setting up the project, the first we need to create the Java application which will be running in the background and listening for messages from Adobe AIR.
This application will instantiate the Merapi AIR bridge and through this listen for commands in the form of Compile message types.
It could look something like this…
import java.io.File;
import merapi.Bridge;
import flex2.tools.oem.Application;
public class FxsdkJavAirApplication
{
public static void main(String[] args)
{
Bridge.open();
new CompileHandler();
}
protected static void compile(CompileMessage message)
{
try
{
String inputFile = message.inputFile;
String outputFile = message.outputFile;
Application application = new Application(new File(inputFile));
application.setOutput(new File(outputFile));
application.setProgressMeter(new FxsdkJavAirProgressMeter(message));
long result = application.build(true);
if (result > 0)
{
System.out.println("COMPILE OK");
}
else
{
System.out.println("COMPILE FAILED");
}
}
catch (Exception ex)
{
ex.printStackTrace();
}
}
}
The message which will be using to pass through the bridge is called CompileMessage and inherits from Merapi’s message class and we are using the Application class from the Compiler API to actually do the building of the SWF from the MXML file.
import merapi.messages.Message;
public class CompileMessage extends Message
{
public static final String COMPILE = "compile";
public String inputFile = null;
public String outputFile = null;
public int progress;
public CompileMessage()
{
super();
}
}
Seeing that I copied most of the Java code from the HelloWorld sample of the Merapi project, the calling back to the Adobe AIR application is implemented in the ProgressMeter seeing that this was a very easy and convenient way of getting the callback to function. It should not be regarded as a recommended way of doing it, this is merely an experiment and should not be taken on account for recommended ways of implementing callbacks.
import merapi.messages.IMessage;
import flex2.tools.oem.ProgressMeter;
public class FxsdkJavAirProgressMeter implements ProgressMeter
{
private CompileMessage message;
private long before, after;
FxsdkJavAirProgressMeter(IMessage message)
{
super();
this.message = (CompileMessage)message;
}
public void start()
{
before = System.currentTimeMillis();
System.out.print("begin...");
}
public void end()
{
after = System.currentTimeMillis();
System.out.println("done");
System.out.println("Elapsed Time: " + (after - before) + "ms");
this.message.send();
}
public void percentDone(int n)
{
System.out.print(n + "...");
this.message.progress = n;
this.message.send();
}
}
One of the key elements in the establishing the bridge between Adobe AIR and Java is the message handler invoked by the Java application.
This eventually registers a message type and will assume the role of the observer in the messaging flow.
import merapi.handlers.MessageHandler;
import merapi.messages.IMessage;
public class CompileHandler extends MessageHandler
{
public CompileHandler()
{
super( CompileMessage.COMPILE );
}
public void handleMessage( IMessage message )
{
if( message instanceof CompileMessage )
{
CompileMessage compileMessage = (CompileMessage)message;
FxsdkJavAirApplication.compile(compileMessage);
}
}
}
These 4 classes are all the constitute the Java application based on the existing Flex Compiler API and the classes from the Merapi Project.
Now in the same order, I will go through the Flex part of the application.
First we have the application itself, in this case it is the container of the form and the Mate EventMap and to spice thinks up, a PreferenceMap which wraps the logic relating to managing user preferences.
<?xml version="1.0" encoding="utf-8"?> <s:WindowedApplication xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" xmlns:simplecompile="org.hello.fxsdkjavair.simplecompile.*"> <simplecompile:SimpleCompileForm /> <fx:Declarations> <simplecompile:MainEventMap /> <simplecompile:PreferenceMap /> </fx:Declarations> </s:WindowedApplication>
The message which corresponds to the message in the Java application looks something like this.
package org.hello.fxsdkjavair.simplecompile
{
import merapi.messages.Message;
[Bindable]
[RemoteClass(alias="CompileMessage")]
public class CompileMessage extends Message
{
public static const COMPILE:String = "compile";
public var inputFile:String = null;
public var outputFile:String = null;
public var progress:int;
public function CompileMessage()
{
super( COMPILE );
}
}
}
Then we have the form which contains the code allowing us to manage the inputfile and the outputfile paths.
<?xml version="1.0" encoding="utf-8"?>
<s:Group xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo"
xmlns:merapi="http://merapiproject.net/2009"
xmlns:simplecompile="org.hello.fxsdkjavair.simplecompile.*"
width="100%" height="100%">
<fx:Script>
<![CDATA[
import com.adobe.air.preferences.Preference;
import com.asfusion.mate.core.Cache;
import mx.rpc.events.ResultEvent;
protected function compileHandler_resultHandler(event:ResultEvent):void
{
this.currentState = READY;
}
protected function compileButton_clickHandler(event:MouseEvent):void
{
this.currentState = PROCESS;
this.compileMessage.inputFile = inputFileInput.text;
this.compileMessage.outputFile = outputFileInput.text;
this.compileMessage.send();
this.preference.setValue( "inputFile", inputFileInput.text );
this.preference.setValue( "outputFile", outputFileInput.text );
}
[Bindable]
public var preference:Preference
public static const READY:String = "ready";
public static const PROCESS:String = "process";
]]>
</fx:Script>
<s:layout>
<s:VerticalLayout />
</s:layout>
<fx:Declarations>
<simplecompile:CompileMessage id="compileMessage" />
<merapi:MessageHandler id="compileHandler" type="{ CompileMessage.COMPILE }" result="compileHandler_resultHandler(event)" />
</fx:Declarations>
<s:Group width="100%" height="30">
<s:layout>
<s:HorizontalLayout>
</s:HorizontalLayout>
</s:layout>
<s:TextInput id="inputFileInput" width="100%" text="{ this.preference.getValue('inputFile') }" />
<s:TextInput id="outputFileInput" width="100%" text="{ this.preference.getValue('outputFile') }" />
<s:Button id="compileButton" label="Compile" click="compileButton_clickHandler(event)" enabled.process="false"/>
<mx:Label text="{ this.compileMessage.progress }%" />
</s:Group>
<mx:DataGrid id="resultGrid" width="100%" height="100%" />
<s:states>
<mx:State name="ready" />
<mx:State name="process" />
</s:states>
</s:Group>
For your reference, I will just be adding the EventMap and the PreferenceMap as well…
First we have the EventMap which is a core element of Mate based applications, again… this as well is outside the scope of this post to discuss further.
<?xml version="1.0" encoding="utf-8"?>
<mate:EventMap xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo"
xmlns:mate="http://mate.asfusion.com/">
<fx:Script>
<![CDATA[
import com.adobe.air.preferences.Preference;
import mx.events.FlexEvent;
]]>
</fx:Script>
<fx:Declarations>
<mate:EventHandlers type="{ FlexEvent.INITIALIZE }">
<mate:ObjectBuilder generator="{ Preference }" />
</mate:EventHandlers>
<mate:EventHandlers type="{ FlexEvent.LOADING }">
<mate:MethodInvoker generator="{ Preference }" method="load" />
</mate:EventHandlers>
<mate:EventHandlers type="{ Event.CLOSING }">
<mate:MethodInvoker generator="{ Preference }" method="save" />
</mate:EventHandlers>
</fx:Declarations>
</mate:EventMap>
This is the preferencemap, again it might be total overkill to put in a sample such as this… but seeing that it is a basic part of any application I do these days, I saw no reason to exempt it. Remembering the user’s preferences is paramount when creating user experiences which seeks to satisfy the increasingly high expectations of users today.
<?xml version="1.0" encoding="utf-8"?>
<mate:EventMap xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo"
xmlns:mate="http://mate.asfusion.com/">
<fx:Script>
<![CDATA[
import com.adobe.air.preferences.Preference;
]]>
</fx:Script>
<fx:Declarations>
<mate:Injectors target="{ SimpleCompileForm }">
<mate:PropertyInjector source="{ Preference }" targetKey="preference" />
</mate:Injectors>
</fx:Declarations>
</mate:EventMap>
This is far from a complete or perhaps even suitable sample to illustrate the interoperation with both Merapi and the Flex Compiler API, but I decided to put it out here as part of a collaborative effort of getting my hands dirty with extending Flash Builder and Flash Catalyst.
If you have any questions regarding this sample, please don’t hesitate to contact me or comment on the post.
I will soon make the source code available under the “unsponsored” framework.
Quirk with the Merapi Hello World project…
When running the Merapi project for the first time within Flash Builder, the obvious choice is to look for the Hello World project. However, when you first try to run this project the compiler will complaint with the following error:
Actual Results:
Process terminated without establishing connection to debugger.Command:
“/Applications/Adobe Gumbo MAX Preview/sdks/4.0.0/bin/adl” -runtime “/Applications/Adobe Gumbo MAX Preview/sdks/4.0.0/runtimes/air/mac” “/Users/mac/Documents/Flex Builder 3/myair/bin-debug/myair-app.xml” “/Users/mac/Documents/Flex Builder 3/myair/bin-debug”Output from command:
error while loading initial content
The solution is to update the application configuration file to use the 1.5 namespace instead of the preconfigured one which is set to 1.1.
You can read more about the solution in the Adobe JIRA here: http://bugs.adobe.com/jira/browse/FB-15687
My Microsoft Entourage is suffering from “Database Daemon Fatal Error”…
Now its been two times in three days I have had to run the Database Utility which is shipped and installed together with Microsoft Office for MAC 2008.
Each time I have been forced to do so has been due to a Fatal Error (see screenshot below) in the Microsoft Database Daemon which seems to fail in keeping consistency and integrity in the database underlying Microsoft Entourage.

The solution to solve it is pretty easy… inside the Microsoft Office directory of the local applications folder, you will find a sub-directory entitled “Office” which contains the application called “Microsoft Database Utility”. When executed the application offers you the option of rebuilding the database. Choosing this option will fix the issues while off course creating a backup in case something even more serious should fault during rebuilding. I can’t imagine what use a backup a broken database can have, but I guess its a nice gesture by the utility developers.
Anyways, should you encounter the error below, don’t dispair… make a quick search on your preferred search engine and find this blog-entry, then your problem is likely to be solved in less than half an hour.
Introducing… FlexBox
FlexBox is a directory of Adobe Flex Components…
…some of them are pretty cool and there is sure to be a resource or two for everyone, no matter skill-level…
Check it out…
http://flexbox.mrinalwadhwa.com/
AXIS IP Cameras SWF Streams are not loadable with recent Flash Players
Due to changes in the security settings of the Flash Player Platform its not possible to view SWF streams from AXIS IP cameras with Flash players later than Flash Player 7 effectively preventing anyone from using the build-in SWF streams of the AXIS IP cameras as is.
I therefore uninstalled my Flash Player 9, installed Flash Player 7 and then, voila… no problem loading the SWF’s directly from the cameras
Nevertheless, since the cameras are NOT shipped with a crossdomain file, and therefore does not allow the SWF to be loaded from other domains than the camera itself, there is no other option than to get a crossdomain file into the camera’s webserver’s root.
Unfortunately did a quick examination of AXIS’s Management Software for their cameras not indicate that it would be possible to access the filesystem on the camera. However, after registering that the there was a FTP server on the camera, i quickly connected through FTP and could easily browse, however I could still not write a file – so only read-access.
However, the AXIS Custom Firmware Tool allows for this, but unfortunately “AXIS Custom Firmware Tool is exclusively available for members of the Axis ADP Program”.
(http://www.axis.com/files/tech_notes/development_guidelines_1_00.pdf)
Therefore, I’m gonna do five things now.
1. Examine the Management Tool to see if there is an undocumented way to get access to the filesystem of the Cameras.
2. Examine if there is alternative way to access the filesystem.
3. Apply for membership of the AXIS Application Development Partner (ADP) Program.
4. Ask the vendor providing the cameras here in Denmark to add a crossdomain file to the image.
5. Ask AXIS customer support if they are planning Firmware updates addressing this issue.
Adobe Flex : The Undocumented StaticEventDispatcher
There is an undocumented feature of the Flex Compiler which can come in quite handy.
If you have wanted to listen for changes to static variables, there is an undocumented static variable called “staticEventDispatcher” on classes that have one or more static variables prior to compilation.
The way it works is that as part of compiler pre-processing, the Flex compiler adds a static EventDispatcher object to the class, which eventually can be used to listen for PropertyChangeEvents on the class-reference itself.
If the class does not have a static variable at compiler preprocessing time, the staticEventDispatcher is not added. Despite the i-logic of the fact that a public static property (getter/setter functions) does NOT result in the pre-processor adding the staticEventDispatcher reference it can off course be worked around by adding a variable which references the function in which you have not broken the “contract” of the class, but still have “triggered” the Flex compiler to add your staticEventDispatcher.
The code below is just exploratory-code, and should off course NOT be used anywhere, it just proves the point about the discrepancy about static properties and variables.
public static var getSomethingFunction : Function = something as Function;public static function get something() : String { return "Hello World"; }
This feature of the Flex compiler is very closely related to an undocumented class in the Flex framework, its the StaticPropertyWatcher which extends its more wellknown cousin, the Watcher class in the same mx.binding.* namespace.
Seeing that the StaticPropertyWatcher actually uses the staticEventDispatcher mechanism of the Flex compiler, and seeing that the ordinary Watcher class uses the StaticPropertyWatcher there is no reason not to use this feature.
However, an important point is that in order to ensure forward-compatibility I recommend that you use the staticEventDispatcher in a more type-strict fashion then the StaticPropertyWatcher implementation.
The following excerpt is taken from the StaticPropertyWatcher, and as you can see – they reference it through the class-index and not directly. By doing this you don’t allow the compiler to capture classes attempting to use the static EventDispatcher reference without having a static variable resulting in runtime errors in situations where you don’t check for it’s existance prior to use.
parentObj = Class(parent);
if (parentObj["staticEventDispatcher"] != null) { for (var eventType:String in events) { if (eventType != "__NoChangeEvent__") { var eventDispatcher:IEventDispatcher = parentObj["staticEventDispatcher"];
eventDispatcher.addEventListener(eventType, eventHandler, false, EventPriority.BINDING, true); } } }
In the above case its not possible to do a more type-strict notation seeing that its generic framework code, however in cases where the code is more business-logic-oriented the following notation would make a bit more sense for the compiler
parentObj.staticEventDispatcher.addEventListener( PropertyChangeEvent.PROPERTY_CHANGE, onSomeobjectChange );
This is the preferred way and also a pretty cool way to listen for changes to static variables, despite the fact that its not documented.
Adobe Flex : DataProvider to a Charting Series
I have found that when setting the series for a charting component in Adobe Flex 2.0 it is important to remember that it does not respond correctly to anything except an instance of Array, this means that you can not use any members from the Collection package directly, you can off course still use the ArrayCollection.toArray() when setting the dataProvider property.
However, another spurious thing to consider when working with the dataprovider of a Series item, you can not use the methods of the dataProvider if you want the Chart to respond to the build-in-databinding mechanisms, e.g. even though you know that the dataProvider property points to an Array, you can not use the Array.push() to add a new member of data dataProvider – you are forced to set the entire Series.dataProvider property every time you want to force a build-in-databinding-triggered-update on the Chart component.
These small quirks are not included in the documentation.






2 comments