ограничение ввода

← →
фыва (2007-10-23 11:55) [0]

Всем доброо времени суток.
Подскажите, пожалуйста, как мне ограничить ввод символов в едит только числами
пишу в OnPressKey:
if not Key in ("0".."9") then Key := #0;
ругается.
Заранее благодарен.

← →
Правильный_Вася (2007-10-23 11:59) [1]

> ругается.

матом?

← →
Palladin © (2007-10-23 12:03) [2]

if not Key in ["0".."9"] then Key := #0;

← →
Ins © (2007-10-23 12:06) [3]

> Palladin © (23.10.07 12:03) [2]

Полагаю, следующий вопрос будет, а как мне сделать так, чтобы туда еще и вставить из буфера ничего лишнего было нельзя. А если так, то см. здесь + обсуждение:
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1140

← →
фыва (2007-10-23 12:15) [4]

> Palladin © (23.10.07 12:03) [2]

спасибо

> Ins © (23.10.07 12:06) [3]

Не правильно полагаешь

← →
фыва (2007-10-23 12:17) [5]

> Palladin © (23.10.07 12:03) [2]

[Error] uAct.pas(140): Operator not applicable to this operand type

← →
фыва (2007-10-23 12:38) [6]

Ну скажите же, что писать и где: в OnKeyPress или OnKeyDown?

← →
Leonid Troyanovsky © (2007-10-23 12:40) [7]

> фыва (23.10.07 12:17) [5]

> [Error] uAct.pas(140): Operator not applicable to this operand type

Там же курсор встает где not applicable.

Жмешь на оной строке compiler messages F1 и изучаешь статью.
Т.е. not (Key in ["0".."9"])

--
Regards, LVT.

← →
Leonid Troyanovsky © (2007-10-23 12:46) [8]

> фыва (23.10.07 12:38) [6]

> Ну скажите же, что писать и где: в OnKeyPress или OnKeyDown?

Я бы написал в OnChange.

А, во-ще, почитай
http://groups.google.com/group/borland.public.delphi.vcl.components.using.win32/msg/e73fe76d78b7b8f4

--
Regards, LVT.

← →
Ins © (2007-10-23 12:48) [9]

> Я бы написал в OnChange.

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

← →
Leonid Troyanovsky © (2007-10-23 12:56) [10]

> Ins © (23.10.07 12:48) [9]

> Ну а я бы отделял мух от котлет, и запихнул бы весь этот
> функционал в отдельный класс.

Peter предлагал, например, TNumberEdit и т.п.
Я предлагал, например,
http://www.rsdn.ru/Forum/Message.aspx?mid=626935&only=1

Но, я, также, не настаиваю :)

--
Regards, LVT.

← →
Ins © (2007-10-23 13:04) [11]

Кстати, есть еще такой стиль окна - ES_NUMBER, но если не ошибаюсь, от вставки из буфера он не спасает.

← →
Leonid Troyanovsky © (2007-10-23 13:10) [12]

> Ins © (23.10.07 13:04) [11]

> Кстати, есть еще такой стиль окна - ES_NUMBER, но если не
> ошибаюсь, от вставки из буфера он не спасает.

Не ошибаешься.

Вот, кста,
http://groups.google.com/group/borland.public.delphi.vcl.components.writing/msg/41b62f85dd405cdf

--
Regards, LVT.

← →
Ega23 © (2007-10-23 13:15) [13]

ДА нефиг заморачиваться.
Просто проверяйте перед тем, как OK нажать - и всё нормально... :)

← →
Anatoly Podgoretsky © (2007-10-23 13:15) [14]

> Ins (23.10.2007 13:04:11) [11]

Спастись просто - это не ограничивать пользователя, ему виднее как вводить.

← →
Leonid Troyanovsky © (2007-10-23 13:16) [15]

> Ega23 © (23.10.07 13:15) [13]

> Просто проверяйте перед тем, как OK нажать - и всё нормально.

А почему перед?

--
Regards, LVT.

← →
Ins © (2007-10-23 13:26) [16]

> Спастись просто - это не ограничивать пользователя, ему
> виднее как вводить.

