capital H coder

I recently got down to the “Support Foreign Characters” item in my Knowtes To-Do list, and figured it would be fairly easy to find an example component out there that provided an easy way for users to enter special characters into Flex text controls (TextInput, TextArea, and RichTextEditor).

Unfortunately, both my posts to FlexCoders and my lengthy Google search turned up empty.

So on the off chance that I’m not actually the only person in the world with a need for this type of feature, here is what I came up with (a very simple version of it anyway):

And HERE IS THE SOURCE

Two points worth mentioning:

• The key for getting the unicode characters into the text controls was to use the String.fromCharCode() function.
• To enhance usability, the cursor is placed at the end of the text in the associated control when the character dropdown is closed. The selectionBeginIndex and selectionEndIndex are used for setting the caret position. For the RichTextEditor this property changes to selection.beginIndex and selection.endIndex.

It definitely needs some polishing, but hopefully it will give someone a jump start on providing a simple method of allowing users to easily enter unicode/foreign/special characters in Flex apps.

~Shaun

So we have the ability in Flex to select an image as the background of a container. However, the only control we get over this image is the ability to specify its size. From my background in .NET, I am accustomed to being able to specify the layout of a background image as one of four options:

• Centered: shows up as its default size, centered in the container
• Stretched: made to fill all area of the background (causing distortion if necessary)
• Tiled: repeats itself to fill entire background area
• Zoomed: image stretched as large as possible while maintaining aspect ratio & centered

So what I’m providing here (right-click for code) is my method of providing this functionality as a skin in Flex.



I call it the CuSTomiZableImageSkin (for Center, Stretch, Tile, and Zoom), but you can call it whatever you want (feel free to use and modify it to your heart’s content).

This should work for any containers in your app, and all you have to do to use it is specify the class as your borderSkin, provide a backgroundImage, and set the backgroundSize style to center, stretch, tile, or zoom.

HERE IS THE SOURCE

Possible improvements: allowing a border as well as the image. I haven’t needed a border as well as the image yet, so I haven’t done this.

~Shaun

So I really like the idea of runtime styles in Flex. Enough that I went through the process of moving my styles out of my app and into an external swf even though it wasn’t absolutely necessary. My thought was that this would gain me some flexibility in the future, and I could then share the style swf between apps if I ever needed to.

Then, in the process of optimization, I noticed that my Style SWF file was 127k in size. Ouch. Using an RSL got that down to about 50k. Better… but not good. So I decided to put the styles back into my app to see what the difference would be, if any. It turns out that adding it back only added 24k to main app!

Not only this, but initialization time was cut by 1/4th. On top of this, any dynamic updates I made to styles while running were noticably faster as well.

It was probably my imagination, but it seemed as though everything was faster, even just switching app locations, creating components, etc.

This was all done with Flex 2.0.1, and I am hoping that I do not experience the same symptoms when I move to Flex 3. For now, I am staying away from runtime styles unless they are absolutely required. I recommend you do the same if you don’t have an explicit need for them.

~Shaun

So I decided to do a little experiment. I wanted to create an embeddable player for Knowtes that users could post on their own pages. I could have just used the one I have on the Knowtes site, but it weighs in at a hefty 277k due to its use of the Flex Framework. This is obviously not acceptable if I’m going to have a lot of users embedding this new player on their pages.

So, I set out to create an actionscript only project that would provide all the features of my current framework based player. Here is the result:

I ended up adding more features than the original version (most notably, the theme changes to match the library theme of the user who embeds it), but it still only weighs in at 17k! I think I’ll have to can the original

In creating this I had to convert a few of my personalization classes to work without the framework. So if anyone would like to see how I did one of the following, just post a comment and let me know:

• Bitmap Fade: makes a bitmap copy of a given DisplayObject, replaces the target with the bitmap in the display list and then fades the bitmap, switching it back when it is done. This let me avoid embedding fonts
• Full Gradient Background: allows radial or linear gradients, any number of colors/ratios/alphas, and changeable angle and focalpointratio (pretty much any common gradient option).
• Strech/Zoom/Center/Tile -able Background Image: An actionscript only component that fills up its display area with an image using any of these methods.

Whew!

So my real job turned out to be a lot less work than programming on Knowtes for the Derby. I need to work on my self-motivation (less would be better I think).

In any case, the bug-ridden AIR version of Knowtes is off, and I can only hope that there are too many features in there for the judges to get too in-depth and find all of the errors

I waited pretty much until the last second to submit it, just in case Adobe had some automated process to download your AIR file as soon as you sent in your submission, though it appears they did not. Now it’s time to sit around and wait for the judges to start doing their thing.

Well, not exactly just sit around. I’ve got plenty of projects to be working on and I’d like to start blogging about different parts of the AIR development experience as well as code I used. So to that end, here’s a list of things I might blog about:

• The Knowtes GradientSelector control
• The BitmapFade effect (gets around non-embedded font issues and is faster than typical fade)
• Secure login via HTML
• Kuler integration
• Tile-able, center-able, stretch-able, zoom-able background image

Just post a comment and let me know what you’d like to hear about and I’ll make a blog post about it.

Till then,
~Shaun (more…)

One of my least favorite things about web development is the need to upload images before being allowed access to them on the client side.  In the era of Rich Internet Applications, where client-side file manipulation is becoming more commonplace, the step of transferring an image to the server just to immediately bring it back to the client seems like a waste of time, bandwidth, and server resources, not to mention being horrible for the user experience.

Of course, it is also necessary unless you want to use a java applet (and who does?).  Or is it?  Apparently Microsoft has decided that this is one security vulnerability that they can deal with and have announced client side access to files.  That’s right, with Silverlight you can now access files before uploading them to the server!  Read about it on Scott Guthrie’s blog (check out the slides) and here.

The only limitations are that you must allow the user to browse to the file with a browse file dialog (as they do now), and you get access only to that file.  Pretty simple.

Of course, I don’t want to use Silverlight.  I want the features and reach of Flash.  So until Adobe decides it is worth it to provide this feature (I’m hoping to hear word on this from an Adobe blog by Lucas Adamski), I’ll just add one to the “Silverlight is the best” column (it’s still rather lopsided in favor of Adobe) and put up with a poor experience in the file upload department.

~Shaun