dans.blog

I was doing some UI work this morning and ran into a bit of a problem. We have some HTML input elements that need to be disabled so the user can not interact with them. The problem is, we wanted to display a message to the user if they tried to interact with the element. While some browsers respond to a mousedown event, Firefox and Opera ignore all mouse-related events on a disabled form field. Since they seem to completely ignore mouse interaction, that means not even event delegation works.

After thinking about various ways to work around the behavior, I thought the most elegant solution might be to add an overlay over the disabled element which I'd use as the hotspot for mouse interaction. The overlay lays on top of the element and intercepts all mouse interaction.

Let's look at some sample HTML:

<label for="normal">
  <input type="checkbox" disabled="disabled" />
  Disabled Option
</label>

With a little jQuery magic, we can find the disabled element, get the parent <label /> element and then place a <div /> element over where the label element resides. The code looks like this:

// on DOM ready
$(document).ready(function (){
  // attach a click behavior to all checkboxes
  $(":checkbox").click(function (){
    alert("Clicked!");
  });

  // find the disabled elements
  var $disabled = $("#overlay-example input:disabled");

  // loop through each of the disable elements and create an overlay
  $disabled.each(function (){
    // get the disabled element
    var $self = $(this)
      // get it's parent label element
      , $parent = $self.closest("label")
      // create an overlay
      , $overlay = $("<div />");

    // style the overlay
    $overlay.css({
      // position the overlay in the same real estate as the original parent element 
        position: "absolute"
      , top: $parent.position().top
      , left: $parent.position().left
      , width: $parent.outerWidth()
      , height: $parent.outerHeight()
      , zIndex: 10000
      // IE needs a color in order for the layer to respond to mouse events
      , backgroundColor: "#fff"
      // set the opacity to 0, so the element is transparent
      , opacity: 0
    })
    // attach the click behavior
    .click(function (){
      // trigger the original event handler
      return $self.trigger("click");
    });

    // add the overlay to the page  
    $parent.append($overlay);
  });
});

You can see a live example here.

Posted by Dan on Apr 23, 2010 @ 3:08 PM

Rey Bango and had a little discussion this morning on Twitter about a JScript update Microsoft recently released to fix a native JSON feature in Internet Explorer 8. I made the comment that it's really only a useful, if Microsoft really automatically pushes the update to users (which I meant via Windows Update—which Rey confirmed to me that they are indeed.) Rey and I then had an ongoing dialog via IM about browser updates in general.

For those of you who aren't aware, Google Chrome uses background updating to automatically update the browser when updates are available. The updating happens seamlessly in the background—there's no visual indication that updating, it happens in the background when you're using your PC.

When I first discovered that Chrome does this (shortly after installing the initial beta,) I was really irritated. I was really against the idea of software upgrading itself without my interaction. I don't like my PC doing things without my permission.

However, after using the beta and having it automatically update itself, I realized it worked pretty well for beta software—which is often buggy. Then I really started thinking about the whole idea of background updating. I started thinking about how much easier my job as a web developer would be, if I wasn't always fighting the battle of supporting old browsers (specifically IE6/7.)

Could you imagine if IE had implemented this concept in Internet Explorer back in 1998? We'd no longer have sites full of HTML, JS and CSS hacks targeted specifically at fixing IE6 or IE7 issues. That would certainly make my job easier.

There are certainly issues with background updating. Browsers that have a plug-in/add-on framework certainly risk breaking the browser with automatic updates—which is definitely an issue. In order to do background updating, you've got to make sure that it doesn't change the user's browsing experience. While Google's has enhanced certain features of Chrome, they haven't implemented any drastic changes to the user's experience—which is important.

While in general, I'm not a fan of automatic updates, in my findings the average web user doesn't really care what their browser is doing—as long as it doesn't change how they use their browser. The average user doesn't proactively look to upgrade their PC—that's one reason so many PCs get infected with viruses/trojans/spyware/etc.

I consider my parents to be a pretty good representation of the normal web user and I just can't get them to keep their PCs up-to-date. No matter how many times I tell them to stay up-to-date on Windows Updates, the response I always hear is "I'm afraid I'm going to break my PC!" Too many users get tricked into clicking and installing stuff from the Internet, because it looks like a PC update and they become afraid of updating.

Anyway, the more I think about it, the more I like the idea of browsers (by default) keeping themselves up-to-date automatically. While there will be vocal crowd against the concept, as long as updates aren't making drastic changes to the user's experience, the general user just doesn't care.

