2011-06-30 24 views
16

Estoy tratando de activar una ventana emergente como se muestra a continuación, pero no está funcionando. Por favor, ayudaUso de Page.ClientScript.RegisterClientScriptBlock no funciona

public void btnSubmit_Click(Object o, EventArgs e) 
{ 
    if (checkFileExists(Convert.ToString(fileInfo))) 
    { 
     Page.ClientScript.RegisterClientScriptBlock(this.GetType(), "Msg", "<script type=\"text/javascript\" language=\"javascript\">function showMsg(){return confirm(\"This image name already exists, do you want to replace it?\");}</script>", true); 
     btnSubmit.OnClientClick = "return showMsg()"; 
    } 
    if (something else) 
    { 
     // It does whatever is here but never pops the question above 
    } 
} 

y en el botón Tengo

<asp:Button class="Button" ID="btnSubmit" CausesValidation="True" Text="SUBMIT" runat="server" 
      OnClick="btnSubmit_Click"></asp:Button> 
+0

En mi caso no estaba funcionando debido a que el prototipo de función en mi guión era malo perder el '(arg, context)' de la firma de la función. Espero que ayude a alguien. –

Respuesta

17

El último parámetro que va a enviar a RegisterClientScriptBlock es true, que le dice al método de envolver su escritura en un bloque <script>, pero' ya estás haciendo eso. Probablemente no funcione, porque está generando etiquetas de scripts inválidas (es decir, anidadas).

+0

Lo cambié a falso, pero todavía lo ignora, no aparece. Incluso saqué la condición if para forzarlo a que se ejecute, pero nada, simplemente continúa con "Enviar" y termina ... nunca se dispara el btnSubmit.OnClientClick = "return ShoeMsg()"; – user710502

+0

Cuando ve el origen de su página, ¿ve el bloque '

5

ACTUALIZACIÓN DE RESPUESTA (en respuesta a los comentarios de OP)

El conjunto "¿está seguro de" paradigma puede ser un poco molesto para implementar en ASP.NET. Aquí hay un enfoque que he usado para abordarlo. Estoy seguro de que hay muchas otras maneras de lograr esto, algunas de las cuales son más elegantes. Pero de todos modos ...

  • Ponga un asp: campo oculto en su formulario, para indicar "el usuario está seguro". Establezca su valor predeterminado en falso.
  • Defina su función javascript showMsg() directamente en el archivo .ASPX. Siempre puede estar en la página, listo para disparar; no desea o necesita agregarlo condicionalmente a través de RegisterClientScript. También deberá mejorar esa función para hacer 2 cosas si el usuario confirma "sí, estoy seguro": a) configure su asp: valor del campo oculto en verdadero; b) envíe el formulario.
  • Implemente su función btnSubmit_Click() para verificar el asp: Valor oculto: si ese valor es verdadero, usted sabe que el usuario ya ha confirmado el diálogo "¿está seguro?", Entonces puede hacer su operación (y el valor oculto vuelve a falso para "restablecerlo"). Si el valor de asp: oculto es falso, active RegisterClientScript para llamar (no definir, pero realmente llamar) su función showMsg().
  • Implementar Page_LoadComplete para comprobar el valor oculto: si es verdad, mediante programación llamar btnSubmitClick()

Con los cambios anteriores hechos, su página debe comportarse así:

  1. clics usuario se someten, publicaciones de la página de vuelta.
  2. btnSubmit_Click se ejecuta, ve el campo oculto es falso y establece RegisterClientScript para llamar a showMsg().
  3. Page_LoadComplete ve que el campo oculto es falso, por lo que no hace nada. La postback se completa y la página se envía de vuelta al navegador.
  4. La página de análisis del navegador, llega a showMsg() y la ejecuta. Esto abre el cuadro de diálogo seguro.
  5. El usuario hace clic en "sí" en el cuadro de diálogo seguro. Su función showMsg actualizada detecta esto, establece el campo oculto como verdadero y envía el formulario. Página posts-back.
  6. Debido a que el formulario fue enviado hacia atrás pero no se hizo clic en el botón de enviar, su función btnSubmit_Click NO se llama aquí.
  7. Page_LoadComplete ve que el campo oculto es verdadero, por lo que llama a la función btnSubmit_Click.
  8. btnSubmit_Click ve que el campo oculto es verdadero y realiza la operación real.

El enfoque anterior es definitivamente torpe. Si está dispuesto a utilizar ajax para tomar una decisión, ya sea que "¿está seguro?" Es necesario, puede pasar mucho más de esta lógica al lado del cliente y ahorrarse una operación de devolución de datos.

Sin embargo, con mano dura o no, el enfoque anterior funcionará, y dará como resultado un código relativamente fácil de mantener, siempre y cuando haga algunos buenos comentarios.

respuesta original:

como está escrito actualmente, showmsg() no se llamará hasta la segunda vez que el usuario hace clic en el botón Enviar:

  1. botón se vuelve sin valor OnClientClick.
  2. El usuario hace clic en el botón enviar; página posts-back.
  3. El controlador de eventos pone la definición de "función showMsg()" en la página (registerClientScript); también agrega un atributo OnClientClick al botón. La post-impresión se completa y la página se vuelve a dibujar en el navegador.
  4. En este momento, nadie ha llamado a showMsg().
  5. El usuario hace clic en el botón Enviar.
  6. Dado que el botón ahora tiene un valor OnClientClick, esta vez debe llamar a showMsg.

