| Вопрос: Delay | Добавлено: 26.05.09 17:17 |
Автор вопроса:  Sergey
|
| Ответы | Всего ответов: 32 |
|
Номер ответа: 16 Автор ответа:  VβÐUηìt Вопросов: 246 Ответов: 3333 |
Web-сайт: Профиль | | #16 | Добавлено: 28.05.09 15:41 |
| Потому что ты его не прорисовываешь. Update или Refresh вызывай, не помню, что там. | ||
|
Номер ответа: 17 Автор ответа: Arvitaly ICQ: 301746136 Вопросов: 28 Ответов: 549 |
Web-сайт: Профиль | | #17 | Добавлено: 28.05.09 15:48 |
| Слушай чувак скинь куда нить проект посмотрим, а то твой код у меня пашет без проблем | ||
|
Номер ответа: 18 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #18 | Добавлено: 28.05.09 17:22 |
| Поясни лучше что ты конкретно хочешь сделать. | ||
|
Номер ответа: 19 Автор ответа: Sergey Вопросов: 39 Ответов: 87 |
Профиль | | #19 | Добавлено: 28.05.09 17:44 |
Я хочу, чтобы текст в текстбоксе я видел раньше, чем начинал выполняться 1.bat |
||
|
Номер ответа: 20 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #20 | Добавлено: 28.05.09 17:52 |
|
||
|
Номер ответа: 21 Автор ответа: _SeregaВопросов: 1 Ответов: 43 |
Профиль | | #21 | Добавлено: 28.05.09 22:26 |
| Тут торможения не надо, тут в отдельном теневом потоке нужно запускать открытие файла - тогда торможения при выводе элементов текста не будет, все от того, что при передаче вызовов от среды .Net к АРI вызовам, что происходет при вызове Shell, тогда для системы наиболее приоритетным становится API вызов, поэтому отработка .Net среды тормозится и в некотроых случаях помогает настройка ускорения системы Windows - Свойства системы - Параметры быстродействия, но корректное решение - всеж отдельный поток создавать. | ||
|
Номер ответа: 22 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #22 | Добавлено: 28.05.09 22:37 |
|
_Serega пишет:
Тут торможения не надо, тут в отдельном теневом потоке нужно запускать открытие файла - тогда торможения при выводе элементов текста не будет, все от того, что при передаче вызовов от среды .Net к АРI вызовам, что происходет при вызове Shell, тогда для системы наиболее приоритетным становится API вызов, поэтому отработка .Net среды тормозится и в некотроых случаях помогает настройка ускорения системы Windows - Свойства системы - Параметры быстродействия, но корректное решение - всеж отдельный поток создавать. Все правильно кроме того что помечено курсивом. _Serega, будь добр, уважь мою просьбу в топике http://vbnet.ru/forum/show.aspx?id=189692&page=4, меня интерисует, в чем, по твоему мнению, мои представления о .NET неверные? |
||
|
Номер ответа: 23 Автор ответа: _SeregaВопросов: 1 Ответов: 43 |
Профиль | | #23 | Добавлено: 28.05.09 22:46 |
| Там ты не прав по той же причине, по которой и подчеркиваешь мои коментарии тут - ты можешь написать код, но не понимаешь это происходит, а я могу. И написал я все правильно, а если нет, то будь добр разъяснить, отчего это происходит, раз тебя не устраивает мое объяснение, а в личностных разборках я учавствовать нехочу и если будешь продолжать хамить, то просто буду игноировать. | ||
|
Номер ответа: 24 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #24 | Добавлено: 28.05.09 23:04 |
| Я тоже не понял, что значит "более приоритетным становится API вызов" и как именно это можно настроить через "Параметры быстродействия". | ||
|
Номер ответа: 25 Автор ответа: _SeregaВопросов: 1 Ответов: 43 |
Профиль | | #25 | Добавлено: 28.05.09 23:29 |
| В Параметрах быстродействия определяется приоритет выполнения потоков, который перераспределяется или для системных программ или для прикладных. Win 32 API - это основа посредством которой Windows "общается" c аппаратной частью, то есть когда выполняется команда считывания файла мы не обращаемся непосредственно к жесткому диску, как к физическому устройству и мы не задумываемся ни над аппаратными прерывавниями, ни аппаратными адресами - для этого есть драйвера, но при этом среда .Net вообще никак не взаимодействет и с драйверами устройств, для нас Windows организовывает уже высокоуровневое логическое устройство, как диск C: к примеру, но с таким устройством в действительности взаимодействует API, а мы из среды .Net вызываем API, к которому обращаемся через шлюзы CLR. Это в двух словах, а вообще это большой материал и не на одну книгу. | ||
|
Номер ответа: 26 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #26 | Добавлено: 28.05.09 23:34 |
|
_Serega, успокойся. Кроме тебя здесь никто не нашел хамства и личностных разборок.
Проблема которая стоит перед топик-стартером абсолютно тривиальна. Рассматриваем код
1) Каким образом происходит генерация события Button.Click? После клика по кнопке основной цикл обработки сообщений получает сообщение WM_RBUTTONUP, которое трактуется .NET как клик и приводит в конечном счете к генерации данного события. 2) Каким образом происходит установка текста в TextBox? Для того чтоб произошло обновление и перерисовка содержимого TextBox, должны обработаться несколько Windows-сообщений (скорее всего что-то вроде WM_SETTEXT и WM_PAINT, может еще что-то - можно легко проверить). 3) Каким образом выполняется задержка Thread.Sleep? Я не располагаю инфомрацией как реализован этот метод, но могу предположить что он просто вызывает функции Win32API Sleep, которая блокирует выполнение потока на некоторое время. 4) Как работает метод Shell? Скорее всего через функцию API ShellExecute/ShellExecuteEx. При этом происходит запуск нового процеса и после этого выполнение возвращается обратно в упралвяемый код. После выполнения Shell процедура завершает свою работу и цикл обработки сообщений сможет выполнить обработку поставленных туда WM_SETTEXT и WM_PAINT и что туда еще поставили. Таким образом, обновление текста на TextBox произойдет только после того как завершится процедура Button_Click. Способ решения я уже приводил - можно через Threading.Timer запланировать запуск нужного кода через определенное время. Можно запустить новый поток. Можно запустить код запуска процеса асинхронной операцией BeginInvoke. Также можно дать команду принудительно обработать поступившие сообщения в очередь:
О приоритете функции Win32API говорить нет никакого смысла, так как функция ShellExecute выполняется в том же потоке в котором выполняется Button1_Click. А вот запущеный батник, разумеется, будет выполняться в другом процесе и кто раньше кого выполнится, зависит от планировщика Windows, текущей загруженности системы и еще кучи факторов. При этом могу тебе точно сказать, что обновление содержимого TextBox произойдет намного раньше чем новосозданный процес успеет проинициализироваться и показать какой-то свой UI, если он у него есть. |
||
|
Номер ответа: 27 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #27 | Добавлено: 28.05.09 23:39 |
|
_Serega пишет:
В Параметрах быстродействия определяется приоритет выполнения потоков, который перераспределяется или для системных программ или для прикладных. Win 32 API - это основа посредством которой Windows "общается" c аппаратной частью, то есть когда выполняется команда считывания файла мы не обращаемся непосредственно к жесткому диску, как к физическому устройству и мы не задумываемся ни над аппаратными прерывавниями, ни аппаратными адресами - для этого есть драйвера, но при этом среда .Net вообще никак не взаимодействет и с драйверами устройств, для нас Windows организовывает уже высокоуровневое логическое устройство, как диск C: к примеру, но с таким устройством в действительности взаимодействует API, а мы из среды .Net вызываем API, к которому обращаемся через шлюзы CLR. Это в двух словах, а вообще это большой материал и не на одну книгу. Никто не спорит. Те опции которые находятся на указанной тобою вкладке используются, чтоб указать Windows, каков сценарий использования компьютера - либо это рабочая станция, либо это сервер, и таким образом Windows решает как распределять приоритет выполнения между клиентскими программами и службами (не обязательно системными). Вызовы Win32API ко всему этому не имеют практически никакого отношения. |
||
|
Номер ответа: 28 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #28 | Добавлено: 28.05.09 23:53 |
Smith, DoEvents уже было сказано  посмотри повыше!
|
||
|
Номер ответа: 29 Автор ответа: _SeregaВопросов: 1 Ответов: 43 |
Профиль | | #29 | Добавлено: 28.05.09 23:55 |
|
"Я не располагаю инфомрацией как реализован этот метод, но могу предположить что он просто вызывает функции Win32API Sleep, которая блокирует выполнение потока на некоторое время. "
- Ну в общем то я о том же и написал, но ты это почему то это же и оспариваешь. |
||
|
Номер ответа: 30 Автор ответа: ArtyomРазработчик Вопросов: 130 Ответов: 6602 |
Профиль | | #30 | Добавлено: 29.05.09 00:03 |
|
_Serega, жжошь , мастерски выдрал кусок из контекста
Чтоб точно узнать как ТЕХНИЧЕСКИ реализован метод Thread.Sleep, нужно увидеть его код. Рефлектором (кстати а что это такое?) его код нельзя получить, так как он помечен атрибутом
что означет что данный метод реализован в самой CLR на неуправляемом коде. Поэтому нужно либо качать опубликованные исходники CLR, либо с помощью отладчика отследить, какие вызовы Win32API выполняет этот метод. Делать все это у меня нет никакого желания, тем более с очень большой уверенностью я могу заявлять что данный метод вызывает функцию API Sleep, которая по интересному стечению обстоятельств имеет такое же имя как и у интерисующего нас метода и выполняет те же самые действия, что и указанный метод. |
||