... но нужно оставаться на текущей странице.
Может можно этого добиться как-то средствами .Net.
Пробовал через iframe, но там

Автор: somesoul
Дата: 30.08.10

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

З.Ы. заставлять пользователя использовать "Save linked content as ..." как и открывать ссылку в новой вкладке тоже не хочется.

Здравствуйте, somesoul, Вы писали:

S>... но нужно оставаться на текущей странице.
S>Может можно этого добиться как-то средствами .Net.
S>Пробовал через iframe, но там

Автор: somesoul
Дата: 30.08.10

не могу отловить момент закрытия диалога сохранения файла.
S>В принципе мелочь, но хотелось бы на него реагировать для большей usability.
S>Хочется немного обновлять страницу перед и после загрузки файла.
S>Возможно есть варианты как реализовать функционал без фрейма.

S>З.Ы. заставлять пользователя использовать "Save linked content as ..." как и открывать ссылку в новой вкладке тоже не хочется.

Если использовать заголовок attachment, то браузер обычно не меняет страницу.

Здравствуйте, gandjustas, Вы писали:
G>Если использовать заголовок attachment, то браузер обычно не меняет страницу.

Я так и делаю в странице которая возвращает контент файла.
Проблема в том что я не могу контролировать процесс загрузки iframe-а/файла.
Вы предлагаете не использовать доп страницу?
Я пока не вижу как это поможет.

Здравствуйте, somesoul, Вы писали:

S>Я так и делаю в странице которая возвращает контент файла.
S>Проблема в том что я не могу контролировать процесс загрузки iframe-а/файла.

Потенциально сервер знает "сколько скачал пользователь" на данный момент (сделать свой HttpHandler для скачивания файла). Дальше, с основной страницы слать запросы о текущем прогрессе на сервер.

Здравствуйте, TK, Вы писали:

S>>Я так и делаю в странице которая возвращает контент файла.
S>>Проблема в том что я не могу контролировать процесс загрузки iframe-а/файла.

TK>Потенциально сервер знает "сколько скачал пользователь" на данный момент (сделать свой HttpHandler для скачивания файла).

Это если нет прокси.

Здравствуйте, Lloyd, Вы писали:

S>>>Я так и делаю в странице которая возвращает контент файла.
S>>>Проблема в том что я не могу контролировать процесс загрузки iframe-а/файла.

TK>>Потенциально сервер знает "сколько скачал пользователь" на данный момент (сделать свой HttpHandler для скачивания файла).
L>Это если нет прокси.

Ну, хоть что-то

Здравствуйте, TK, Вы писали:
S>>Я так и делаю в странице которая возвращает контент файла.
S>>Проблема в том что я не могу контролировать процесс загрузки iframe-а/файла.
TK>Потенциально сервер знает "сколько скачал пользователь" на данный момент (сделать свой HttpHandler для скачивания файла). Дальше, с основной страницы слать запросы о текущем прогрессе на сервер.

Мне не нужен прогресс бар. Браузер отлично справляется с этой задачей.
Но пока файл генерируется на сервере хочется написать что-то типа
"Подождите, идет генерация файла" и спрятать кнопочки вызывающие его генерацию.
А когда пользователь закрыл диалог сохранения файла хочется убрать сообщение и вернуть кнопку на место.
Пока это делает JS по таймеру, а мне это не нравится. И не хочется какое-то хлопотное решение применять.
Заставлять клиент опрашивать сервер по таймеру на предмет "не готово ли" кажется уж слишком "overkill" решением.

P.S.
Кстати Devexp тоже элегантно решает эту проблему
Похоже что даже без фрейма, но чтобы разобраться надо глубоко копать.

Здравствуйте, somesoul, Вы писали:

S>Кстати Devexp тоже элегантно решает эту проблему

Не рещает. Прямо сейчас открыл два окошка скачки файла.

Здравствуйте, somesoul, Вы писали:

S>"Подождите, идет генерация файла" и спрятать кнопочки вызывающие его генерацию.
S>А когда пользователь закрыл диалог сохранения файла хочется убрать сообщение и вернуть кнопку на место.

Когда пользователь закрывает диалог сохранения файла сам файл уже обычно скачан (или качается) и лежит в кеше.

S>P.S.
S>Кстати Devexp тоже элегантно решает эту проблему
S>Похоже что даже без фрейма, но чтобы разобраться надо глубоко копать.

А что именно там делается? Можно нажать на кнопку "Export To..." и это не приведет как каким либо изменениям в UI. До момента появления диалога с сохранением UI продолжает работать как и раньше.

Вам уже предложили делать опрос сервера, и это хороший способ. В момент начала генерирования файла кладёте в кеш какое-то значение с ключом, однозначно идентифицирующим файл, по окончании работы удаляете его из кеша.

