After I upgraded from Subclipse 1.4 to 1.6, for some reason (I pretty sure it was Subclipse as I didn’t upgrade anything else), it decided that it didn’t like my comment color in CFEclipse or my highlight color and decided to randomly alter those colors to something else…a really weird, dark green for the comment background color and a much darker shade of blue for the text highlight color. To my mild case of OCD, that is just unacceptable Plus it’s just really difficult to read *any* text with a dark green background

If you want to switch these options back to their original colors, do the following:
Window -> Preferences -> CFEclipse -> Editor -> CFML Colours -> CFML Comment Background
I switched this one back to white from dark green.
and
Window -> Preferences -> CFEclipse -> Editor -> Appearance color options -> Selection background color
This one I had to create a new custom color and set it to Red 49, Green 106, and Blue 197 (this, I think, is the windows highlight color).

So far these are the only things I’ve found that it changes. I’ll post new updates if I find anything else.

There is a file called config.xml (on my PC it is located in C:\Program Files\Adobe\Flex Builder 3 Plug-in\eclipse\plugins\com.adobe.flexbuilder.flex_3.0.214193) that gets installed when updating via the Adobe updater. I’m not quite sure what happened, but it decided that my compiler arguments should be set to ja_JP. In order to fix this problem, just change this line from

<locale>ja_JP</locale>

to

<locale>en_US</locale>

This will now add en_US as an additional compiler argument instead of ja_JP. Now I can get back to coding again

Each time I create a new project I get -locale ja_JP added to the compiler arguments. It’s an easy fix, just remove that or change it to en_US, but I have to do that each time I create a new project. If I could even find the file that’s making that setting, I would be happy to manually alter it, but I haven’t even been able to find that. My flex-config.xml file appears to be set to en_US also, so I have no clue how ja_JP is getting in there.

If anyone has any ideas, I’d be extremely grateful.

In order to make what I did more visible, I decided to enable the source code view when exporting the release build of the project. After exporting the file and FTP’ing it to the server, I started to have some difficulties getting the source code view working properly. Rather than wasting more time trying to get it working, I decided to just uncheck the Enable View Source check box, and re-export the project. However, when I went to my swf and right clicked on it, “View Source” was still an option in the Context Menu. I went back and tried cleaning my project, re-exporting it, deleting the swf and recreating the project. Nothing seemed to be working.

I then figured I would try creating a new project and placing it under there. As I was pasting the new application file, I noticed one new line had been added to my file
viewSourceURL=”srcview/index.html”

Apparently when the compiler enabled “View Source”, it adds this line of code. However, when it re-compiles the code with “View Source” disabled, it does not remove that attribute from the application tag. 30 minutes and lots of yelling later, this has now fixed the problem. It would be nice if Adobe included this little tidbit in their livedocs as “make sure to check this”.

The demo app can be viewed here for anyone interested.

In my work environment, my exported release builds and my debug builds are both built to the same spot, which is due to our upgrade process to Flex being an incremental process (from our current HTML + CFM app). In order to add some values to the Flex app, I write them to the HTML page, thus I decided to build them to the same spot. I had not realized at the time that I had exported a release build right before lunch, then when I returned, I was trying to debug the release build. Due to the very nature of the release build, the debug is removed, thus Flex Builder was not able to stop at the breakpoints. For some reason, Flex Builder wasn’t telling me this initially though (even after I had cleaned the project).

My steps to fixing most Flex weirdness (i.e. something isn’t happening that I feel should be happening), is to clean a project first, then restart Flex Builder, if neither of those work, restarting my PC is next. One of those will usually fix the problem .

In order to fix this, close out of Flex Builder or Eclipse and go to wherever you have Flex Builder preferences installed (which for me was in my “My Documents” on my C: drive), not the main Program Files directory.

This was where mine was located C:\Documents and Settings\(my logged in account)\My Documents\Flex Builder 3\.metadata\.plugins\org.eclipse.core.runtime\.settings

Once you are in this directory, back up then open up
org.cfeclipse.cfml.prefs

Once inside this, add the line
lineNumberRuler=true
and save the file

Now you can open Flex Builder/Eclipse again, and line numbers should be showing up for you when view ColdFusion files.

