А. Григорьев - О чём не пишут в книгах по Delphi

В принципе, при использовании перекрытого ввода-вывода система может сама взводить указанное программой событие при получении данных почтовым ящиком, но перекрытый ввод-вывод имеет ограниченную поддержку в Windows 9х/МЕ и на почтовые ящики не распространяется. Чтобы приложение могло работать не только в Windows NT/2000/XP, мы не будем применять перекрытый ввод-вывод.

События относятся к именованным объектам, поэтому с их помощью можно синхронизировать разные процессы. В нашем случае первая копия приложения с помощью CreateEventсоздает событие, а последующие копии с помощью OpenEventполучают дескриптор этого события и взводят его. чтобы послать сигнал о появлении данных в почтовом ящике. Для обнаружения этого момента в первой копии приложения создается отдельная нить, которая ожидает событие и, дождавшись, посылает главной форме сообщение (эта нить практически не требует процессорного времени, потому что почти все время находится в режиме ожидания, т.е. квант времени планировщик задач ей не выделяет, по крайней мере, проверка наличие данных в главной нити по таймеру отняла бы больше ресурсов). Это сообщение определяется пользователем и берется из диапазона WM_USER, т.к. его широковещательной рассылки не будет. При получении этого сообщения форма выполняет код, приведенный в листинге 1.49.

// Реакция на получение команд от других экземпляров приложения

procedure TDKSViewMainForm.WMCommandArrived(var Message: TMessage);

var

Letter: string;

begin

// Переводим приложение на передний план

GoToForeground;

// Пока есть команды, читаем их и выполняем

Letter := ReadStringFromMailslot;

while Letter <> '' do

begin

// Анализируем и выполняем команду.

// Команда "s" не требует никаких действий, кроме перевода

// приложения на передний план, поэтому здесь мы ее не учитываем

case Letter[1] of

'e': OpenFile(Copy(Letter, 2, MaxInt), False);

'v': OpenFile(Copy(Letter, 2, MaxInt), True);

end;

Letter := ReadStringFronMailslot;

end;

end;

// Чтение очередного сообщения из почтового ящика

function TDksViewMainForm.ReadStringFromMailslot: string;

var

MessageSize: DWORD;

begin

// Получаем размер следующего сообщения в почтовом ящике

GetMailslotInfo(ServerMailslotHandle, nil, MessageSize, nil, nil);

// Если сообщения нет, возвращаем пустую строку

if MessageSize = MAILSLOT_NO_MESSAGE then

begin

Result := '';

Exit;

end;

// Выделяем для сообщения буфер и читаем его в этот буфер

SetLength(Result, MessageSize);

ReadFile(ServerMailslotHandle, Result[1], MessageSize, MessageSize, nil);

end;

Так как события являются именованными объектами, второй экземпляр приложения мог бы обнаруживать наличие первого не по почтовому ящику, а по событию. Более того, если бы нам требовалось не передавать данные первому экземпляру, а только активизировать его, можно было бы вообще обойтись одним только событием.

Первая копия приложения, получив команду от другой копии, должна вывести себя на передний план. Казалось бы, все просто: с помощью функции SetForegroundWindowмы можем вывести туда любое окно. Однако так было только до Windows 95 и NT 4. В более поздних версиях введены ограничения, и теперь программа не может вывести себя на передний план по собственному усмотрению. Функция SetForegroundWindowпросто заставит мигать соответствующую кнопку на панели задач.

Тем не менее, если программа свернута, команда Application.Restoreне только восстанавливает окно, но и выводит его на передний план, что нам и требуется. Ну а если программа не свернута, то "выливаем из чайника воду и тем самым сводим задачу к предыдущей": сначала сворачиваем приложение с помощью Application.Minimize, а потом разворачиваем его. Цели мы добились — главное окно на переднем плане.

Дело портит только то, что изменение состояния окна сопровождается анимацией: видно, как главное окно сначала сворачивается, а потом разворачивается. Чтобы убрать этот неприятный эффект, можно на время сворачивания/разворачивания окна запретить анимацию, а потом восстановить ее. С учетом этого метод GoToForegroundвыглядит так, как показано в листинге 1.50.

// Перевод приложения на передний план

procedure TDKSViewMainForm.GoToForeground;

var

Info: TAnimationInfo;

Animation: Boolean;

begin

// Проверяем, включена ли анимация для окон

Info.cbSize := SizeOf(TAnimationInfo);

Animation := SystemParametersInfo(SPI_GETANIMATION,

SizeOf(Info), @Info, 0 and (Info.iMinAnimate <> 0);

// если включена, отключаем, чтобы не было ненужного мерцания

if Animation then

begin

Info.iMinAnimate := 0;

SysteParametersInfo(SPI_SETANIMATION, SizeOf(Info), @Info, 0);

end;

// Если приложение не минимизировано, минимизируем

if not IsIconic(Application.Handle) then Application.Minimize;

// Восстанавливаем приложение. При этом оно автоматически выводится

// на передний план

Application.Restorе;

// Если анимация окон была включена, снова включаем ее

if Animation than

begin

Info.iMinAnimate := 1;

SystemParametersInfo(SPI_SETANIMATION, SizeOf(Info), @Info, 0);

end;

end;

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

В этом примере мы создадим "дырявое" окно. Те, кто уже знаком с функцией SetWindowRgn, знает, что сделать "дырку" в окне или придать ему какую-либо другую необычную форму не так уж и сложно. Но мы здесь пойдем дальше: у дырки в нашем окне будет рамка, и пользователь сможет изменять размеры и положение дырки так же, как он может изменять положение и размеры окна. Как это выглядит, показано на рис. 1.14.

Рассмотрим те средства, которые нам понадобятся для реализации этого.

Каждое окно в Windows делится на две области: клиентскую и не клиентскую. Клиентской называется та область, в которой отображается содержимое окна. Неклиентская область — это различные служебные области окна: рамка, заголовок, полосы прокрутки, главное меню и т.п. Положение клиентской части окна относительно неклиентской определяет само окно при обработке сообщения WM_NCCALCRECT. Многие окна (особенно различные элементы управления) вообще не имеют неклиентской части.