закрытие окна после Response.End

Question

например. У меня есть форма с ListView, которая находится в режиме редактирования.
Что-то происходит, так что таблица, которую использует Listview, больше не доступна.
Я просто хочу иметь возможность закрыть окно, если пользователь нажимает «сохранить».

In Page_Load, я проверяю, доступна ли таблица, если нет, я звоню RegisterClientScriptBlock(type,name,"window.close()"). Однако обработка все еще происходит, и она переходит к L istView1_ItemUpdating event.

В Page_Load, если таблица не существует, я могу вызвать Response.End, чтобы остановить обработку, однако окно все еще остается, так как скрипт никогда не регистрировался.

Можно ли как-нибудь остановить обработку и закрыть окно, не устанавливая пользовательскую проверку IsTableValid() во всех моих методах?

Answer 1

Ответ, предоставленный Одедом, не работает с Page_Load, я не знаю почему. Ответ предоставлен эйч работает. Тем не менее, если вы не хотите сохранять дополнительный HTML-файл и выполнять перенаправление, вы можете использовать что-то вроде:

Response.Clear();
Response.Write("<script>window.close();</script>");
Response.Flush();
Response.End();

Answer 2

Flush ответ на отправку всех данных в браузер до его завершения:

RegisterClientScriptBlock(type,name,"window.close()")
Response.Flush()
Response.End()

Вы можете Clear ответ дорегистрация скрипта, чтобы убедиться, что в буфере ответа больше ничего нет.

Существуют также методы ClearHeaders и ClearContent, если вы хотите очистить только один, а не другой.

Answer 3

одно решение, kludgey, но может использоваться в другом месте:

Response.Redirect("close.html")

, где close.html просто имеет

  <script>
  window.close();
  </script>

Answer 4

Попробуйте вместо этого:

HttpContext.Current.ApplicationInstance.CompleteRequest();

Microsoft сами говорят , что Response.End существует только для обратной совместимости:

Этот метод предоставляется только для совместимость с ASP, то есть для совместимость с COM-интерфейсом Технология веб-программирования, которая предшествовал ASP.NET

Не уверен, что это решит вашу проблему, но по крайней мере у Microsoft не будет оправдания ..:)