There's definite risk in this approach, because vendors have to be very careful that they're not breaking the user's browser or their experience—that will only frustrate users. However, I'm definitely curious to see if Google is successful in with their current strategy of automatically updating Chrome. I really haven't heard a very vocal outcry against it and Chrome's seems to be picking up popularity, so we'll see how it all plays out.

I have definitely become a fan of the idea that maybe some day in the future I won't have to keep implementing various hacks just because web users don't/won't/can't upgrade their browser. I just think how wonderful the web might be if IE6 was no longer around.

Posted by Dan on Feb 24, 2010 @ 11:17 AM

For the longest time I've been stuck on Mylyn Eclipse Plug-in v3.0.5—which is very old. Every time I attempted to upgrade to a newer version, Mylyn could no longer authenticate against my Trac installation on Apache. It was a frustrating problem, because I really wanted to upgrade to take advantage of a number of enhancements and fixes.

Today I went upgrade another plug-in and figured I'd try the latest version of Mylyn to see if my issue was resolved. Unfortunately, I was still getting the error "Insufficient permissions for selected access type" anytime Mylyn would try to authenticate via the XML-RPC method. What was really strange, is when I tried connecting via the "Web" method, everything worked fine (which was a new behavior.) So, I decided to spend some time in Charles HTTP Proxy to see if I could debug the issue.

I spent some time monitoring the HTTP traffic, but really couldn't find any rhyme or reason why the authentication was failing. So, I decided to investigate my Apache modules to see if there were any updates to the authentication modules I was using.

One aspect of my Apache configuration that is a little different is that I use mod-auth-sspi module because I authenticate against our Active Directory server (see Configuring Windows Authentication with Apache 2.2.x and Subversion.) After much research and playing around with our configuration, I finally discovered the fix for my problem.

There's apparently an issue with the case that Mylyn sends the authentication information in, the trick was to change my Apache configuration and add the line: SSPIUsernameCase lower

Here's what my authentication configuration rules look like in my Apache httpd.conf file:

AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
# set the domain to authorize against
SSPIDomain AD
SSPIOfferBasic On      # let non-IE clients authenticate
SSPIOmitDomain On      # keep domain name in userid string
SSPIBasicPreferred Off # basic authentication should have higher priority
SSPIPerRequestAuth On  # required for IE POST operations
SSPIUsernameCase lower

So, if you're having mystery issues with applications authenticating against your Apache server and your using SSPI, you might try implement the SSPIUsernameCase lower directive.

Posted by Dan on Feb 16, 2010 @ 11:40 AM

Many of you may know that the wife and I have our first baby due this Spring. One the things I've been researching since I found out the wife was pregnant has been IP cameras. I really like the idea of being able to check in on the baby at any time to make sure she's ok—without actually walking in and risking waking her up.

I looked at a lot of various wireless cameras, from baby-specific video monitors to IP cameras, but the features that were key for me were:

• Night vision—this is a must to check in on a sleeping baby
• Viewable from my iPhone—the wife and I both have iPhones and this makes the perfect remote video monitor
• Remote pan/tilt
• Audio monitoring (2-way audio would be a bonus)
• A way for the Grandparents to view in on the baby