Где-то в одной из книг по проектированию UI этот момент излизан со всех сторон. В общем, не всегда ему виднее, но нужно сделать так, чтобы было видно. Хорошим стилем считается "говорящая" метка возле поля ввода, которая хорошо поясняет, что же тут должно быть введено, и Beep при вводе не того, что нужно. Можно еще дисэйбл/энейбл кнопки "ОК", или какая там еще будет. Плюс контекстная справка. В общем, направлять пользователя нужно, но максимально мягко, чтобы он об этом даже не заподозрил и не считал себя идиотом.

← →
Leonid Troyanovsky © (2007-10-23 13:27) [17]

> Anatoly Podgoretsky © (23.10.07 13:15) [14]

> Спастись просто - это не ограничивать пользователя, ему
> виднее как вводить.

Введет-то он правильно, и будет спрашивать,
почему, скажем, IЗО не принимают.

--
Regards, LVT.

← →
Anatoly Podgoretsky © (2007-10-23 13:40) [18]

> Leonid Troyanovsky (23.10.2007 13:27:17) [17]

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

← →
Ins © (2007-10-23 14:19) [19]

> А если посмотреть по форуму, то ограничение у некоторых
> становится самоцелью.

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

← →
Leonid Troyanovsky © (2007-10-23 14:33) [20]

> Anatoly Podgoretsky © (23.10.07 13:40) [18]

> Не на этом надо зацикливаться в большинстве случаев, а применять
> ограниченный ввод только в действительно мотивированных

Вот, к примеру, TDateTimePicker - специализированный
контрол, достаточно сильно ограничивающий ввод юзера
(на основе достаточно нетривиальных проверок).
Но он, все равно, IMHO, удобней любого TEdit,
допускающего произвольный ввод.
Примерно тоже можно сказать пр контрол для ввода IP.

Так почему б не быть TNumberEdit?
Пусть он будет, скажем, с нестандартным фоном.
Хотя, например, окно ввода у Calc.exe и вовсе не EDIT,
и прямой ввод туда, во-ще, заказан.

--
Regards, LVT.

← →
Anatoly Podgoretsky © (2007-10-23 14:49) [21]

> Leonid Troyanovsky (23.10.2007 14:33:20) [20]

> Так почему б не быть TNumberEdit?

Так нет же, как и TIPEdit
А TDateTimePicker удобен если ввод в текущем месяце, далее пользователи начинают путаться.
Ну и главное это не должно быть самоцелью.

← →
Ins © (2007-10-23 15:00) [22]

> Так нет же, как и TIPEdit

По-моему, оконный класс, реализующий ввод только IP-адреса, есть в comctrls.dll. Нет объектной надстройки над ним в VCL, но никто не мешает ее сделать самому.

> А TDateTimePicker удобен если ввод в текущем месяце, далее
> пользователи начинают путаться.

Тоже спорно. Скорее они запутаются при вводе даты вручную.

← →
Ins © (2007-10-23 15:03) [23]

> Пусть он будет, скажем, с нестандартным фоном.

ИМХО, выравнивание текста по правому краю неплохо намекает на то, что это для цифр. По крайней мере такое часто встречается и может быть "понято" пользователем.

← →
Anatoly Podgoretsky © (2007-10-23 15:05) [24]

> Скорее они запутаются при вводе даты вручную.

У нас разные пользователи!
Кстати у них во многих приложением есть кнопка вывода календаря, практически никогда не пользуются.

← →
Ins © (2007-10-23 15:06) [25]

> Ins © (23.10.07 15:03) [23]

И пусть в этом поле сразу же по умолчанию стоит какое-либо значение, например 0, а ввод пустой строки автоматически на 0 заменяется.

> и прямой ввод туда, во-ще, заказан.

Вроде бы как можно.

← →
Leonid Troyanovsky © (2007-10-23 15:17) [26]

> Ins © (23.10.07 15:06) [25]

> > и прямой ввод туда, во-ще, заказан.

> Вроде бы как можно.

Там нынче уже STATIC, IMHO.

--
Regards, LVT.

← →
Ins © (2007-10-23 15:24) [27]

> Там нынче уже STATIC, IMHO.

Только что попробовал - получилось. WinXP. Оконный класс - "Edit"

← →
Leonid Troyanovsky © (2007-10-23 15:35) [28]

> Ins © (23.10.07 15:03) [23]

> ИМХО, выравнивание текста по правому краю неплохо намекает
> на то, что это для цифр.