Опыт показывает, что браузер выполняет аяксные запросы последовательно, поэтому если сначала натравить iframe на нужный адрес, а потом начать опрос аяксными вызовами, то самый первый такой вызов поступит на сервер уже после того, как генерирование файла закончится. В результате сколько бы ни заняло времени генерирование файла, опросить потребуется только один раз.

Здравствуйте, Lloyd, Вы писали:
S>>Кстати Devexp тоже элегантно решает эту проблему
L>Не рещает. Прямо сейчас открыл два окошка скачки файла.
Хмм. По крайней мере они ловят момент закрытия окна сохранения файла, что для меня важно.

Здравствуйте, TK, Вы писали:
S>>"Подождите, идет генерация файла" и спрятать кнопочки вызывающие его генерацию.
S>>А когда пользователь закрыл диалог сохранения файла хочется убрать сообщение и вернуть кнопку на место.
TK>Когда пользователь закрывает диалог сохранения файла сам файл уже обычно скачан (или качается) и лежит в кеше.
Важно отловить момент когда закончена генерация файла и началось его скачивание
(Событие закрытие окошка выбрано как очевидно используемое в уже работающих решениях)

S>>P.S.
S>>Кстати Devexp тоже элегантно решает эту проблему
S>>Похоже что даже без фрейма, но чтобы разобраться надо глубоко копать.

TK>А что именно там делается? Можно нажать на кнопку "Export To..." и это не приведет как каким либо изменениям в UI. До момента появления диалога с сохранением UI продолжает работать как и раньше.
курсор меняется на wait. когда начинается непосредственно скачка блокируется контент и появляется "save as ..." по закрытии которого форма возвращается в нормальное состояние.
Нужна визуализация процесса генерации для пользователя т.к. из-за особенностей дизайна базы генерация может занят заметное время.

Здравствуйте, somesoul, Вы писали:

S>>>"Подождите, идет генерация файла" и спрятать кнопочки вызывающие его генерацию.
S>>>А когда пользователь закрыл диалог сохранения файла хочется убрать сообщение и вернуть кнопку на место.
TK>>Когда пользователь закрывает диалог сохранения файла сам файл уже обычно скачан (или качается) и лежит в кеше.
S>Важно отловить момент когда закончена генерация файла и началось его скачивание
S>(Событие закрытие окошка выбрано как очевидно используемое в уже работающих решениях)

Сделайте это через отдельный фрейм (либо без фрейма — не столь важно). При запросе на генерацию отчета блокируется UI на странице. По завершении генерации сервер сбрасывает на клиента страницу со скриптом (либо клиент сам переодически опрашивает сервер на предмет завершения генерации и адреса для скачивания отчета) для разблокировки UI и адресом для скачивания готового отчета.

TK>>А что именно там делается? Можно нажать на кнопку "Export To..." и это не приведет как каким либо изменениям в UI. До момента появления диалога с сохранением UI продолжает работать как и раньше.
S>курсор меняется на wait. когда начинается непосредственно скачка блокируется контент и появляется "save as ..." по закрытии которого форма возвращается в нормальное состояние.
S>Нужна визуализация процесса генерации для пользователя т.к. из-за особенностей дизайна базы генерация может занят заметное время.

Если честно, то ничего похожего на это я там не заметил. Видел эффект аналогичный описанному Lloyd. Это говорит как минимум о том, что никакой UI не блокируется.

Здравствуйте, TK, Вы писали:
S>>>>"Подождите, идет генерация файла" и спрятать кнопочки вызывающие его генерацию.
S>>>>А когда пользователь закрыл диалог сохранения файла хочется убрать сообщение и вернуть кнопку на место.
TK>>>Когда пользователь закрывает диалог сохранения файла сам файл уже обычно скачан (или качается) и лежит в кеше.
S>>Важно отловить момент когда закончена генерация файла и началось его скачивание
S>>(Событие закрытие окошка выбрано как очевидно используемое в уже работающих решениях)
TK>Сделайте это через отдельный фрейм (либо без фрейма — не столь важно). При запросе на генерацию отчета блокируется UI на странице. По завершении генерации сервер сбрасывает на клиента страницу со скриптом (либо клиент сам переодически опрашивает сервер на предмет завершения генерации и адреса для скачивания отчета) для разблокировки UI и адресом для скачивания готового отчета.
Я уже писал, что и так сделано через iframe. Также я писал что не хочу опрашивать клиентом сервер по таймеру.
Момент "завершения генерации" мы и обсуждаем: его отловить не удается, хотя умные люди как-то ухитряются это сделать.