After looking at some baby video monitors (which didn't meet all the above requirements anyway) I realized that they're all over priced and most got pretty poor reviews. I was leaning towards getting an IP camera anyway, so this made the decision easier.

After looking at many different models, I ended up purchasing the Foscam IP Wireless/Wired Camera (Model: FI8908W). I looked at a few Axis cameras, which are great cameras, but really more expensive than I wanted to pay and really way more than I needed. I also seriously considered getting Astak Mole IP Camera—it met all my requirements, but just was a little more than I wanted to spend. Then just last weekend I stumbled across the Foscam camera. It met all my needs and I could get it shipped for around $95.

After playing around with the camera a bit last night, here's my findings:

• The camera uses MJPEG for streaming video—which doesn't natively support audio. There is an ASF streaming URL you can access (which supposedly includes audio,) but I haven't found the necessary codec to view it with Windows Media Player. Supposedly VLC will play the stream fine, but I don't want to install another app if I don't have to.
• Terrific night vision—I was really impressed with the quality in a pitch black room.
• Pretty straight forward setup. While I found it easy/quick to setup, someone without good gadget skills might struggle a bit.
• Decent integrate web-interface. While it has lots of options, it's not particularly user friendly. Fortunately, you can give out URLs straight to the stream for family members.
• Multi-user configuration. You can have up to 8 separate user accounts. Users can either be an Administrator, Operator or Visitor. An Operator can do everything but change configuration—including changing the camera pan/tilt. A Visitor can only view the picture.
• The picture quality is a little washed out, but seems to do well in low lighting. I've heard that replacing the lens can improve the coloring, but I think it's sufficient for monitoring purposes—I don't need exact color matching.

I would definitely say the camera is well worth the $100. I'm still playing around with it, but there's a nice iPhone app called Foscam IP Control for $1.99 that allows you to remote view the camera and alter the pan/tilt (it does lack a full screen mode.) Since I'm still not sure how I'm going to expose the camera to the world, I may end up changing apps but it works well.

If you decide this camera, you must watch out for Foscam clones. Apparently there are a slew of online resellers selling clones of the Foscam (same box, same design) that use a different firmware. Foscam has a list of authorized resellers on their site. I ended up using an eBay reseller named usahitec. I ordered the camera on Saturday for $95.60 (w/free priority shipping) and it got here yesterday (Wednesday.)

If you want more information on the Foscam camera, check out Gadget Victims has several really insight blog entries:

• http://www.gadgetvictims.com/2009/07/foscam-ip-camera-part-two.html
• http://www.gadgetvictims.com/2009/08/third-party-software-for-foscam-ip.html

So far this seems like an excellent way to monitor my sleeping baby and give the out-of-town grandparents a way to keep up with the baby too!

Posted by Dan on Feb 4, 2010 @ 1:08 PM

For Christmas this year, the big family gift was a new Samsung PN58B860 58" Plasma TV. Our old TV worked fine, but with the baby on the way I we wanted try and reclaim some living room space—much of which was being taken up by our old Mitsubishi 55" rear projection TV.

We absolutely love the picture, but from day one we started running into a problem with the TV in which it would just randomly power off and then immediately back on. I went through a battery of tests trying to determine if it was a power issue, cable issue, etc. I tried replacing the HDMI cable, hooking the TV up directly to the cable, changing outlets, etc. Nothing I did resolved the issue. Since the problem was random (on average, probably happened once an hour, but we might go a couple of hours with no issues or it might happen several times within a few minutes.) It didn't matter what we were watching—could be cable TV, a DVD, playing XBOX, etc. The TV would just turn off and then turn right back on.

After talking to Samsung and HH Gregg everyone seemed to think it was the power supply on the TV and since the TV was less than a week old, HH Gregg delivered a replacement TV. However, the new TV was having the same problem. So, once again I started going through my battery of tests trying to figure out what was wrong.

After testing tons of things, I finally found the root case—the Internet connection.

Newer TVs are now coming with Internet connections. Being the tech guy I am, I immediately hooked my TV up to the Internet so I could get firmware updates, view Flickr photos, etc. To get up and running quickly, I had plugged my TV into the wireless bridge I was using for my XBOX 360—which I had the IP configured as the DMZ in my firewall (which I had done to resolve some issues with online play.)

Since now the TV was acting as a DMZ, all unrecognized traffic was being routed to the TV. I suspect what was happening is various ping and exploit attacks on my IP address was causing problems with the TV, so the TV would just shut down and power up again. I just never thought that the Internet connection would be the root casue of the TV rebooting.

Anyway, if you have a Samsung TV that's recycling the power, try unplugging your Internet connection and see if that improves the situation. Also, never run a device as a DMZ unless you know what you're doing!

Posted by Dan on Dec 21, 2009 @ 10:27 AM

Several years ago, I bought a set of Milwaukee power tools. I love the tools, but one of the batteries seemed to die after a few years (but very little usage.) The batteries are like $80 and since I don't use the tools very often, I've never bothered replacing the one that seemed to be dead (since I have 2 batteries.)

However, today I came across a very cool tip.

Apparently these "dead" batteries are a known issue with Milwaukee and often the batteries aren't dead, but just need to be jump started. To awaken one of these dead batteries, place a standard 9-volt battery against the leads on your dead Milwuakee battery for 30 seconds (single lead on your Milwaukee is positive, the double lead is negative.)

Sure enough after doing this little tip, I was able to plug my battery in to the charger and it started charging it!

Posted by Dan on Dec 3, 2009 @ 4:05 PM

Yesterday I rebooted my personal dev server and much to my chagrin, when the server started back up the ColdFusion 8 Search Server service (aka Verity) would not start. Any attempt to start the service would result in the following error:

Error 1067: The process terminated unexpectedly.

I looked around ColdFusion's log files, but couldn't find anything useful so I decided to try and start up Verity from the command line. Running from command line resulted in:

K2Admin - Verity, Inc. Version 5.5.0 (Build 20050601)
Resolved Entity [admin.dtd] to DTD file [C:\ColdFusion8\verity\k2\common\admin.dtd]
D:\ColdFusion8\verity\Data\host\admin\admin8.xml parsed in 16 ms
Status: Starting K2Admin Version 5.5.0 (Build 20050601 Sep  4 2006 14:41:49)
Status: Service Alias: ColdFusionK2 (Host:localhost Port:9951)
Status: Master Administration Server: localhost:9951
Status: Creating Backup Service - 2 threads
Status: Creating Broker Service - 1 threads
*** FATAL Application Error ***
Exiting ...

I hunted around trying to find the root cause for the fatal application error, but I couldn't find anything on Google or any of the forums I checked. Since I wasn't getting anywhere, I decided to try uninstalling and reinstalling the Verity services.

Inside the .\ColdFusion8\verity folder, there's two files called verity-uninstall.bat and verity-install.bat which you can use to uninstall and install the Verity service.

I ran the verity-uninstall.bat batch to uninstall the service and once the service was correctly uninstalled, I went ahead and ran the verity-install.bat file to re-install the service.

Fortunately this fixed the issue for me. I had to re-create all my collection, but that wasn't a big deal (time consuming, but painless.)

So, if your Verity service isn't starting up and nothing else you've tried is working, you might just trying uninstalling and reinstalling the service.

Posted by Dan on Nov 6, 2009 @ 5:08 PM

Sometime in the last week or so, Flash stopped working me on many sites. It seemed to stop working around the time of the last Microsoft Vista updates, but I can't be sure. The strange thing is, it worked on some sites (like Adobe) but wasn't working on a lot of the sites I was visiting. I tried reinstalling Flash, but that didn't fix it. Since it wasn't a high priority for me, I haven't had time to look into it until today.

Today I was doing some QA on our site and noticed one of the Flash components was no longer working. Since Flash seemed to break for me around the time of the last Windows Update, I thought I should probably look into things to see if this is a wide spread issue.

I quickly fired up a couple of different versions of Firefox (and on different PCs) and they were all working fine. This seemed to indicate the problem might be local to my installation.

Next, I decided to actually examine the source code in Firebug—which is when I noticed something odd. The <object /> tag was grayed out like it was hidden or being ignored. So, I fired up the same page in another Firefox install and the <object /> tag was being shown as expected.

NOTE:

At this point I also checked some of the sites I remembered where Flash was working and sure enough they were using the <embed > tag instead of the <object /> tag.

Since I thought this was extremely odd, I decided to fire up a brand new Profile to see if things would work in an empty Profile. Dropping to a command prompt, I used firefox -P to create a brand new profile called "test". Next I used firefox -P test -no-remote to open up the new profile (the -no-remote argument allows you to open a separate instance of Firefox using a different profile.)

When using the new Profile, Flash was worked as I expected. This told me something was wrong with my normal Profile, but what?

In order to track things down, I first tried disabling add-ons that looked like primary suspects (Firebug, Web Developer, AdBlock Plus, etc.) Nothing changed. I next tried uninstalling these add-ons. Flash still not working. I finally just uninstalled all the add-ons. And what do you know? Flash started working again.

In order to try to determine which add-on was causing my Flash problems, I tried installing each add-on individually. Unfortunately (at least from a troubleshooting standpoint) after re-installing all the add-ons Flash is still working correctly.

So I obviously had a problem with my profile that was caused by one of the add-ons I had installed. Unfortunately, I do not know which add-on was the culprit. I do know that after removing all my add-ons and reinstalling them Flash is now working properly again.

UPDATE:

Here are a list of the add-ons I had installed, all of which have been reinstalled:

Adblock Plus 1.1.1
Clear Cache Button 0.9b
ColorZilla 2.0.2
Download Statusbar 0.9.6.5
Firebug 1.4.3
Firesizer 0.92
Free Download Manager 1.3.4
Html Validator 0.8.5.8
IE View 1.4.4
Microsoft .NET Framework Assistant 1.1
Organize Status Bar 0.6.3
Page Speed 1.3
Print Context Menu 1.2
QuickFrame 0.5.1
QuickProxy 2009.07.19
Web Developer 1.1.8
XMarks 3.3.2  (NOTE: I didn't actually uninstall this add-on, it was the one exception of an add-on that I did not uninstall.)

Posted by Dan on Oct 21, 2009 @ 11:32 AM

Occasionally I've run into a situation where I've wanted to add some whitespace between two options in a <select /> element. The most common solution I've seen people use is to include an empty <option></option> tag pair. While this works, it adds a blank entry that the user can actually select—which means you have to add some code to handle the selection of what is designed to just be used for whitespace.

A better solution is to use an empty <optgroup /> that is disabled:

<select>
  <option>Value 1</option>
  <!---// add a non-selectable space between options, the margin-top is for FF spacing //--->
  <optgroup disabled="disabled" style="margin-top: 1em;"></optgroup>
  <option>Value 2</option>
</select>

This will add a non-selectable blank line between "Value 1" and "Value 2". Here's an example:

Value 1 Value 2

I use this technique often before normal <optgroup /> tags as it helps make the menu look a little cleaner by adding some separation between the options and works with all modern browsers. Best of all, you don't have to worry about handling those empty <option /> tags!

Posted by Dan on Oct 16, 2009 @ 11:53 AM

While working on some code today, I faced a problem I've run into a few times in the past where I needed to find the first usable input element within a specific context. What I mean by "usable" is an element which is visible to the user and not disabled.

Finding the first usable input element can be handy when you're using tabbed form, as when the user changes tabs, you can place the focus in the first visible input element. In my use case, I was implement a "reset" on a form where the fields being displayed could vary. I wanted to automatically place the focus in the first visible field after the user triggered a "reset" of the form.

If you're using jQuery v1.3 (or higher) this custom selector is very simple, just add the following to your page:

// finds elements that are usable (i.e. visible on the screen and are not disabled)
$.expr[":"].usable = function (node, index, prop, nodes){
  var $n = $(node);
  // return if the element is viewable or not            
  return ($n.attr("disabled") !== true) && $n.is(":visible");
};

If you're using jQuery v1.2 (or lower) the code is slightly more complex because the ":visible" selector doesn't check with the parent elements to make sure they are all visible. So, in order to make our code work with jQuery v1.2 we'll need to first create a custom selector for which will find elements that are truly visible:

// finds elements that are viewable
$.expr[":"].viewable = function (node, index, prop, nodes){
  var r = false;

  function viewable(n){
    var $n = $(n);
    return (($n.css("display") !== "none") && ($n.css("visibility") !== "hidden"));
  }

  // if not usable, stop processing
  if( !viewable(node) ) return false;

  $(node).parents().each(function (){
    r = viewable(this);
    // if not viewable, stop processing chain
    return r;
  });

  // return if the element is usable or not            
  return r;
};

The new ":viewable" selector should pretty much behave the same way that the ":visible" selector does in jQuery v1.3.

The only difference in this version of the ":usable" selector is that we're going to use our custom ":viewable" selector instead of the ":visible" selector:

// finds elements that are usable (i.e. visible on the screen and are not disabled)
$.expr[":"].usable = function (node, index, prop, nodes){
  var $n = $(node);
  // return if the element is viewable or not            
  return ($n.attr("disabled") !== true) && $n.is(":viewable");
};

The ":usable" selector can be used in several ways:

// find all usable form elements
$(":input:usable")

// find the first usable form element
$(":input:usable:first")

While the most common usage of the selector will probably be :input:usable:first, I can see where occasionally you might want to get all the input elements visible to the user.

Hope this helps someone!

Posted by Dan on Oct 15, 2009 @ 2:31 PM

Today I submitted the ColdFusion Enhancement Request #80336 to add better tools for preventing XSS attacks. More and more it's becoming common for developers to need to implement some type of WYSIWYG editor, but with that comes the increased risk of XSS attacks.

We've all heard about attacks on MySpace and other major sites and this is because it's actually a pretty difficult problem to solve correctly (since there are so many attack vectors.)

My suggestion would be for Adobe to integrate the OWASP AntiSamy project into ColdFusion. This is an excellent tool for cleaning up input to prevent XSS attacks and is highly configurable via XML.

If you're interested in solving this problem now, see my Using AntiSamy to protect your CFM pages from XSS hacks blog entry for details on implementing AntiSamy right now.

Posted by Dan on Oct 14, 2009 @ 2:46 PM

I'm working on some "star rating" code and I really wanted to round numbers of to the nearest fraction. While the math is really basic, my math skills are rusty and this took me longer to solve than I care to admit. So I thought I'd just blog the solution for anyone else that might find it useful:

round( value/fraction ) * fraction

Like I said, it's very basic math but is very handy when you want to round to something other than to the closest integer.

Posted by Dan on Sep 25, 2009 @ 8:55 AM

Today started off horribly. But before I get into today, I have to backtrack a bit.

While I haven't blogged about this yet (because it's still very early,) my wife is pregnant. Getting pregnant has been a long process for us and something our family and close friends have known about. Because so many people have known what we've been going through, we announced it to close friends and family a little sooner than we'd probably have liked.

Last Monday at 5am, Jenn woke me up and she had passed a clot. From the look of things, I was really afraid things were bleak. Jenn continued to spot all last week, so I was really worried that something went wrong w/the pregnancy. The doctor's didn't seem overly concerned and we just needed to wait out our appointment which was scheduled for today at 10a.

Needless to say, last week really sucked. We were trying to stay optimistic, but I was preparing for the worst.

At work we just released another jQuery plug-in called the iButton jQuery Plug-in (which brings the total of open source jQuery plug-ins we've released to four.) This plug-in allows you to generate iPhone-style buttons from checkbox and radio elements. While there are several libraries out there that generated iPhone-style buttons, we couldn't find one that did everything we needed, so I wrote one!

The users of our application are very keyboard centric, so it was very important that we supported keyboard entry. Keyboard support often seems to be overlooked in most UI plug-ins—developers get so focused on the mouse interaction, they forget completely about keyboard entry. So we always make keyboard support a key feature in the jQuery plug-ins we write.

Anyway, here's a list of the key features:

• Works with checkboxes or radio elements
• Full keyboard support — use the [TAB] key to move from field to field and use the spacebar to toggle the status of the iButton (or use the arrow keys for radio buttons)
• Custom event handlers
• Detach iButton behavior from the element
• Metadata support — when used with the jQuery Metadata Plug-in, you can define the properties for your button completely within the class attribute of your input elements
• Enable/disable drag support — while the dragging behavior is intuitive on touch-based devices, it's not always be the best or expected UI behavior and may cause some mouse users problems (NOTE: In order to help differentiate between an intended mouse click or an actual drag event, we're developed the clickOffset option. If the time (in milliseconds) is under this value (120ms by default) it's assumed the user was attempting to click the button and not drag the handle.)
• Enable/disable animation
• Single sprite image — easily change the look of your button by just replacing the image sprite
• Customizable labels — use any labels you want for your buttons
• Support for disabled buttons
• Easing support for animations
• iPhone support

You can see a demo of the plug-in on the Giva Labs - iButton Example Page.

We're pretty happy with the end result and are planning on using it in a few locations in our application. If you like plug-in, don't forget to Digg it!

Posted by Dan on Sep 3, 2009 @ 5:09 PM

Ever since upgrading to Windows Vista, I've had a probably with a program that I run infrequently where I'd get a message of "The Publisher Could Not Be Verified" and have to click on a box to verify I want to run the program. Since I don't use the application very frequently, the annoyance was minor.

Today I found myself needing to frequently re-load the application, so this message became really annoying. Windows Vista has an "Unblock" function in the file properties (right-click on the file from Windows Explorer and select "Properties"—it's on the general tab,) but this was not working for me.

I could click the "Unblock" button and apply the change, but the change wouldn't ever take. Since this program is my Program Files (x86) folder, I suspected this was the culprit. While I tried a few things to try to make the change as an admin (such as changing the file attributes—which forces you to grant admin privileges) the thing that end up working for me was to copy the files to another folder (like the desktop) go through the "Unblock" procedure again and then copy the files back to it's sub-folder in the Program Files (x86) folder. This seemed to do the trick.

So, while I'm sure there's a better way to get this to work, if you're getting the message "The Publisher Could Not Be Verified" every time you try to run a program and just using the "Unblock" function doesn't work, try moving the file to a folder that doesn't need administration privileges to modify the file.

Posted by Dan on Aug 18, 2009 @ 4:18 PM