I just switched to Flash Builder 4.5 and noticed that the code completion is really delayed. However, after doing some digging I found out that this is simply a setting you can tweak to your satisfaction.
Go to Preferences > Flash Builder > Editors and change the value of “Enable auto-activation of code and template proposals“. I have it set to 50 ms and it’s looking slick and snappy. Screenshot below.
Thanks to this article for the tip.
If you are having trouble with Facebook Comments moderation through WordPress, this may be your solution.
The first thing to always check with Facebook is that you are using their most recent protocols. Facebook is notoriously changing how you must integrate it into your website, to be sure to check this link regularly: https://developers.facebook.com/docs/guides/web/
And the latest code (August 2011) is below. Place this below the opening <body> tag in your HTML document.
<div id="fb-root"></div>
<script src="http://connect.facebook.net/en_US/all.js"></script>
<script>
FB.init({
appId:'YOUR_APPLICATION_ID', cookie:true,
status:true, xfbml:true
});
</script>
In order to have comment moderation, you’ll need to do a few things:
1) Set up an App and enable moderator access to whoever needs to have it.
2) Add relevant <meta> property tags to the <head> portion of your website.
3) Match the comment plugin’s href attribute to the current permalink URL.
There are two ways to do the <meta> property tags. You can either enable a specific user to have moderator access or give access to all moderators within the App. Going with the App method is more ideal because it will connect to your App’s dashboard in www.facebook.com/developers/. A direct link to managing comments via the App interface would be https://developers.facebook.com/apps/{YOUR_APPLICATION_ID}/plugins?view=queue. This method’s code is below:
<meta property="fb:app_id" content="{YOUR_APPLICATION_ID}">
You can always read more about the comments plugin by going to https://developers.facebook.com/docs/reference/plugins/comments/ although their documentation is typically confusing and subpar.
One way WordPress can make moderation break is due to the fact that page GUID’s may be different from your permalink URL’s. If you put a $post->GUID into your <fb:comments href=”">, moderation will NOT work. The comments URL and the page URL must be identical. To get the page URL of a post, you can use get_permalink(). By feeding the permalink into your comments plugin and doing the other steps above, you should be in good shape! Just be aware that by changing permalink structure or changing URL’s you will lose all of your comments.
(this solution was discovered via http://forum.developers.facebook.net/viewtopic.php?id=102099)
Tonight I wrestled with the IE9-agator because my SWF would just not show up in the browser no matter how much Javascript or Facebook stuff I removed from my semi-bloated HTML-Template file. I looked around the web and there appears to have been a wave of IE9-related issues with Flash Player 10.x, and unfortunately this is one of them. However, the solve quite easily (yay).
I stumbled upon a solution after reading this bug report ( http://code.google.com/p/swfobject/issues/detail?id=547 ). I tried removing the swfobject.createCSS(); call and what it revealed was something far stupider. Look at the default CSS from Flashbuilder’s HTML-Template below:
<style type=”text/css” media=”screen”>
html, body { height:100%; }
body { margin:0; padding:0; overflow:auto; text-align:center;
background-color: ${bgcolor}; }
object:focus { outline:none; }
#flashContent { display:none; }
</style>
The line for #flashContent is normally toggled to display:true with all other browsers once everything is honky-dory (including past versions of IE) but for some reason IE9 does not get the message to do so. If you get rid of this line you may get a millisecond flicker of your alternate text but your SWF will show up!
Ever had this happen? You have an existing text field, and you want to see its textFormat properties. So you do…
var fmt:TextFormat = myTextField.getTextFormat();
Unfortunately, all of the properties (fmt.font, fmt.size, etc.) of fmt are null!
This bug was driving me crazy. What I discovered was that getTextFormat() is basically retarded under two conditions:
1. Your text field is empty and has never had text in it.
2. Your text field is empty, had text in it at some point, and is set to use Single Line.
Under condition #1, you will never be able to pull any TextFormat data out of your text field, even though it technically should be there. In condition #2, you MUST set the text field to multi-line or it will not work.
What is the solution? Put an empty space in your text field before you use it. This seems really dirty but unless you want to dynamically generate all of your fields, this is the gift Adobe has given us :)
I had a heck of a time looking for a solution to this very common problem. Fortunately, the solution is quite easy!
WordPress, by default, limits your search results to 10 per page. When doing a normal query, you’d use get_posts(numberposts=99) to determine how many results appear from your query. You use a different parameter, showposts, for search pages.
So how do you modify the query to show what you want? Simply take the current $query_string (generated by WordPress’s header functions) and modify its showposts. Make sure to do this before the loop and you’re all good! All the code you need is below.
[php]query_posts($query_string . ‘&showposts=12′);[/php]
If you know a pretty girl, do not use Photoshop to make her pregnant. Girls do not like receiving these kinds of greetings.
(censored to protect the innocent)
If you’re using custom post types in WordPress and your category pages are throwing 404′s every time you try to paginate, you may be running into a bug with the WordPress core (as of version 3.0.4).
There is a solution — but first make sure that you have:
1) Checked your permalink settings to make sure there is nothing wonky. Try the recommended presets in the permalinks settings page and see if you are still having a problem.
2) View the same category page on the default skin. This will rule out issues that may lie within your specific code.
3) Cried a bit. Just kidding… kinda (I suffered for days before coming to a resolution courtesy of Mark / t31os)
If you’re still getting 404′s… here’s the code that saved my life. Replace your_custom_type with your custom type (surprise). You can put however many custom types as you’d like. Do this in your functions.php.
[php]add_action( 'parse_query','changept' );
function changept() {
if( is_category() && !is_admin() )
set_query_var( 'post_type', array( 'post', 'your_custom_type' ) );
return;
}[/php]
Best of luck! You can view my entire sob story / thread here (and give Mark all of your money if possible).