TK>>>А что именно там делается? Можно нажать на кнопку "Export To..." и это не приведет как каким либо изменениям в UI. До момента появления диалога с сохранением UI продолжает работать как и раньше.
S>>курсор меняется на wait. когда начинается непосредственно скачка блокируется контент и появляется "save as ..." по закрытии которого форма возвращается в нормальное состояние.
S>>Нужна визуализация процесса генерации для пользователя т.к. из-за особенностей дизайна базы генерация может занят заметное время.
TK>Если честно, то ничего похожего на это я там не заметил. Видел эффект аналогичный описанному Lloyd. Это говорит как минимум о том, что никакой UI не блокируется.
До конца генерации контента файла они изменяют курсор, но не блокируют форму. Форма блокируется одновременно с появлением диалога.
Это приемлемое решение, т.к пользователь может играться с гридом пока генерируется файл. Можно поиграться и спрятать кнопку самому.
Был бы у меня Devexp GridView — не знал бы проблем.
увы.

Здравствуйте, somesoul, Вы писали:

S>Я уже писал, что и так сделано через iframe. Также я писал что не хочу опрашивать клиентом сервер по таймеру.
S>Момент "завершения генерации" мы и обсуждаем: его отловить не удается, хотя умные люди как-то ухитряются это сделать.

Зачем вам опрашивать сервер? Пусть сервер в IFRAME отправит страницу со скриптом который, разблокирует вам UI и после этого сделает редирект на адрес с котрого уже будет скачиваться готовый отчет...

TK>>Если честно, то ничего похожего на это я там не заметил. Видел эффект аналогичный описанному Lloyd. Это говорит как минимум о том, что никакой UI не блокируется.
S>До конца генерации контента файла они изменяют курсор, но не блокируют форму.

Честно говоря, у меня такого не наблюдается.

S>Форма блокируется одновременно с появлением диалога.
S>Это приемлемое решение, т.к пользователь может играться с гридом пока генерируется файл. Можно поиграться и спрятать кнопку самому.

Какой смысл специально блокировать форму на время появления диалога? В момент его появления уже пошло скачивание файла и пользователь мало чего может изменить. Более того, этот диалог часто является модальным — блокирование может быть вызванно именно этим эффектом.

Здравствуйте, TK, Вы писали:
TK>Зачем вам опрашивать сервер? Пусть сервер в IFRAME отправит страницу со скриптом который, разблокирует вам UI и после этого сделает редирект на адрес с котрого уже будет скачиваться готовый отчет...
Я тоже, в конце концов, остановился на таком решении. Буду мириться с двумя постами.

Кому интересно вот сырой вариант страницы загружаемой в iframe
функция DontWaitForFileAnymore() объявляется на базовой странице в которой содержится iframe

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="DownloadFilePage.aspx.cs" Inherits="CNGOnline.DownloadFilePage" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
    <script language="javascript" type ="text/javascript">
        function onDownloadPageLoaded() {
            alert("Hi!");
            if (parent != undefined && parent != null && parent.DontWaitForFileAnymore != undefined) 
                parent.DontWaitForFileAnymore();
            m_btnGetReport = document.getElementById("m_btnGetReport");
            m_btnGetReport.click();
        }
    </script> 
</head>

<body onload="onDownloadPageLoaded();">
    <form id="form1" runat="server">
    <div>
        <asp:Button ID="m_btnGetReport" runat="server" Text="Button"/>
    </div>
    </form>
</body>
</html>

и не забыть в OnLoad

       protected void Page_Load(object sender, EventArgs e)
        {

            // Убить кеш об стену...
            if (!this.IsCallback && !this.IsPostBack)
            {
                //сгенирировать файло...
                Thread.Sleep(3000);
            }
            else
            {
               //выложить файло в response...
            }
        }

TK>>>Если честно, то ничего похожего на это я там не заметил. Видел эффект аналогичный описанному Lloyd. Это говорит как минимум о том, что никакой UI не блокируется.
S>>До конца генерации контента файла они изменяют курсор, но не блокируют форму.
TK>Честно говоря, у меня такого не наблюдается.
Sorry, так красиво ведет себя Opera.
глянул в IE: действительно все выглядит попроще.

Здравствуйте, SergASh, Вы писали:
SAS>Вам уже предложили делать опрос сервера, и это хороший способ. В момент начала генерирования файла кладёте в кеш какое-то значение с ключом, однозначно идентифицирующим файл, по окончании работы удаляете его из кеша.
SAS>Опыт показывает, что браузер выполняет аяксные запросы последовательно, поэтому если сначала натравить iframe на нужный адрес, а потом начать опрос аяксными вызовами, то самый первый такой вызов поступит на сервер уже после того, как генерирование файла закончится. В результате сколько бы ни заняло времени генерирование файла, опросить потребуется только один раз.
Спасибо за вариант. Он возможно и будет работать во всех браузерах так как вы предполагаете.
Проверять его у меня уже нет ни времени и желания. Кроме того мне не нравится вешать клиент на таймер и дергать постоянно сервер.

