Hi Trevor,

I'm not really much of an authority on the WebControls, so hopefully someone else will chime in here (you might consider starting another thread if this doesn't happen).

I looked at the HTTP requests to see what was going on, and the ClientAPI is looking for a control with name MyDNNTextSuggest and clientId "dnn_ctr2885_ViewTaxiRouteSearchDemo_ViewTaxiRouteSearchDemo_MyDNNTextSuggest".  A non-ClientAPI request to the page does indicate that the control is being instantiated.  The 404 result code is indicating that the Globals.FindControlRecursive call in DotNetNuke.WebUtilities (not the one in DotNetNuke.Common.Globals) is failing for some reason.

If I were in your shoes, I would attach a debugger and investigate why the DotNetNuke.WebUtilities.Globals.FindControlRecursive call is failing.  Are you mucking with the IDs in any way during postback? 

Also, please at a minimum use PortalSecurity.InputFilter(strText, FilterFlag.NoSQL) on your SQL statement construction.  You are at risk for an injection attack here.  I would advise against ad-hoc query construction in this manner entirely.

Hope this helps!

Brandon

Hi Both,

Thanks for the feedback.

Im really not doind anything that clever here. *I think*

I have not messed with any ids and I am not adding the DNNTextSuggest module dynamically.

I get the feeling this might be a DNN problem.

Im at a loss what to do now really.

Should i try that CallbackType anyway?

Trev

Mr. Henning is THE ClientAPI guy, so he's the one you'll want to listen to in resolving this issue.

That said, until he is able to assist further, do you have a development environment where you can reproduce the issue?  My previous comment stands -- it is likely that the DotNetNuke.WebUtilities.Globals.FindControlRecrusive method is failing, either because of an issue on  your end or with the ClientAPI itself.  If you can attach a debugger and investigate why this is occurring, you'll be that much closer to resolving which of the two cases is in play here.

Brandon