Project Page for ImageCFC:  http://www.opensourcecf.com/imagecfc/

version 2.11 includes the following changes:

I originally realized 2.11 on December 14, but made a minor correction to ImageObject.cfc today and repacked it without changing the version number so if you downloaded version 2.11 already, please do so again.

Also, ImageCFC 2.11 has been integrated into CFFM 1.15.

Project Page for ImageCFC:  http://www.opensourcecf.com/imagecfc/

version 2.10 adds image filtering capability to ImageCFC, including the following:

 o simple blur (very fast)
 o box blur (slow)
 o gaussian blur (slow)
 o sharpen
 o posterize

Some examples of each of the filters.

http://www.opensourcecf.com/imagecfc/examples.cfm

Thanks to everyone who assisted via the list!

Rick

I've completed imageCFC version 2.0

Numerous changes since beta 3... and unfortunately some of the changes will break your code if you're using image.cfc 2.0 beta.

NEW (REAL) DOCUMENTATION!
http://www.opensourcecf.com/imagecfc/docs/imageCFC.cfm

This release includes a few bug changes plus the following changes:

• readImage() and writeImage() are now public methods.
• writeImage() method writes to temp directory and then uses cffile to move image to its final destination. This corrects a known issue where resizing an image down and saving it to the same file did not actually reduce the physical file size.
• changed scaleX() to scaleWidth()
• changed scaleY() to scaleHeight()
• Added optional preserveAspect argument to resize() method (allowing you to resize an image to fit within a certain width and height without messing with the aspect ratio)
• You can turn text antialiasing on and off, or change the interpolation mode now using the setOption() method.
• WROTE REAL API DOCUMENTATION!

There are a variety of other fixes and minor enhancements. Please see the full change log on the site for details.

CFOpenMail / ImapCFC project page

Every time I made a change to the code in imap.cfc, I had to reinitialize it and log in again.  I had to do this because the init() method stored the connection information in the variables scope of the CFC.. so reloading the CFC would wipe them out.  That got old really fast, so I moved the connection information into the session scope.  Now during development, the CFC can be reloaded on every page call if I want.. but I'll probably just add a "refresh CFC" shortcut into CFOpenMail to ccause that to occur so it only happens when I want it to.

I updated the delete() method to allow the deletion of multiple messages.  I also adjusted the getfolderinfo() and getfolderstructure() methods so they return more information, and don't attempt to get information like message counts and unread message counts on folders that can't actually hold messages.

The copyMessages() method now throws meaningful errors for things like "The destination folder does not exist" and "The destination folder cannot contain messages".

Also, the getMessage() method will throw a meaningful message when you attempt to retrieve an invalid message number.  "The specified message number was not found in the specified folder." instead of what was essentially an "Array index out of bounds" error.

CFOpenMail / ImapCFC project page

I corrected the issue with the folderDelete() method.  It's very strange the way the actual delete method works in the java folder object.  It nearly always returns true, even if the delete fails.  The correct way to determine if the delete was successful is to run the exists() method on the folder you just deleted.  Sometimes, I think OO programming is a little wacky.  Or maybe it's just this particular implementation.

I also implemented the copyMessages() method in CFOpenMail.  I haven't tested it thorougly, but it does work.

The CFC on the project page has been updated to include today's changes.

CFOpenMail / ImapCFC project page

I corrected a bug in the folderRename() method involving mismatched variable names (obj_Folder and objFolder).  However, the method still doesn't work.  Maybe my imap server doesn't allow renaming of folders.  It says it's working, but it's just not renaming the folder.  No errors, and it returns true.

I also added a recurse option to the folderDelete() method that should prevent you from deleting a non-empty folder unless you specify to do the delete recursively.  This too, doesn't work.  Might be time to drop a line to the JavaMail-INTEREST mailing list.

CFOpenMail / ImapCFC project page

Earlier this week, I decided it would be fun to build a webmail application.  Of course, any good webmail application connects to an IMAP mail server, so I needed to figure out how to use imap in Coldfusion.

Although Bluedragon has a CFIMAP tag, Coldfusion (currently) does not.  I wanted to go open source, and didn't want to require any DLL installations or anything so most of the custom tag options out there were not options (like CFX_IMAP, CFX_IMAP4, etc).  But I did find a project on sourceforge called cfimap-cfc.  Sweet.

I started cranking away, and I've made a LOT of changes to imap.cfc, enhancing its functionality, fixing bugs, etc.  Some of the major changes so far:

• an authenticated imap session can be stored in memory (the session scope), so you don't have to authenticate every time you try to do something.  This was a HUGE performance increase.
• the "view" method was incompatible with multipart mime messages with parts whose content type was multipart/*.  In otherwise, a message might have two parts, but one of those parts might also have multiple parts as well.  Curiously, the old imap.cfc worked with such messages but only grabbed the first subpart in such situations.  This required taking part of the view() method out and putting it into a separate method called getParts(), which calls itself recursively for multipart parts.
• I've properly var scoped *EVERYTHING*.  Version 1.0 of imap.cfc was not var scoped at all, and you could have easily experienced all kinds of variable problems.
• The old imap.cfc attempted to put HTML and text attachments inline.  Personally, in a web based application, I'd just rather see them as attachments, and so that's what it does now.
• The download method was enhanced by adding an includeData argument, which, when false, causes the returned structure to not include the actual binary file contents.  The method also now returns file size as well, so you can publish the list of attachments along with their content type and size.
• Added a slew of try/catch statements because some folders can't contain messages, so you can't open them.  I don't really know why for sure, but I've got one such folder in my Sent folder, so I added error trapping.
• I also added code hints, changed some variable names and column names, and did some commenting of the code too.

It's worth mentioning that I've never worked with the JavaMail API before, so this was fun and challenging.

There's still a lot of work to do, particularly with regards to the send() feature.  I also haven't yet  tested the deleting, creating, or renaming of folders, nor have I tested the copyMessages() method either.