J
jerc
Howdy:
I'm building a very simple web application and have noticed extremely odd
behavior associated with the Ajax:AutoCompleteExtender. I'm using a
asp:wizard and on step N of the wizard I have a few textboxes which I've
extended with the AutoCompleteExtender from AJAX.
One textbox, in particular, is for a user to enter a lot number. This lot
number can contain any number of special characters (for exampe, a lot might
be 2008-01, representing the first lot in the year 2008).
The problem I've run into is the data being rendered at the client by the
AutoCompleteExtender is not the data that resides in the database, nor the
data being returned by the web service the AutoCompleteExtender consumes.
It's a bit of a conundrum. I noticed the lot numbers being "suggested" were
not familiar, so I did quick query in the database on the LOT column in table
X. Several of the "suggested" items did not even exist. Quite odd... and I
started to wonder where could this non-existent data possibly be coming from.
I placed a breakpoint in the web service being consumed by the
AutoCompleteExtender.
Here's the code for the web service:
[WebMethod]
[ScriptMethod]
public string[] AutoCompleteLotNumber(string prefixText, int count)
{
List<string> items = new List<string>();
IDBManager dbManager = new DBManager(DataProvider.SqlServer);
dbManager.ConnectionString =
ConfigurationSettings.AppSettings["ConnectionString"].ToString();
dbManager.Open();
dbManager.CreateParameters(2);
dbManager.AddParameters(0, "@LOTNUMBER", prefixText);
dbManager.AddParameters(1, "@ROWCOUNT", count);
dbManager.ExecuteReader(CommandType.StoredProcedure, "acLotNumber");
while (dbManager.DataReader.Read())
items.Add(dbManager.DataReader["LOTNUMBER"].ToString());
dbManager.Dispose();
return items.ToArray();
}
I placed the brake point at the end so I could do a quick watch on the items
array. Low-and-behold, the items array contained the correct data for the
lot numbers. So, somewhere between the web service and the client the data
is being altered.
The quick watch revealed the following items in the array:
items (count = 15)
...
[6] "10827-0029"
[7] "1090000329731"
[8] "109396/1.1"
[9] "109748/1.1"
[10] "1111"
[11] "11112"
...
Note the dash in item 6, and the slashes in items 8 and 9.
Now, when the AutoCompleteExtender renders at the client, I receive the
following in the "suggested" items drop down list (these items correpond to
the items in the array above):
....
10798
1090000329731
99450.90909090909
99770.90909090909
111
11112
....
It doesn't take a mathematical genius to realize what's happening. The dash
and slash is being interpreted as subtraction and division, respectively, and
the result is what's being displayed at the client.
Looks like a bug to me, or maybe I'm doing something completely wrong. Does
anyone have any idea how to go about fixing this? I'm returning a string
array from the web service, not that it means anything to javascript, so I'm
not sure what else I could do to prevent this calculation from taking place.
Any suggestions would be most appreciated!
-Jeremy
I'm building a very simple web application and have noticed extremely odd
behavior associated with the Ajax:AutoCompleteExtender. I'm using a
asp:wizard and on step N of the wizard I have a few textboxes which I've
extended with the AutoCompleteExtender from AJAX.
One textbox, in particular, is for a user to enter a lot number. This lot
number can contain any number of special characters (for exampe, a lot might
be 2008-01, representing the first lot in the year 2008).
The problem I've run into is the data being rendered at the client by the
AutoCompleteExtender is not the data that resides in the database, nor the
data being returned by the web service the AutoCompleteExtender consumes.
It's a bit of a conundrum. I noticed the lot numbers being "suggested" were
not familiar, so I did quick query in the database on the LOT column in table
X. Several of the "suggested" items did not even exist. Quite odd... and I
started to wonder where could this non-existent data possibly be coming from.
I placed a breakpoint in the web service being consumed by the
AutoCompleteExtender.
Here's the code for the web service:
[WebMethod]
[ScriptMethod]
public string[] AutoCompleteLotNumber(string prefixText, int count)
{
List<string> items = new List<string>();
IDBManager dbManager = new DBManager(DataProvider.SqlServer);
dbManager.ConnectionString =
ConfigurationSettings.AppSettings["ConnectionString"].ToString();
dbManager.Open();
dbManager.CreateParameters(2);
dbManager.AddParameters(0, "@LOTNUMBER", prefixText);
dbManager.AddParameters(1, "@ROWCOUNT", count);
dbManager.ExecuteReader(CommandType.StoredProcedure, "acLotNumber");
while (dbManager.DataReader.Read())
items.Add(dbManager.DataReader["LOTNUMBER"].ToString());
dbManager.Dispose();
return items.ToArray();
}
I placed the brake point at the end so I could do a quick watch on the items
array. Low-and-behold, the items array contained the correct data for the
lot numbers. So, somewhere between the web service and the client the data
is being altered.
The quick watch revealed the following items in the array:
items (count = 15)
...
[6] "10827-0029"
[7] "1090000329731"
[8] "109396/1.1"
[9] "109748/1.1"
[10] "1111"
[11] "11112"
...
Note the dash in item 6, and the slashes in items 8 and 9.
Now, when the AutoCompleteExtender renders at the client, I receive the
following in the "suggested" items drop down list (these items correpond to
the items in the array above):
....
10798
1090000329731
99450.90909090909
99770.90909090909
111
11112
....
It doesn't take a mathematical genius to realize what's happening. The dash
and slash is being interpreted as subtraction and division, respectively, and
the result is what's being displayed at the client.
Looks like a bug to me, or maybe I'm doing something completely wrong. Does
anyone have any idea how to go about fixing this? I'm returning a string
array from the web service, not that it means anything to javascript, so I'm
not sure what else I could do to prevent this calculation from taking place.
Any suggestions would be most appreciated!
-Jeremy