Снабдим TMemo высотой в одну строку, taRightJustify,
обработчиком OnChange и вуа-ля!
Я победил :)

--
Regards, LVT.

> Снабдим TMemo высотой в одну строку, taRightJustify,
> обработчиком OnChange и вуа-ля!

А зачем? :)))

> Ins © (23.10.07 15:24) [27]

> > Там нынче уже STATIC, IMHO.
>
> Только что попробовал - получилось. WinXP. Оконный класс
> - "Edit"

Мда.. Попутал, это раньше был STATIC (даже пара).
Sorry.

--
Regards, LVT.

> Выровнять по правому краю.

М"сье понимает толк в извращениях :)) (Это не наезд, это шутка)

> Leonid Troyanovsky (23.10.2007 15:35:28) [28]

Победил, только тяжело.

Понять что ввел не правильно пользователь долже до submit, даже если этот submit не заметен по времени.

Вспмните «тупые» сайты, введя в который ник и еще кучу араметров жмёш сабмит, ждёшь, а потом «ой такой ник уже занят» и половина полей пустая(снова вводить).

Так вот настольное приложение тут ничем не отличается от сайта. И если я в поле «Возраст» ввожу «Колян», мне олжнв об этом тут же сообщить, но не прерывая мою работу(то есть MessageBox фтопку).

Я и скайп например сообщают внизу поля ввода строкой с 7 шрифтом и с красным цветом. (Иногда «вылезает» собщение из под заголовка формы&#133) и пока нормально не введешь submit сделать нельзя.

короче ради примера можно посмотреть инсталлер скайпа.

if not Key in ["0"&#133"9"] then Key := #0;
А стирать как? Хде #8?

Если этот код в OnKeyPress, то надо все равно сообщать что введены не те символы, иначе не понятно что не так&#133

> Anatoly Podgoretsky © (23.10.07 15:54) [33]

> Победил, только тяжело.

Ладно уж, напишу дома TNumberEdit = class(TEdit),
с правым выравниванием.

В фак-то хоть включат? :)

--
Regards, LVT.

> Ладно уж, напишу дома

Поделитесь?
А добавтьте туда события, тобы можно было информировать пользователя о том что именно не так.

И еще, а может сделать эдит с неким интерфейсом, а конкретные проверки завернуть в объект и подключать к эдиту. Ведь TFloatEdit нужет не реже :)&#133

> Ладно уж, напишу дома TNumberEdit = class(TEdit),
> с правым выравниванием.

Все уже написано. :) Ссылку я привел. Там в обсуждении статьи Shabal именно такой компонент выложил. Да и вообще в интернете полно таких компонентов.
А считаю, что писать класс нужно вместо обвешивания TEdit или TMemo обработчиками событий по следующим банальным причинам:
1. Наверняка ведь понадобится не в одном проекте. А раз так, то проще один раз написать, а потом просто кидать компоненты на форму, чем по десять раз переписывать одни и те же обработчики событий.
2. В случае обработчиков событий нет никакой модульности. Только захламляется модуль формы.

> Ins © (23.10.07 16:19) [38]

> Все уже написано. :) Ссылку я привел. Там в обсуждении статьи
> Shabal именно такой компонент выложил. Да и вообще в интернете
> полно таких компонентов.

Уговорил :) Не буду, уж больно скучны все эти ffFixed.

> А считаю, что писать класс нужно вместо обвешивания TEdit
> или TMemo обработчиками событий по следующим банальным причинам:

Ну, а считаю, что тот, кому нужно, может и сам сделать Change; override.
И добавить по-вкусу выравнивание - не квадратный трехчлен.

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

> Kolan © (23.10.07 16:15) [37]

> И еще, а может сделать эдит с неким интерфейсом, а конкретные
> проверки завернуть в объект и подключать к эдиту. Ведь TFloatEdit
> нужет не реже :)…

С Float, как раз, все просто: Val что передадут, то и будет.
А вот бизнес-компонент, конечно, интересней б было представить,
но, пока не очень ясно, стоит ли его интегрировать с обычным Edit,
а делать специализированный контрол не очень хочется.

Хотя, возможно, что для некоего грида игра и может стоить свеч.

--
Regards, LVT.

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

ограничение ввода Найти похожие ветки