Using CFMX 6.1 I have about the same errormessage
<code>
Cannot invoke method setSessionStatus on an object of type coldfusion.runtime.Struct with named arguments.
</code>
but in a different situation.

It's kinda weird actually, if I use named arguments when I call an UDF that I rescoped to the request scope _and_ don't provide all (optional) arguments I get the error above. (i.e. request.udf.setSessionStatus( arg1 = 'something', arg3 = 'something else' );)
As far as I can tell it does work when you:

1. Provide all the arguments (even the optional ones).
2. Don't rescope them and use setSessionStatus( ... ) instead of request.udf.setSessionStatus( ... ).

I thought I'd post it for people searching on the errormessage.

PS. I do not know whether or not this works on CFMX 7.

@RC >>I've filed a bug and hopefully this will be corrected

Do yo know if it ever did? I'm using the exact scenario you describe above, UDFs in the request scope, on CF7, and this is bugging me greatly?

If it didn't get fixed, do you know of any not-too-painful workarounds?

I just tested w/ 8. Looks to be no. :( Of course, you can always use cfinvoke if you have complex argument naming patterns.

Thanks for checking Ray.

cfinvoke is unfortunately not an option, as this UDF is fired off inside a loop, and it's sometimes a whopping big loop :-)

NB. My original plan was to have a simple CFC, invoked in the application.cfm and persisted in the app scope, and call the function like "application.objCFCName.methodName()", but it turned out to be much slower than calling the function out of the request scope, which works like lightning! Any idea why?

Why is cfinvoke not an option? The size of the loop isn't really a concern.

Well...

Because I (stupidly) thought that cfinvoke would instatiate a new object every time. I just checked and of course I'm wrong there.

Still, to use cfinvoke, I still need to wrap my UDF in a CFC, in which case I may as well have reverted back to plan A and persisted the function in the app scope, where named arguments seem to be permissable. But I'm finding that doing this is slower than cfincluding the UDF.

I'd like to use the CFC, but performance is a real issue and the point of the exercise is to speed everything up as much as possible.

Nope, cfinvoke can call a UDF.

Oh, excellent! How do you refer to the UDF using the attributes of cfinvoke?

Just use method="X" where X is a udf on the page. Don't use component= at all.

I have a feeling I may have missed something here.

My original call to the UDF, using ordered args looks like this:
#request.udfs.encodeString(myStringVar, false, false)#

To do the same using named args, I would perhaps do something like this:
<cfset objArgs = structNew() />
<cfset objArgs.szHtmlIn = myStringVar />
<cfset objArgs.bNowrap = false />
<cfset objArgs.bCommasToBreaks = false />

<cfinvoke method="[X]" argumentcollection="#objArgs#" returnVariable="myReturnVariable" />#myReturnVariable#

But what goes in [X]? Trying "request.udfs.encodeString", "udfs.encodeString" or "encodeString" all result in a "Entity has incorrect type for being called as a function" error.

Copying the UDF back from request scope to variables scope before cfinvoking DOES work:
<cfset encodeString = request.udfs.encodeString />
<cfinvoke method="encodeString" ...
But does the UDF really have to be back in the vars scope?

Ah, I had not tried a UDF in a different scope. I guess you would need to do the copy. It is a copy by reference though so there is no real impact on memory/performance.

Ah, that all makes sense now!

Thanks for taking the time to go through that for me. Sometimes I feel with CF the more I learn the less I know...