NOTE: It looks like this problem may only affect Coldfusion and Java.

Protx have just switched over to the new SagePay URL's today on LIVE and unfortunately the old URL's have broken. This was not supposed to happen and the old URL's should have continued for the forseeable future.

SagePay are telling developers to update all sites to the new URL system.

I can't imagine how many orders are being lost this morning.

Get your URL's updated ASAP, full details here:

https://support.sagepay.com/forum/Topic8090-22-1.aspx

I wondered why when I tried to test my Protx VSPServer integration today that it just wouldn't work. I kept getting this SSL problem when submitting the HTTP POST:

I assumed this was a temporary issue but have just found out that ProtX is rebranding to SagePay and you need to use the following domain for TEST and SIM:

http://test.sagepay.com

There is also a new path for each operation so check out the table posted on the ProtX support forums:

https://support.sagepay.com/forum/Topic8090-22-1.aspx

I just came across an annoying problem when trying to upgrade MS SQL 2005 my development server to SP3. Whatever I did it would fail on the first step of the process - "Setup Support Files". Here's the lines from the log file the patch created:

This is the core error here:

MSP Error: 1304  Error writing to file: Microsoft.NetEnterpriseServers.ExceptionMessageBox.dll.  Verify that you have access to that directory.

I did a lot of searching but just couldn't find out what could be causing this or how to fix it.

I eventually discovered that the problem was down to the version of .NET I had installed. I *think* I was running the old V1.1 of the .NET assemblies as I had to downgrade to get something running on an ASP website.

Anyway, I installed the latest version of .NET - V3.5 and restarted the SP3 install and it went through without problem.

It's annoying that on the download page for SP3 there is no mention that you need an updated version of .NET installed or that that patch doesn't even tell you! Another Microsoft oversight that has wasted a few hours of my life!

I am assuming this would have worked fine if I had upgraded to V2 of .NET as well.

You can get the latest .NET installer from here

I just spent a little time wrestling with an annoying JQuery error when trying to select a form element by name.

I was using the following code to simply grab the contents of a hidden field named 'required':

I got this syntax from a quick google search and found it referenced on a number of web guides about JQuery.

However, when I used it I got the following error in Firefox:

Well after some head scratching and then some more searching I found the answer. The @ syntax is no longer supported in JQuery 1.3+.

So the simple fix is to just remove the @ and it'll work as expected:

Hopefully this will help someone who, like me, hit's Google when looking for a quick fix to a problem.. :)

I've just come across a problem when installing the Microsoft Script Debugger in IE7 on Vista.
It installs fine, but as soon as I restart IE the browser hangs. I then had to kill the IE task.

At this point an 'Internet Explorer Security' error popup appeared:

I then clicked 'Allow'. However, upon restarting IE it hung again.

Very frustrating until I realised the simple solution. All you have to do is run the browser, let it hang and then kill it. When the above popup appears, tick the box which says 'Do not show me the warning for this program again' and then click 'Allow'.

Now, when you start IE it will start fine without the hang and debugging working perfectly.

Annoying that this is the way to get it to work but at least there is a workaround.

I am running Vista x64 Ultimate for what it's worth.

By the way, if you do any development with IE 7 and Javascript you NEED 'My Debug Bar' - www.my-debugbar.com. It add's a FireBug type debug interface to IE which lets you debug Javascript without the need to drop into the awful Microsoft Visual Debugger thing. The same guy also develops DebugBar which is also a fantastic piece of kit for adding comprehensive debugging to IE.

Just a quick gotcha that caught me out for hours while using CFAjaxProxy in a messaging application I'm currently building.

When using CFAjaxProxy in asyncronous mode and setting a callback handler (setCallBackHandler(function)), be aware that this then becomes the callback handler for ALL subsequent calls. This is very important when building a complex Ajax application.

Basically when the user sends a message, I set a callback handler which then dynamically reloads the lists of past messages in the thread without leaving the message page.

Outside of this I have a global 30 second poll function which also uses CJAjaxProxy to obtain various user data (to alert of new messages etc). What I couldnt understand was that every 30 seconds the message list on this page would reload all by itself.. Spooky.. I searched my code looking for a call to my reloadThreadMessage() function but couldn't find one, outside of the send message function..

