В Windows Vista во многих MDI приложениях часто наблюдается баг (субъективно – в SP1/SP2 значительно реже) при максимизации дочернего окна – оно занимает не всю отведенную ему область. Справа остается небольшое пространство. Читать далее…
Все кто учил язык BASIC, наверно помнят оператор безусловного перехода GOTO. Почему BASIC? Не только он, конечно, просто в ранних реализациях BASIC (например, Microsoft QuickBasic, входивший в свое время в поставку MS-DOS) он применялся действительно часто. Ведь там не было ни классов, ни операторов обрыва циклов и выполнения вроде Break, Exit, Continue, а также исключений. В современных же языках с полноценными средствами структурного программирования, использование Goto считается крайне дурным тоном, так как затрудняет чтение и делает код непредсказуемым. Доводы против оператора goto четко выписаны в одноименной статье Эдсгера Дейкстры. Но я решил идти не по тропе теоретических изысканий, а показать на практике, что код БЕЗ GOTO может быть не только красивее и логичнее, но и в разы быстрее.
Во время разработки своей новой программы я решил вплотную взглянуть на новый компонент Delphi 2007 — TFileOpenDialog, который инкапсулирует современный диалог открытия файлов в Windows Vista. Те функции, что я в нем увидел, меня приятно удивили. Читать далее…
В дизайне современных приложений меню занимает уже далеко не главное место, уступив первенство панелям инструментов. Такие тенденции наблюдаются например в Internet Explorer 7 и Windows Vista Explorer (Проводник).
Наверняка перед многими когда-либо вставала задача: открыть ряд файлов одного типа, но расположенных в различных подкаталогах.
Как известно, в Windows Vista обычное иерархическое меню Пуск было заменено более удобным «древовидным». Но данное нововведение имеет и обратную сторону: бывает, что это меню работает медленнее, чем привычное старое. И вот, оказывается, почему. Читать далее…
Рано или поздно в любых, более или менее серьезных проектах встает необходимость в автоматической компиляции или компиляции в один шаг. Зачем? Самая элементарная причина: чтобы быстро скомпилировать проект, не открывая его в среде. Например, был разработан крупный проект, включающий не один десяток компонентов, модулей, библиотек. Среда во время разработки сильно обросла посторонними и собственными компонентами и становится трудно различить, какой компонент используется в данном проекте, а какой — нет. Переносимости у проекта в данном случае никакой. На другом компьютере с установленной средой Delphi его не получится скомпилировать: придется переносить и устанавливать все необходимые компоненты, причем вспоминать, какой из них нужен, а какой нет. Это крайне неудобно, а если еще принять во внимание, что данный процесс подвержен ошибкам, то становится совсем невесело.
Многие из нас пользуются мультимедийными или расширенными клавиатурами, где кроме обычных 100 с чем-то клавиш есть клавиши, упрощающие доступ к часто используемым функциям. Например, навигацию в браузере (Home, Back, Forward, Refresh, Stop), проигрывание музыки и фильмов в плеере, вызов калькулятора, почтового клиента и т.д.
Эти дополнительные клавиши действительно часто упрощают вызов постоянно используемых действий. Как же сделать поддержку этих клавиш в Delphi, чтобы пользователю было удобнее пользоваться нашей программой? Читать далее…
