И спор сейчас пойдет на тему что лучше: try/catch с исключением или if/else с функцией-валидатором :)
Лично я принципиальной разницы в данной ситуации не вижу — главное не смешивать модель с представлением, о чем и писал изначально :)
А вы себе можете представить пользователя, который заметит тормоза единоразового вызова этого обработчика? Да создание мессаджбокса займет больше времени, чем обработка исключения :)
А Qt/WinForms/VCL/<ваш-любимый-тулкит> с этой точки зрения вообще насмерть убивает производительность, создавая лишнюю прослойку над WinAPI…
Я, конечно, люблю поковыряться в низкоуровневой оптимизации, но только когда это большие массивы данных и большое количество итераций, а тут… :)
TBitBtn там был, клон обычного баттона только с иконкой :) А краишлось оно от какой-то компоненты кривой, но из стандартной поставки. Насчет вызовов — не знаю, апишному приложению манифеста хватает.
Да и вообще — это давно было, лет 6 назад… Сейчас я с итренфейсом сталкиваюсь в основном в миранде, а там царит C да WinAPI :)
Ага, только от добавления манифеста приложение падало на старте )
Да и поддержка тем в системных контролах ну никак не поможет кастомной отрисовке кнопок :)
Ой не… На внешний вид каждая следующая винда требует поиск новых компонент, которые умеют рисовать себя похоже на новую тему винды :) Да и куча косяков в кастомной прорисовке из VCL тоже меня убивают…
Так было по крайней мере во времена ХР, потом я как-то от дельфи ушел :)
Сам пользовался дельфей некоторое время… Так вот интерфейс с системным look&feel (вот есть у меня такая заморочка) проще писать и поддерживать на winapi (кросс-платформенность не в счет). А если забить на эту мелочь, то «заказчик хавает» :)
Вы себе не представляете, как требовательны «ихние» компании к оформлениям техническиго дизайна и прочей документации ) По крайней мере те, с которыми я работал.
Написать нормальный проект без предварительного обдумывания невозможно. Документация — один из способов коллективного обдумывания проекта + потом по документу легче координиировать действия команды. Отдай такое кому-то левому — год разгребать будешь.
Ладно, проехали, всему свое место на самом деле :)
if (!User::ValidateInput(...))
{
// bad input
return;
}
user = new User(...);
//…
тем более что все-равно прийдется как-то ловить ошибки вроде недоступности базы, или сбоя подключения, или еще что там может вылезти.
P.S. никакого отношения к коду из топика это уже не имеет, просто философия способов организации кода :)
Лично я принципиальной разницы в данной ситуации не вижу — главное не смешивать модель с представлением, о чем и писал изначально :)
А Qt/WinForms/VCL/<ваш-любимый-тулкит> с этой точки зрения вообще насмерть убивает производительность, создавая лишнюю прослойку над WinAPI…
Я, конечно, люблю поковыряться в низкоуровневой оптимизации, но только когда это большие массивы данных и большое количество итераций, а тут… :)
try
{
user = new User(txtName.Text, txtPassword.Text);
//…
}
catch (ArgumentException)
{
// bad user input
}
catch (Exception)
{
// something gone wrong
}
Это переносит валидацию корректности имени (например надо только латиницу) на уровень движка аккаунтов, оставляя отображение на уровне интерфейса.
Да и вообще — это давно было, лет 6 назад… Сейчас я с итренфейсом сталкиваюсь в основном в миранде, а там царит C да WinAPI :)
Да и поддержка тем в системных контролах ну никак не поможет кастомной отрисовке кнопок :)
Вцелом стиль выдержан )
Так было по крайней мере во времена ХР, потом я как-то от дельфи ушел :)
А так, конечно есть множество более удобных вещей чем WinAPI, будь он идеальным — другие тулкиты бы не появлялись.
P.S. вы не любите WinAPI? да вы просто не умеете его готовить! (с) анекдот :)
Функциональное вроде в этом топике не совсем уместно по контексту.
Написать нормальный проект без предварительного обдумывания невозможно. Документация — один из способов коллективного обдумывания проекта + потом по документу легче координиировать действия команды. Отдай такое кому-то левому — год разгребать будешь.