Страница: 1 | 2 |
|
Вопрос: существует ли метод, противоположный Refresh?!
|
Добавлено: 13.05.07 04:49
|
|
Автор вопроса: Marki
|
Используется VB EE 2005.
Вопрос:
Есть ли возможность остановить отображение изменений, происходящих с объектом (TextBox)?
Пояснение:
Есть поле для ввода информации. Для проверки корректности ввода (соответствия определенным требованиям) используется событие "TextBox.TextChanged".
Если условия корректности не соблюдаются, в поле возвращается текст, находившийся там перед изменением.
Проблема: перед отображением корректного значения, находившегося в поле ранее, на экране "проскакивает" вводимый в поле "некорректный" символ.
PS Использование события "TextBox.TextChanged" обусловлено необходимостью действий, выполняющихся синхронно с вводом пользователем данных.
Благодарю Всех за помощь.
Ответить
|
Номер ответа: 2 Автор ответа: GSerg
Вопросов: 0 Ответов: 1876
|
Профиль | | #2
|
Добавлено: 13.05.07 12:28
|
Если знаешь MASM32
MASM32 в .NET? Оригинально.
смотри в его примерах про суперклассинг
Суперклассинг приведёт к обработке вообще всех текстбоксов. Это то, что требуется? Сомневаюсь.
Marki, таки обоснуй необходимость использования TextBox.TextChanged.
Ответить
|
Номер ответа: 3 Автор ответа: Marki
Вопросов: 42 Ответов: 94
|
Профиль | | #3
|
Добавлено: 13.05.07 13:36
|
2 GSerg
Marki, таки обоснуй необходимость использования TextBox.TextChanged.
Обоснование использования TextBox.TextChanged было СПЕЦИАЛЬНО указано в тексте вопроса в разделе PS для исключения подобных вопросов.
Ответить
|
Номер ответа: 6 Автор ответа: Marki
Вопросов: 42 Ответов: 94
|
Профиль | | #6
|
Добавлено: 13.05.07 14:18
|
Еще раз, специально по просьбе аудитории.
В данном случае событие "TextBox.TextChanged" используется для выполнения действий, выполняющихся синхронно с вводом пользователем данных.
Пример:
1) синхронный перевод текста
2) калькулятор с расчетом по ВВОДИМОМУ числу
3) и тд
Для чего это надо?! Объем вводимой информации крайне небольшой, и "вешать" дополнительно кнопку "выполнить" (или давить "Enter" или что-либо пободное, заставляя пользователя двигать мышкой, стучать "Tab'ом"... представляется нецелесообразным.
Если сумеете предложить другой вариант оценки окончания ввода пользователем данных (фокус при этом может вполне остаться непосредственно в объекте ввода) - буду благодарен.
При этом еще раз поясню, что результатом ввода может быть даже одна-единственная нажатая клавиша, а отображение результата обработки введенных данных должно полностью соответствовать текущей информации в полях ввода (!).
Убедительная просьба - отвечать ПО СУЩЕСТВУ.
Ответы типа "мне не нравится твое решение", не подкрепленное альтернативными вариантами, вынужден буду оставлять без внимания.
Благодарю всех за понимание, и еще раз спасибо.
Ответить
|
Номер ответа: 7 Автор ответа: GSerg
Вопросов: 0 Ответов: 1876
|
Профиль | | #7
|
Добавлено: 13.05.07 15:20
|
Сколько праведного гнева.
Я плАчу.
Убедительная просьба - отвечать ПО СУЩЕСТВУ.
Приведённые ответы являются ответами ПО СУЩЕСТВУ. Потому что они должны были заставить автора заново просмотреть хотя бы список событий TextBox. Если этого не произошло, это просто характеризует.
RTFM.
Запрет ввода "a" и "b".
Private Sub TextBox1_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles TextBox1.KeyPress
If e.KeyChar = "a"c OrElse e.KeyChar = "b"c Then e.Handled = True
End Sub
Ответить
|
Номер ответа: 8 Автор ответа: Marki
Вопросов: 42 Ответов: 94
|
Профиль | | #8
|
Добавлено: 13.05.07 15:40
|
... то это всего лишь характеризует невнимательность к написанному ранее:
Для проверки корректности ввода ...
Есть клавиши, которые РАЗРЕШЕНЫ к вводу, но НЕ ВСЕГДА.
Поясню на примере, чтобы "ответы по существу" реально были ими "без слез".
Скажем, если Вы вводите время, то при вводе часов Вы можете использовать цифру "9", но не имеете такой возможности, если ранее уже была введена любая ццфра кроме "0" или "1". И даже если были введены "0" или "1", то "9" может быть введена только ПОСЛЕ них, а не перед ними.
Таким образом, банальный запрет ввода определенных символов НЕ проходит, потому что условие анализа корректности более сложное - проверяется не только ЧТО нажимается, но И ГДЕ, т.о. анализируется может ли быть текущий ввод корректным. Если условие корректности нарушено - восстанавливается значение, находившеееся в поле ДО нажатия клавиши, нарушающей корректность значения.
Ответить
|
Номер ответа: 9 Автор ответа: Marki
Вопросов: 42 Ответов: 94
|
Профиль | | #9
|
Добавлено: 13.05.07 15:45
|
ps Список событий пересмотрен многократно. Или глаз "замылился", или в EE нет более подходящего события.
Ткните, пожалуйста, в наиболее подходящий вариант с учетом написанного выше.
Ответить
|
Номер ответа: 10 Автор ответа: GSerg
Вопросов: 0 Ответов: 1876
|
Профиль | | #10
|
Добавлено: 13.05.07 16:17
|
Таким образом, банальный запрет ввода определенных символов НЕ проходит, потому что условие анализа корректности более сложное - проверяется не только ЧТО нажимается, но И ГДЕ, т.о. анализируется может ли быть текущий ввод корректным. Если условие корректности нарушено - восстанавливается значение, находившеееся в поле ДО нажатия клавиши, нарушающей корректность значения
Использование .NET вполне однозначно накладывает (что было неоднократно подтверждено ранее со многими лицами) отпечаток на программиста: если в FW нет класса, который на 100% сразу выполняет задачу, программист оказывается беспомощным.
Наличие классов-кирпичиков не помогает, т.к. способность самостоятельно складывать из них решение постепенно угасает.
Я, например, понятия не имею, как это делается, однако я нажимаю F2, просматриваю методы и события и - самое главное - думаю. И примерно через 15 секунд созревает что-то вроде
Private Sub TextBox1_KeyPress(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyPressEventArgs) Handles TextBox1.KeyPress
Dim FutureString As String = TextBox1.Text
FutureString = FutureString.Substring(0, TextBox1.SelectionStart) + e.KeyChar + FutureString.Substring(TextBox1.SelectionStart)
If FutureString = "abab" Then
e.Handled = True
End If
End Sub
Этот код разрешает ввод "a" и "b", но только если они не формируют "abab".
Ядерная физика?
Не думаю.
СтОит отстаивания нужности и важности TextChanged?
Не уверен...
Ответить
|
Номер ответа: 11 Автор ответа: Marki
Вопросов: 42 Ответов: 94
|
Профиль | | #11
|
Добавлено: 13.05.07 16:59
|
Однако могу только развести руками...
Ну кто сказал что ЗАМЕНЫ TextChanged нет?!
Как раз для меня вся проблема в том, что из нескольких существующих в моем понимании путей (слишком, мля, МНОГО думаю...) меня не устраивает полностью ни один. Просто не нравится. Чем?
Например, ваш Код, позволю заметить, не учитывает возможности ВЫДЕЛЕНИЯ части текста, когда любой вводимый символ просто замещает группу ранее введенного, а не просто дополняет строку. понимаю, что это скорее придирка к реализации идеи, но... Разговор то совсем о другом!
Все это я УЖЕ сделал ДО ТОГО как написать сюда вопрос: и с учетом выделенного ввода при наличии выделенного фрагмента, и с учетом ограничения на максимально допустимый размер строки, и с учетом... и т.д.
"Думать некогда, пырагать надо"... (
Все получается "громоздко". Пришел в голову как один из вариантов (! - смотри первоначальный вопрос)
ВСТАВКА:
ОСОБОЕ ВНИМАНИЕ ОБРАЩАЮ ЕЩЕ РАЗ: вопрос был не в том КАК сделать ВООБЩЕ (вариантов у меня несколько есть и у самого), а как реализовать КОНКРЕТНЫЙ вариант (если такая реализация возможна).
(продолжение абзаца) "притормозить" вывод на экран отображение ввода на этапе его анализа.
В этом и была суть вопроса, чтобы оценить реальность и целесообразность такого подхода.
Вы же у необъяснимой упорностью, несмотря на необходимость заставить автора заново просмотреть хотя бы список событий , упорно давите только на одно из них:TextBox1_KeyPress .
В любом случае - спасибо за диалог.
Метода, "противоположного" Refresh, видимо не имеется.
Еще раз всем спасибо, вопрос закрываю.
Ответить
|
Номер ответа: 13 Автор ответа: GSerg
Вопросов: 0 Ответов: 1876
|
Профиль | | #13
|
Добавлено: 13.05.07 17:06
|
"притормозить" вывод на экран отображение ввода на этапе его анализа.
В этом и была суть вопроса, чтобы оценить реальность и целесообразность такого подхода.
Ура.
Вот она, квинтэссенция.
"Притормаживанием" вывода на экран и занимается как раз событие KeyPress вообще и его флаг Handled в частности. Потому что событие вызывается до изменения состояния текстбокса (а не после, как изначально используемое).
упорно давите только на одно из них
Отчего же, есть и другие (из тех, которые вызываются до). Но они, смею заверить, в деле обработки такого ввода менее удобны.
Метода, "противоположного" Refresh, видимо не имеется.
Допустим, он имеется.
Где его планируется вызывать? В TextChanged? Результатом будет то же самое появление и пропадание неправильной буквы. Разве нет?
Ответить
|
Страница: 1 | 2 |
Поиск по форуму