Just want to thank Francois Levesque over at http://blog.critical-web.com/blog for this.  This has saved me many headaches.

This regular expression can be used in Eclipse (my current IDE) and will convert something that looks like:

<cfset variables.firstName = "" />
<cfset variables.lastName = "" />

into

<cffunction name="getfirstName" output="false" access="public" returntype="any">
<cfreturn variables.firstName />
</cffunction>
 
<cffunction name="setfirstName" output="false" access="public" returntype="void">
<cfargument name="val" required="true" />
<cfset variables.firstName = arguments.val />
</cffunction>

The search string is:

<cfset variables.(\w+) =  [^>]+>(\r\n)(\t)

and the replace string is:

<cffunction name="get$1" output="false"  access="public" returntype="any">$2$3$3<cfreturn variables.$1  />$2$3</cffunction>$2$2$3<cffunction name="set$1" output="false"  access="public" returntype="void">$2$3$3<cfargument name="val"  required="true" />$2$3$3<cfset variables.$1 = arguments.val  />$2$3</cffunction>$2$2$

The search string contains a “tab” character at the end. This is really just so I can format the output of the getters and setters, but feel free to modify them however you wish.

The first thing I came across that was mildly annoying, but needs to be noted as it may cause some issues for others trying to follow along with the tutorials.  In Tutorial: Notepad Exercise 1, Step 1, it mentions that to create the new project to download the source and select “Create project from an existing source”.  When I tried to do this, Eclipse balked and stated that there already existed.  I then moved my files from my workspace to my desktop then tried again.  However, using this method, the project was now using the files from my desktop.

I think the better way to get the project up and running is to import the files (as Eclipse actually states when you try to create the project in the same space as your workspace).  To do this go to

File -> Import -> General -> Existing Projects Into Workspace
Then select “Browse” next to “Select root directory” and find your Notepad files (mine were on my desktop).
Make sure to also check “Copy projects into workspace” so the files are copied to your android workspace.
Click Finish.

Now you should have the Notepadv1 project imported into your android workspace in Eclipse and all files should be located with the rest of your android files.  This to me seems like a better way of accessing the files than having them all over your computer.

I was rethinking how I did this and came up with a new method. The only difference is that this test will need to be run twice, once for the opening parenthesis and once for the closing parenthesis. As I usually just do a “Replace All”, I figured it wasn’t that much more difficult than doing it the old way (plus this will work for a much parenthesis nesting as a user puts in).

The Regular Expression is:

Find: \((?! |\))
Replace: "( "

remove the double quotes first…I just wanted to make the space visible.

This regular expression means:
Find an opening parenthesis

\(

Then check the next character (but do not include/consume it in the “find”). If it is not a space or a closing parenthesis, match the statement

(?! |\))

This will work on something like:

(((test())))

which, after the first run, becomes

( ( ( test())))

Then the second Regular Expression would be:

Find: (?<! |\()\)
Replace: " )"

remove the double quotes first…I just wanted to make the space visible.

This regular expression means (starting from the right this time):
Find a closing parenthesis

\)

Then check the previous character (but don’t include/consume it in the “find”). If it is not a space or opening parenthesis, match the statement.

(?<! |\()

This will take the previous finished example of:

( ( ( test())))

and change it to:

( ( ( test() ) ) )

By adding the extra space to my code, I think it makes everything a little bit easier to read. This will work for any type of brackets (or any character for that matter). In the first find statement, you can replace the parenthesis in \) and \( with \[ or \] or whatever you want. The same goes for the second find statement. I don’t know why I didn’t think of doing it this way before instead of trying to figure out how to code a really long match for the opening and closing parentheses. It will definitely make my life easier.

My company has come up with a set of standards that we’re trying to follow when writing our code, so, if anyone else joins the company and edits/creates new code they can just follow the guidelines we already have set up. In order to keep track of all of the regular expressions I’m writing (and so others can use them if they wish), I’ve created a Regular Expressions page that I’ll periodically be updating with new regular expressions each time I use them. I know they’re useful to me, so I’m sure that at least one other person will have a use for them too .

Enjoy!