2010-07-28 13 views
14

Tenemos un sitio web que ejecuta .NET Framework 2.0 con Ajax version 10618.RegularExpressionValidator VS Ajax 1.0.20229

Pero como es, esa es una versión anterior de la DLL, por lo que planeamos cambiarla a la versión "más nueva" para .NET Framework 2.0, AjaxControlToolkit version 20229.

En nuestras pruebas, detectamos un problema con el control ASP RegularExpressionValidator, que solía funcionar bien con la versión anterior.

Cuando la entrada al control de destino no coincide con la validación, el control muestra mi texto , que en este caso es un asterisco rojo dispuesto, como, en la fila siguiente, y muestra lo siguiente en el control : "-1.7976931348623157e+308".

No hay nada malo con la expresión porque como he dicho, que funciona bien con la versión anterior de Ajax, y no pude encontrar nada relacionado con RegularExpressionValidators y Ajax versiones.

PD: Tanto el validador como el control se encuentran dentro de un UpdatePanel.

PD 2: Con la versión anterior, pondría un 0 en el control y luego mostrarme el asterisco rojo justo al lado cuando la expresión no coincidiría.

Editar:

Aquí está el controlar de forma totalmente copiado:

<asp:RegularExpressionValidator ID="ValidateFooOrder" 
runat="server" ControlToValidate="txtFooNum"              
Text="*" ErrorMessage="Invalid Foo number" 
ValidationExpression="^\d{0,4}$" ValidationGroup="GenerateFooFile" /> 

y también tiene un NumericUpAndDownExtender unida a ella:

<ajaxToolkit:NumericUpDownExtender ID="NumericExtenderFooNum" 
runat="server" TargetControlID="txtFooNum"              
TargetButtonDownID="FooBack" TargetButtonUpID="FooForward" /> 
+0

Sé que esta es una pregunta anterior, pero si aún tiene problemas: ¿Puede publicar su código de diseñador? Sería interesante examinarlo y ver si esto es un cambio en la forma en que el control controla la expresión regular o cómo se escribe el javacript. – Peter

+0

@Patricker Ok, agregué el código. Lo siento, tomó mucho tiempo. – Smur

+0

Supongo que el problema todavía está sucediendo desde que actualizó su pregunta, ¿verdad? – Peter

Respuesta

-1

Mirando el mensaje de error, implica el número que se prueba está fuera de los límites de la expresión. Los únicos números permitidos están entre 0 y 9999. No se permiten letras, signos de puntuación u otros caracteres. La otra parte de la expresión afirma anclas alrededor del número, ya sea como principio y fin de una línea o palabra. El único otro valor permitido es NULL, que es probablemente donde la actualización es más estricta y da el error. Por ejemplo, ¿cómo se valida un número o dígito "\ d" que no existe (cero caracteres)?

+0

-1: entonces, ¿por qué cambió con la versión de AJAX? –

+0

Mi suposición (¿están permitidos?) Es que las versiones más nuevas de cualquier cosa corrigen errores. Tener una validación definida como un número, pero permitir que ese valor sea NULL es un error. La expresión regular correcta para validar un número de 1 a 4 dígitos es "^ \ d {1,4} $" no 0,4. –

+0

¿Es eso -1 porque no estoy de acuerdo con algo? Mi respuesta fue dirigida a que la expresión regular sea incorrecta, lo cual es incorrecto en cualquier idioma, no solo en AJAX. El -1 no está justificado y no está justificado. –

2

Ok, tengo el mismo problema y aquí están mis conclusiones:

En primer lugar es la fuente de -1.7976931348623157E+308. Es igual a la propiedad Minimum de AjaxControlToolkit.NumericUpDownBehavior que se llama en uno de los manipuladores de Sys.Application.init Event:

Sys.Application.add_init(function() { 
    $create(AjaxControlToolkit.NumericUpDownBehavior, {"Maximum":1.7976931348623157E+308,"Minimum":-1.7976931348623157E+308, /* other non relevant stuff */); 
}); 

Por lo tanto, no hay magia aquí, sólo un valor mínimo de Double. Minimum es la nueva propiedad que se compara con la versión 10618.

A continuación, ¿por qué se muestra tan pronto como se muestra la página? Esto sucede porque dentro de la función readValue que se define en AjaxControlToolkit.NumericUpDownBehavior.prototype se asigna un valor this._min (que es igual al parámetro Minimum desde $create) a la entrada si está vacío.readValue fuentes:

readValue : function() { 
     /// <summary> 
     /// Parse value of textbox and this._currentValue to be that value. 
     /// this._currentValue = this._min if some there is an exception 
     /// when attempting to parse. 
     /// Parse int or string element of RefValues 
     /// </summary> 

     if (this._elementTextBox) { 
      var v = this._elementTextBox.value; 
// The _currentValue of NumericUpDown is calculated here 
      // if textbox empty this._currentValue = this._min 
      if(!this._refValuesValue) { 
       if(!v) { 
        this._currentValue = this._min; 
       } else { 
        try { 
         this._currentValue = parseFloat(v); 
        } catch(ex) { 
         this._currentValue = this._min; 
        } 
       } 
       if(isNaN(this._currentValue)) { 
        this._currentValue = this._min; 
       } 
// And assigned here. In case of empty input we will get -1.7976931348623157E+308 if Minimum was not changed 
       this.setCurrentToTextBox(this._currentValue); 
       this._valuePrecision = this._computePrecision(this._currentValue); 
      } else { 
       if(!v) { 
        this._currentValue = 0; 
       } else { 
        var find = 0; 
        for (var i = 0; i < this._refValuesValue.length; i++) { 
         if (v.toLowerCase() == this._refValuesValue[i].toLowerCase()) { 
          find = i; 
         } 
        } 
        this._currentValue = find; 
       } 
       this.setCurrentToTextBox(this._refValuesValue[this._currentValue]); 
      } 
     } 
    } 

Antes Minimum, en la versión 10618, valor por defecto fue 0. Así que creo problema descrito podría ser resuelto mediante la especificación de Minimum valor de forma explícita en la declaración extensor:

<ajaxToolkit:NumericUpDownExtender ID="NumericExtenderFooNum" runat="server" 
    Minimum="0" 
    TargetControlID="txtFooNum" 
    TargetButtonDownID="FooBack" TargetButtonUpID 

Otra cosa que he encontrado es que change obras despacho de eventos equivocadas en las nuevas versiones de IE (para que funcione una Vista de compatibilidad debería estar habilitada, pero creo que esta no es una opción para sitios web públicos).

El problema está en la función setCurrentToTextBox. event objeto siempre es null en controladores (controladores de validación, por ejemplo) si se creó utilizando document.createEvent. Para solucionar este problema, la condición debe intercambiarse, por lo que todos los eventos en IE se crearán utilizando createEventObject.

// Current implementation of version 20229 
setCurrentToTextBox : function(value) { 
      // full sources are not shown, only if matters here 

      if (document.createEvent) { 
       // event is created using createEvent 
      } else if(document.createEventObject) { 
       // event is created using createEventObject 
      } 
     } 
    } 

// Updated implementation 
setCurrentToTextBox : function(value) { 
      // full sources are not shown, only if matters here 

      if (document.createEventObject) { 
       // event is created using createEventObject 
      } else if(document.createEvent) { 
       // event is created using createEvent 
      } 
     } 
    }