While working on one of our projects I have noticed this error, which apparently comes from inside the Flex Tree class:

This error could happen when calling exapndItem() method immediately after setting the Tree’s dataProvider property. This is because the Tree does not manage to update itself between the calls.

This issue has been addressed in the following post, but from a quick look I have only spotted a sort of a hack.

Here is a more elegant solution to the expanItem() problem. This was inspired from the following Adobe link. One could extend the Tree component and implement a refresh() method like the one described below:

Then just make sure to call a refresh() before a call to expandItem(). In this case the expanItem() call will be safe.

The critical section of my schema – where I specified the restrictions – was:

The error message I got from the validator wasn’t very informative, so it took some time until I localized the problem. The error appeared due to the fact that the attribute “dataType” already had a “type” defined at the top level, which resulted in conflicting behavior with the “base” attribute of the restriction defined afterwards. Though this was not explicitly stated in the documentation I was able to find on-line, it seems that these two attributes exclude each other, since they basically specify the same thing.

Deleting the “type” attribute finally solved my problem:

After converting the .rpm package to .deb using Alien, and installing the AHFormatter V4.3 or V5.1 (by default in /usr), some errors might occure at run time:

What you have to do is to edit the “run.sh” from the installation folder of AHFormatter (let’s say /usr/AHFormatterV51/run.sh) and replace the line:

with the folder where you installed the Formatter. Let’s say:

The second replacement is in the “font-config.xml” file from the “etc” folder of AHFormatter (let’s say /usr/AHFormatterV51/etc/font-config.xml) at line:

with the folder where you installed the Formatter:

Now you can enjoy the AHFormatter!:)

The installation directory can be provided with the –prefix “installation location” parameters, otherwise it will be installed to the /usr/ServerBasedConvertor location.

To make a a sample conversion the run.sh script must be executed, a frequent error that could appear is:

This means that the converter wants to use the shared objects that came with the installation (in the ~/ServerBasedConvertor/lib directory). As these objects were probably compiled on a different system, the ones that cause the problem must be deleted from the installation directory and the native libraries of the system should be installed.

In our example the ~/ServerBsedConvertor/lib/libOsMesa.so and ~/ServerBsedConvertor/lib/libOsMesa.so.6 files are going to be deleted and the libosMesa6 library will be installed with the following command:

After these errors disappear the shell script should run properly.

If trying to compile and run the sample Java code the publishers provided, the following things must be done:

Some environment variables must be set. These can be found on the publishers site at the following address:

http://rainbowpdf.com/serverdoc/xfo-env.html

After setting the necessary variables a possible error that might appear is:

The cause of this error is that a shared object file does not have the name what the program is searching for. It seems that in the 3.0 package for 64 bit Linux (maybe in other packages as well) a shared object file has not been renamed from the last version.

A quick solution would be to rename one of the symbolic links (rename libDfvJavaCtl.so to libDfvJavaCtl21.so) which point to a library file with the following command:

Now everything should work.

So, I had a java program that needed to run several instances of the same AIR application. By default, calling the following line more than once while the initial application is active:

…, will result in all calls being forwarded to the first instance (message: “invocation forwarded to primary instance”). Since the whole idea of running several apps in the same time is for each to do something specific, this is kind of a blocker.

Good thing that AIR uses only the application id (found under <id> tag in the descriptor) to identify between applications launches. Therefor the solution was pretty straight-forward:

1. replicate the original application descriptor and give it a standardized unique name
2. update the ids for each descriptor and make sure they are unique
3. do a programmatic search in the folder for application descriptors matching the standard name and create a thread pool with launchers for them (this was on java side)

You might find this useful (ant code for replicating descriptors/renaming ids):

…, where application_id is the ID of the application (usually set to project name) and APP_COUNT is a property setting the number of apps to be deployed.

Playing OGG sounds in Flash has been possible for a couple of months now, with the new FP10 Sound API and AS3 OGG Vorbis library built using Adobe Alchemy and available on Adobe Labs: http://labs.adobe.com/wiki/index.php/Alchemy:Libraries.

The strategy is to:

1. load the sound with URLLoader as bytes (it can also be embeded, but it wouldn’t make much sense);
2. use AS3 OGG Vorbis library to parse the data and create the OGGSound (a class created specifically for this demo that wraps an OGG sound byte array); the decoder is OGGDecoder;
3. simulate the sound api by extending Sound class and make use of the new SampleDataEvent.SAMPLE_DATA to read from the samples and output to the audio card.

I’m removing the last 2 samples in order for the sound to loop smoothly.

Give a test to the small demo project below and take a look at the code here.

The fact that you need to do:

…, in order for this to work seems a bit hacky, since in fact you’re creating a dummy empty sound that you lively populate. Maybe there could be something more intuitive…