Здравствуйте, somesoul, Вы писали:

S>Спасибо за вариант. Он возможно и будет работать во всех браузерах так как вы предполагаете.
S>Проверять его у меня уже нет ни времени и желания. Кроме того мне не нравится вешать клиент на таймер и дергать постоянно сервер.

Постоянно дергать не нужно, да и не получится. Будут ровно те же два запроса, что и в вашем варианте, только на сервере не придется сохранять результат генерации, поэтому в целом переделок меньше выходит. Последний раз как я такое делал на реализацию ушло минут 20-25, правда на MVC.

Здравствуйте, SergASh, Вы писали:

SAS>Вам уже предложили делать опрос сервера, и это хороший способ. В момент начала генерирования файла кладёте в кеш какое-то значение с ключом, однозначно идентифицирующим файл, по окончании работы удаляете его из кеша.

SAS>Опыт показывает, что браузер выполняет аяксные запросы последовательно,

Последовательно? А как вы объясните поведение такого кода:

public class HomeController : Controller {
    public ActionResult Index() {
        return View();
    }

    public JsonResult Fast() {
        return Json("Fast!", JsonRequestBehavior.AllowGet);
    }

    [OutputCache(Duration = 0, VaryByParam = "none")]
    public JsonResult Slow() {
        Thread.Sleep(5*1000);
        return Json("Slow...", JsonRequestBehavior.AllowGet);
    }
}

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
  <title></title>
  <script src="../../Scripts/jquery-1.4.1.min.js" type="text/javascript"></script>
  <script type="text/javascript">
    $.getJSON("/Home/Slow", null, function (data) { $('body').append(data); });
    $.getJSON("/Home/Fast", null, function (data) { $('body').append(data); });
  </script>
</head>
<body>
</body>
</html>

Здравствуйте, SergASh, Вы писали:
S>>Спасибо за вариант. Он возможно и будет работать во всех браузерах так как вы предполагаете.
S>>Проверять его у меня уже нет ни времени и желания. Кроме того мне не нравится вешать клиент на таймер и дергать постоянно сервер.
SAS>Постоянно дергать не нужно, да и не получится. Будут ровно те же два запроса, что и в вашем варианте, только на сервере не придется сохранять результат генерации, поэтому в целом переделок меньше выходит. Последний раз как я такое делал на реализацию ушло минут 20-25, правда на MVC.

Чисто спортивный интерес. Не могли бы вы подробнее описать процедуру взаимодействия клиента с сервером в вашем варианте. желательно на примере стандартного ASP.Net.

Здравствуйте, SergASh, Вы писали:

SAS>Опыт показывает, что браузер выполняет аяксные запросы последовательно, поэтому если сначала натравить iframe на нужный адрес, а потом начать опрос аяксными вызовами, то самый первый такой вызов поступит на сервер уже после того, как генерирование файла закончится. В результате сколько бы ни заняло времени генерирование файла, опросить потребуется только один раз.

Это целиком зависит от браузера — сомнительно, что подобное поведение прописано хоть в каком-то стандарте. В следующий раз браузер может послать запрос не дожидаясь предваритено ответа.

Здравствуйте, TK, Вы писали:

TK>Это целиком зависит от браузера — сомнительно, что подобное поведение прописано хоть в каком-то стандарте. В следующий раз браузер может послать запрос не дожидаясь предваритено ответа.

Конечно, именно поэтому и нужно писать честный опрос на случай, если таки браузер станет отправлять запросы параллельно. Просто на всех тех браузерах, на которых я тестировал, а именно FF 3.5, Opera 10, Chrome 5.0, Safari 4.0 и IE6, параллельности не было и близко.

Здравствуйте, TK, Вы писали:

SAS>>Опыт показывает, что браузер выполняет аяксные запросы последовательно, поэтому если сначала натравить iframe на нужный адрес, а потом начать опрос аяксными вызовами, то самый первый такой вызов поступит на сервер уже после того, как генерирование файла закончится. В результате сколько бы ни заняло времени генерирование файла, опросить потребуется только один раз.
TK>Это целиком зависит от браузера — сомнительно, что подобное поведение прописано хоть в каком-то стандарте. В следующий раз браузер может послать запрос не дожидаясь предваритено ответа.

Опыты бывают разные. Согласен с мнением ТК.