Автоматический LOG программы

← →
Shaman_ © (2006-08-08 11:20) [0]

Стоит задача разработать универсальный механизм ведения истории работы с программой. Необходимо на всех формах приложения отслеживать нажатия всех TButton и заносить в историю запись вида:
Открыта форма "TForm.Caption"
На форме "TForm.Caption" нажата клавиша "TButton.Caption"
и.т.д.

Думаю как это лучше организовать одним универсальным методом? Добавлять к кажому TObject событие не подойдет- форм 90 штук, элементов форм - не поддается подсчету. Наверняка уже многие сталкивались и есть свои наработки в этой области.

← →
StriderMan © (2006-08-08 11:24) [1]

способы:
1. сделать свой компонент от TButton, добавив запись в лог. Написать программулину, которая перелопатит в проекте все TButton в *.pas и *.dfm.

2. копать в сторону Application.OnMessage

← →
Shaman_ © (2006-08-08 12:29) [2]

1. - Немного не то
2. - В этом направлении сейчас и копаю

← →
Ketmar © (2006-08-08 12:37) [3]

повесить хук и ловить всё, что надо.

← →
StriderMan © (2006-08-08 12:40) [4]

> Shaman_ © (08.08.06 12:29) [2]

отпишитесь пожалуйста как сделаете. Интересный вопрос.

← →
Loginov Dmitry © (2006-08-08 15:38) [5]

Еще вариант: использовать наследование форм. Обработку сообщений выполнять в процедуре WndProc(), которая объявляется так:

TParentForm = class(TForm)
.....
protected
procedure WndProc(var Message: TMessage); override;
end;

(Вообще, полезая вещь "наследование форм", сильно сокращает объем кода)

← →
DiamondShark © (2006-08-08 16:46) [6]

Интересно, а чем такой лог может быть полезен?

← →
clickmaker © (2006-08-08 16:56) [7]

> DiamondShark © (08.08.06 16:46) [6]
> Интересно, а чем такой лог может быть полезен?

никак не могут прищучить юзера, который лажает, а потом валит все на прграммеров, наверно )

← →
Shaman_ © (2006-08-08 17:35) [8]

DiamondShark [6]
Чем может быть полезен это уже вопрос творческий, а не программерский. В том числе- clickmaker © (08.08.06 16:56) [7] :)

В общем вот пример как реализовал. Все не буду расписывать, просто пишу пример перехвата Caption нажимаемых пользователем TButton

Все делаем через обработку сообщений:
... private procedure MsgHandler(var Msg:TMsg); ... procedure TForm1.FormCreate(Sender: TObject); begin Application.OnMessage := MsgHandler; end; procedure TForm1.MsgHandler(var Msg:TMsg); var CaprionBuffer: PChar; begin case Msg.message of //Перехват нажатия на TButton WM_LBUTTONDOWN: begin //Получаем Caption кнопки GetMem(lpBuffer,255); GetWindowText(msg.hwnd,CaprionBuffer,255); //Вот собственно и все ShowMessage("Перехвачено нажатие кнопки ""+CaprionBuffer+"""); end; //Если нужно перехватить другое действие пользователя //то соответственно обрабатываем здесь нужное сообщение ... end; end;

Это естественно пример. В реале весь код получился на ~300 строк и еще не дописан :)

← →
Loginov Dmitry © (2006-08-08 17:44) [9]

А я вот решил сабж с помощью читерства :)

unit BntLoggerUnit; {$define UserHook} interface uses Windows, Messages, SysUtils, StdCtrls, Buttons, ComCtrls; {$ifdef UserHook} type TMyButton = class(TButton) public procedure Click; override; end; TMySpeedButton = class(TSpeedButton) public procedure Click; override; end; TMyToolButton = class(TToolButton) public procedure Click; override; end; TButton = class(TMyButton); TSpeedButton = class(TMySpeedButton); TToolButton = class(TMyToolButton); procedure WriteToLog(AText: string); {$endif UserHook} implementation {$ifdef UserHook} procedure WriteToLog(AText: string); begin // Здесь выполняй запись в лог-файл end; { TMyButton } procedure TMyButton.Click; begin inherited; Beep; WriteToLog(Caption); end; { TMySpeedButton } procedure TMySpeedButton.Click; begin inherited; Beep; WriteToLog(Caption); end; { TMyToolButton } procedure TMyToolButton.Click; begin inherited; Beep; WriteToLog(Caption); end; {$endif UserHook} end.

Добавь имя данного модуля в список USES секции INTERFACE каждого модуля формы. Оно должно быть в конце списка.

P.S.: enjoy ;)

← →
Loginov Dmitry © (2006-08-08 17:46) [10]

> Application.OnMessage := MsgHandler;

Мой совет: никогда так не делай. Для этих целей в Дельфи есть компонент TApplicationEvents.

← →
Shaman_ © (2006-08-08 18:02) [11]

Loginov Dmitry © (08.08.06 17:46) [10]

Опасения основаны на том, что обработчик может быть только 1? Или может есть еще какие негативные стороны?

← →
Loginov Dmitry © (2006-08-08 18:37) [12]

Вот именно! Только 1. Это ни есть гуд, так как может понадобиться обработка OnMessage в совершенно разных местах программы. А если ты делашь так
Application.OnMessage := MsgHandler;
то все компоненты TApplicationEvents перестают работать.

← →
Shaman_ © (2006-08-08 18:48) [13]

Можно выстроить цепочку на передачу сообщения от одного обработчика к другому, но в целом согласен, лишняя, ненужная замороченность получается

← →
Гутан Орангович (2006-08-09 02:01) [14]

> Loginov Dmitry © (08.08.06 17:46) [10]
> > Application.OnMessage := MsgHandler;Мой совет: никогда
> так не делай. Для этих целей в Дельфи есть компонент TApplicationEvents.
>

> Loginov Dmitry © (08.08.06 18:37) [12]
> Вот именно! Только 1. Это ни есть гуд, так как может понадобиться
> обработка OnMessage в совершенно разных местах программы.
> А если ты делашь такApplication.OnMessage := MsgHandler;
> то все компоненты TApplicationEvents перестают работать.
>

Своя обработка OnMessage совершенно не мешает иметь сколько угодно других обработчиков.

> Гутан Орангович (09.08.06 02:01) [14]
> Своя обработка OnMessage совершенно не мешает иметь
> сколько угодно других обработчиков.

А самому проверить не судьба?

> Loginov Dmitry © (09.08.06 07:51) [15]

можно же сохранить указатель на стандартный обработчик перед переопределением OnMessage, и в своем, после нужных действий вызывать стандартный. Чем это плохо?

← →
Гутан Орангович (2006-08-09 09:28) [17]

> Loginov Dmitry © (09.08.06 07:51) [15]
> > Гутан Орангович (09.08.06 02:01) [14]> Своя обработка
> OnMessage совершенно не мешает иметь > сколько угодно других
> обработчиков.А самому проверить не судьба?

И проверять нечего. Это тривиально.

← →
Loginov Dmitry_ (2006-08-09 10:32) [18]

> и в своем, после нужных действий вызывать стандартный

Что еще за "стандартный" обработчик? Таких здесь нету. Если имеется ввиду старый обработчик, тогда ладно. Но предпочтительнее все же не вешать собственный обработчик, а использовать механизм ApplicationEvents.

← →
Гутан Орангович (2006-08-09 10:38) [19]

Каждому овощу свое время. В том числе и OnMessage и TApplicationEvent.

Не имеет смысла говорить о том, что один метод лучше другого.
Это всего лишь дело вкусовых рецепторов каждого.

Автоматический LOG программы Найти похожие ветки