After much head scratching and shouting I finally realised that what was happening is every 30 seconds when the global poll was run, the CFAjaxProxy call to get the global data was still using the callback handler that was set when I sent the earlier message!

To fix this I simply place a call to setSyncMode() before the global data call and this removes the callback handler routine.

Something to bear in mind if your seeing weirdness while making multiple CFAjaxProxy calls in asyncronous mode..

I just discovered a problem while attempting to use Brian Rinaldi's excellent Illudium PU36 Code Generator on my development server. It would load up but then after entering my Coldfusion administrator password it would just hang. It always used to work so I realised that something must have changed on my server.

Upon monitoring the HTTP requests going to the server I noticed that the first request to /flex2gateway/ on the server was hanging. The response header was received, but then it was waiting for the response body that never seemed to arrive.

After some head scratching I realised that I had implemented gzip http header / body compression on my development server (a filter for the JRun server). As soon as I removed this the code generator started working perfectly.

This is almost 100% a problem that will affect most Flex apps, so it's something to look out for if you have any issues with hangs when trying to use Flex.

Disclaimer: As I have only used one Flex application I have not been able to test the above assertion. If you know of Flex apps that work with the http compression filter I'm using, please let me know.

 

The compression filter I am using is GZIP2WayFilter by Thomas Bayer. Apart from the issue with Flex this works very well indeed with compression of CFM templates to crazy sizes.

Right, well I've been having lots of fun playing with the new super-duper CFWINDOW tag in CF8. What this lovely tag does is it allows you to quickly create impressive lookng web 2.0 style windows. The coolest feature of the tag is the ability to set a window as 'modal'. This makes the window one of those where the background of the page is greyed out with only the window being usable.. Very neat for login panel's etc. I'm making extensive use of this technology on the big project I'm currently working on.

Anyway, I became aware of an annoying problem today where the actual contents of the CFWINDOW was appearing at the top of the page while it was loading. Once loading was complete the content would dissapear as the Ajax goodness kicked in to hide it.. Well obviously on a production site this is simply not workable - we can't have our vistors seeing ugly text at the top of the design only to watch it vanish when the page is fully rendered.

Well anyway after an inspired moment about 10 minutes ago I realised that the key was to make sure the generated <div>'s tags that CFWINDOW creates to hold the window contents are set to render off screen. The fix is the incredibly complex piece of CSS ( :) ) that you need to add to your stylesheet:

You may need to play with the left offset if your CFWINDOW dimensions are quite wide.

This works a treat and ensures that all your CFWINDOW pages are loaded properly.

Just a quick CF8 gotcha that can cause annoying problems if you aren't aware of it.

Basically, if your doing any AJAX in CF8 and using the returnFormat="json" functionality to get a CFC (with access="remote") to return data to Javascript on the frontend, remember this:

ColdFusion internally represents structure key names using all-uppercase characters

So what this basically means is that no matter how you specify your structure data in Coldfusion (e.g params.userName = "james"), when it arrives on the frontend via Javascript you MUST use UPPERCASE variable names.

E.G alert(proxy.USERNAME);

Just something to watch out for as it can catch you out..

I've just been playing with the incredible <cfajaxproxy> tag in CF8 and have come across what appears to be a bug in Coldfusion when using application.cfc and calling CFC's via the URL method.

The URL method allows you to call CFC's via a URL and access any method in the CFC which has access="remote" set. Coldfusion will take care of returning the data as WDDX encoded or in JSON if using Coldfusion 8.

Anyway, I was testing this earlier today and found that no matter what I did, when calling a method in a CFC using the URL method a blank page was returned. It was incredibly frustrating!

A quick trip to the excellent #coldfusion IRC channel on Dalnet gave me the answer though (thanks Hapex) - application.cfc.

Well more specifically the onRequest method in application.cfc! For some reason if this method is defined in the file, remote CFC calls will simply display a blank page.

The solution? Comment out onRequest if you aren't making use of it. If you are, simply create an application.cfm and place it in the folder with your remotely accessed CFC's.

I believe this has been submitted to Adobe as a bug.. Hopefully it'll get fixed in the next release.