Правильно розставляємо послідовність перемикання компонентів
Багато користувачів, особливо ті, хто раніше працював в ДОС, мають звичку переключатися між полями вводити не мишкою, а за допомогою клавіатури клавішею Tab. До того ж, це набагато швидше, ніж виділяти кожне поле мишею. Тому порядок перемикання компонентів повинен бути виставлений правильно. Це стосується як компонентів всередині всіх компонентів-контейнерів (панелей, GroupBox-ів і їм подібних), так і самих компонентів-контейнерів, якщо їх на формі кілька.
Порядок перемикання компонентів всередині контейнера задається властивістю TabOrder. Першим стає активним компонент, у якого TabOrder дорівнює 0, другим з 1 і т.д. поки не будуть перебрані всі компоненти. Крім цього, у компонента є властивість TabStop, яке показує, чи буде компонент отримувати фокус при перемиканні клавішею Tab. Якщо потрібно заборонити перемикання на будь-який компонент, поставте в нього TabStop = false. В цьому випадку переключитися на даний компонент можна буде тільки за допомогою миші.
Бувають випадки, коли користувачі, які звикли перемикатися певної клавішею в одній програмі, за звичкою продовжують користуватися їй і в інших. Часто це відбувається з користувачами 1С, де для переходу по полях введення може використовуватися клавіша Enter. Що ж, дамо їм таку можливість в наших програмах, якщо вони про це просять. Встановлюємо у форми властивість KeyPreview в true і пишемо обробник події OnKeyPress:
Такий обробник забезпечує перехід за елементами форми при натисканні клавіші Enter. Слід зауважити, що подібний метод не буде працювати з кнопками, тому що натискання Enter на кнопці призводить до її натискання, тоді як натискання Tab передає фокус введення наступного в послідовності перемикання компоненту.
Кнопки за замовчуванням
Всі ті ж користувачі досить швидко звикають, що в діалогових вікнах додатків, як правило, клавішею Enter можна підтвердити свій вибір, а клавішею Esc - скасувати. Давайте не будемо їх розчаровувати в наших програмах, тим більше що зробити це дуже просто. Для кнопки, що реагує на Enter, встановлюємо властивість Default в true. Для кнопки, що реагує на Esc, встановлюємо властивість Cancel в true. І все.
Так чи ні
Всі діалогові вікна, що запитують дії користувача, повинні мати, принаймні, дві кнопки: підтвердження дії і відмови від дії (Так / Ні, Зберегти / Скасувати і т.п.). Відмова від дії може здійснюватися закриттям вікна кнопкою [X] в заголовку вікна. Неприпустимо, якщо є тільки одна кнопка для підтвердження дії, а для відмови передбачається закривати вікно кнопкою [X] в заголовку, або можливість відмови взагалі відсутня. Це плутає користувача, викликаючи логічне запитання: а як відмовитися?
Також не забуваємо про те, що було сказано вище в пункті "Кнопки за замовчуванням".
Всі діалогові вікна повинні відкриватися по центру екрана
По центру, а не там, де вони були створені в режимі проектування. По-перше, це наочніше, а по-друге, автоматично усуває проблему різного дозволу екрану у різних користувачів.
Виняток робиться в тому випадку, якщо діалогове вікно не модально, і за результатами роботи користувача в цьому вікні відразу відбуваються зміни в основному вікні (наприклад, фільтрація набору даних, перемальовування графіків і т.п.).
Розміри вікон не повинні перевищувати розмірів екрану
Ні в якому разі. Це неподобство, коли частина вікна вилазить за екран. Дана вимога не залежить від дозволу екрану у користувача, тобто відмовки типу "Хай поставлять більшу роздільну здатність" не проходять.
Коректна зміна розмірів віконних елементів
Віконні елементи повинні коректно змінювати свої розміри або переміщатися при зміні розмірів вікна, при максимізації вікна і при відновленні вікна після максимізації.
Все завжди видно
Зменшення розмірів вікна не повинно призводити до зникнення віконних елементів і бажано не повинно призводити до появи смуг прокрутки (scroller-ів) самого вікна. Можна обмежувати мінімальні розміри вікна таким чином, щоб всі елементи були видні і доступні. Якщо немає можливості розмістити компоненти таким чином, щоб всі були видні у вікні, можна використовувати закладки (типу PageControl) для розбиття компонентів на групи. Відмовки з приводу дозволу екрану теж не пропускаємо.
Хинти всюди, хинти завжди
Для кнопок, особливо на панелях інструментів (типу ToolBar) повинні бути задані підказки (hint), щоб завжди було зрозуміло, навіщо потрібна та чи інша кнопка.
Кольорова гама
Не варто розфарбовувати компоненти на формі в усі кольори веселки. Це втомлює очі і розсіює увагу користувача. Це не виглядає "круто". Виділення кольором використовується в тому випадку, коли треба привернути увагу користувача до якогось певного елементу або певної частини вікна. Наприклад, розфарбувати світло-червоним кольором записи, в яких присутні помилки або, навпаки, світло-зеленим кольором записи, перевірка яких пройшла успішно.
висновок
Є дуже хороший метод, який дозволяє знайти недоліки програми взагалі і інтерфейсу зокрема. Він простий: уявіть себе на місці користувача і протягом півгодини спробуйте працювати так, як працює він. Ще краще, якщо ваш користувач в межах досяжності (наприклад, працює в тій же організації). В такому випадку сядьте поруч з ним, а краще замість нього, і спробуйте зробити його роботу. Вносити дані, змінювати їх, виводити звіти і т.д. Якщо ви не знаєте, як зробити правильно, запитайте у свого користувача. Зробіть не одну-дві однотипні операції, як в отладочном режимі, а 20-30, а то і більше різних операцій, в різному порядку. Забудьте що-небудь ввести або введіть неправильно і подивіться, як програма на це відреагує. Ви досить швидко побачите слабкі місця вашої програми.
Таким чином, пам'ятайте про зручність роботи для користувачів. Нехай їм буде легко і приємно працювати з вашими програмами.
Збірка проектаДля компіляції прикладу потрібно середовище розробки Delphi 6 або 7.Файл проекту - TestVK.dpr.Откройте цей файл (наприклад, подвійним клацанням миші з Провідника). Натисніть клавіші Ctrl-F9 (або пункт меню Project-Compile). Якщо все пройшло нормально, в цій же папці утворюється готовий.
1. Вибираємо з бази даних тільки ті поля, які нам нужниЗапроси виду: select * from. можуть дуже сильно навантажити як сервер, так і комп'ютер користувача, особливо якщо таблиці містять великі символьні або виконавчі поля. Наприклад, навіщо вибирати поле з фотографією співробітників, коли потрібні.
Нерідко зустрічав на форумах думки, що потоки не потрібні взагалі, будь-яку програму можна написати так, що вона буде чудово працювати і без них. Звичайно, якщо не робити нічого серйозніше "Hello World" це так і є, але якщо поступово набирати досвід, рано чи пізно будь-який початківець програм.
Напевно кожен з нас хоча б раз у своїй практиці, але зустрічався з кодом виду: TForm1 = class (TForm) private procedure MyCoolHandler (var Message: TMessage); message WM_USER; public end; procedure TForm1.MyCoolHandler (var Message: TMessage); begin Message.Result: = 32767 ;.