Otras cosas a considerar:

Usted tiene el javascript definición de la función real en su RegisterClientScript. ¿Por qué no simplemente definirlo en la página (en el archivo .aspx)? No va a doler nada tener siempre allí. No se dispara hasta que realmente se llama.

No estoy familiarizado con la notación de doble paternidad que está utilizando: "GetType()()" - si no está causando un error de compilación o no está lanzando, puede ser irrelevante.

Familiarícese definitivamente con Firebug y/o Fiddler, para que pueda ver exactamente qué HTML procesado se envía de vuelta al navegador. Hará que su depuración de desarrollo web MUCHO más fácil.

+0

GetType()() es un error tipográfico cuando publiqué aquí. Lo tenía con un OnClientClick en .aspx, pero me daría un error de JScript Object Expected, y me imaginé que era porque no podía encontrar el método ... parece que primero va para el Javascript y luego el código C# .. el problema es que primero tengo que evaluar algunas cosas en C# para decidir si activar o no el javascript ... No sé qué hacer :( – user710502

+0

Edité mi respuesta para darle más detalles y un posible enfoque No estoy diciendo que sea el mejor enfoque, pero está a solo unos pasos de lo que ha estado haciendo hasta ahora. – mikemanne

1

Entiendo su problema y le sugiero que haga lo siguiente.

1- mantener su btSubmit pero en su

public void btnSubmit_Click(Object o, EventArgs e) 
{ 
    if (checkFileExists(Convert.ToString(fileInfo))) 
    { 
     Page.ClientScript.RegisterClientScriptBlock(this.GetType(), "Msg", "<script type=\"text/javascript\" language=\"javascript\">function showMsg(){return confirm(\"This image name already exists, do you want to replace it?\");}</script>", true); 
     btnSubmit.OnClientClick = "return showMsg()"; 
    }  
} 

borrar el caso (algo más).

2- Utilice Dialog para crear un cuadro de diálogo similar a una confirmación de JavaScript pero con un botón asp.net con su propio evento de clic.

3- cambio de su

return confirm(\"This image name already exists, do you want to replace it?\"); 

en el RegisterClientScriptBlock de su primer evento con la lógica del cuadro de diálogo de jQuery.

4- En el nuevo evento de su nuevo botón añadir su lógica extra:

if (something else) 
{ 
    // you´ll know the user click your confirm button already!!! 
} 

espero que esto le ayuda.

+0

Una cosa para recordar con el diálogo jQuery: cuando inicializa el diálogo, jQuery renderiza las nuevas etiquetas al final del DOM. Esto está fuera de las etiquetas

. Eso significa que cualquier ASP: Los elementos de campo (o similares) contenidos en el cuadro de diálogo NO tendrán sus valores reflejados de nuevo en el estado de visualización. Esto probablemente no sea así. t m Atter para un botón enviar, pero perdí muchas horas un día tratando de averiguar por qué el texto en mi asp: campo en mi diálogo nunca estuvo en el estado de visualización en la devolución de datos! :) – mikemanne

+0

Volví a subir esta respuesta porque me gusta el enfoque de 2 botones diferentes mejor que el enfoque de campo oculto que describí en mi respuesta. – mikemanne

+0

Este análisis SO muestra una manera excelente de asegurarse de que los elementos jQueryUI (al menos los cuadros de diálogo) se procesen dentro de las etiquetas FORM, así que los botones enviar y los valores de datos habilitados para ViewState funcionan correctamente: http: // stackoverflow.com/questions/757232/jquery-ui-dialog-with-asp-net-button-postback – mikemanne

0

FishBasketGordo ¡gracias por señalar la diferencia! Fue una gran ayuda!

Page.ClientScript.RegisterClientScriptBlock no se activó hasta que realicé el cambio que señaló, es decir, eliminé las etiquetas y agregué "verdadero" como el cuarto parámetro. Puede ser una buena idea comprobar que ningún otro bloque de script revierte los cambios efectuados por el que no está activando y que el bloque de script tiene un nombre único.

29

Otro motivo por el que Page.ClientScript.RegisterClientScriptBlock no funciona es cuando la página no tiene un formulario del lado del servidor, p. <form id="form1" runat="server">... </form>

+1

Al agregar una etiqueta de formulario, resuelve mi problema. –

-1

que tenían el mismo problema esta mañana y sólo funcionaba de esta manera:

Response.Write("<script type='text/javascript'>alert('" + AlerteMsg + "');</script>"); 

en su caso, usted puede escribir lo que usted quiere JavaScript!

-1

que tenían el mismo problema esta mañana y sólo funcionaba de esta manera:

Response.Write ("alert ('" + AlerteMsg + "');");

¡En su caso puede escribir lo que javascript quiera!

desde arriba código .. ahora tengo que presionar 2 veces la espalda button..then se remonta .. cualquier solución