Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Timer problem

Status
Not open for further replies.

SonicChen

Programmer
Feb 14, 2004
62
CN
i write my own Timer
Code:
TMyTimer = class
  ...
  procedure TimerCallBack(Handle:THandle,
    Msg:LongWord,TimerID:LongWord,Time:LongWord);
    stdcall;export;
end;
constructor TMyTimer.Create(ACon: TWinControl);
begin
  FTimerID := SetTimer(Handle,GetNewTimerID,
    Interval, @TMyTimer.TimerCallBack);
end;
procedure TMyTimer.TimerCallBack(...);
begin
  ...
end;
everything is ok but TimerCallBack never be call, why? what's the problem?
anybody help me!

way to gold shines more than gold
 
this logic since you can't use a class method for a callback procedure. Why don't you use the standard TTimer object of delhpi? It has anything you'll need...



--------------------------------------
What You See Is What You Get
 
yes i use Delphi TTimer now.
but i heard that TTimer use hwnd resource.
i write mouse hover event myself for delphi no offord.
each wincontrol has hover event and hover event use timer to detect, so every wincontrol has a timer hwnd.
at last we need two hwnd in every wincontrol.
i dont' know whether it matters.

way to gold shines more than gold
 
1) A timer uses a handle too, so you are gaining nothing.

2) Use only one timer to check all your "hovered" objects, sending a signal to every one in every timer tick. Keep your "hovered" objects in a TObject list of sorts, so you can broadcast the tick signal efficiently.

buho (A).

 
yes i found mouse.capture can give the win handle who capture mouse so i can postmessage directly to that control.
but i still worry about the frequent timer will slower the application.

way to gold shines more than gold
 
Thats depend in how many visual objects are you checking, how you are checking the collection and basically what your are doing in a "hit".

You are in an interesting scenario: if you move the checking code to a worker thread you will need to synchronize with the main VCL thread to check your objects and change their graphic state, so it is possible a multithred approach will be worse than having your code in the main thread.

I doubt the performance loss being noticeable if your checking code is something like

- get the cursor position
- for each object
-- if the cursor is inside the object coordinates
-- unhover the hovered object and hover this one

and you are "ticking" every 250 mSecs and no less

Well... if the hover/unhover routines are doing "funny" heavy graphic things it can be noticeable. The other code is mainly irrelevant.

buho (A).
 
yeah, really good opinion.
the following is my pseudocode:
Code:
timer.interval = 10; // ms
timer.callback = timerproc;
var lastpos; // last mouse pos
    lasthwnd; // last mouse capture hwnd
    count=0; // count check times
procedure timerproc;
begin
  if lasthwnd<>hwnd then
    postmessage(hwnd, mouse enter event);
    postmessage(lasthwnd, mouse leave event);
  if lastpos<>pos then
    count++;
  else
    count=0;
  if count=hovercount then // in fact hovercount =
                           // hovertime/interval
    get modifier key state;
    postmessage(hwnd, mouse hover event); // with modifier
                                             and pos
  lasthwnd = hwnd;
  lastpos = pos;
end;
timer good but i have some trouble in message.
i dont' know how to typecast a TShiftState var to WParam


way to gold shines more than gold
 
TShiftState is a set, you can't cast it to a simple type.

You can

a) use code like the one in
(but it is time consuming)

b) "absolute fake" the set to a word:

Code:
function MakeWParam(SS : TShiftState) : word;
  var
    w : word absolute SS;
  begin
    MakeWParam := w;
  end;

c) blindly move it to a word

Code:
var
   w  : word;
   SS : TShiftState;
begin
   Move(SS, w, 1);

Some pointer tricks are possible too, but I think you'll get the problem solved with this ones.

buho (A).
 

------
W A R N I N G
------


Code:
var
   w  : word;
   SS : TShiftState;
begin
   Move(SS, w, [COLOR=red][b]2[/b][/color]);

buho (A).
 
yes, i know your good method, that's what i have been trying.
but recently i found one demo "DockWin" affored by delphi 7
it override the CM_DOCKCLIENT message handle like this:
Code:
  procedure CMDockClient(Message: TCMDockClient); 
    message CM_DOCKCLIENT;
  TCMDockClient = packed record
    Msg: Cardinal;
    DockSource: TDragDockObject;
    MousePos: TSmallPoint;
    Result: Integer;
  end;
we can compare to Message: TMessage
Code:
 TMessage = packed record
    Msg: Cardinal;
    case Integer of
      0: (
        WParam: Longint;
        LParam: Longint;
        Result: Longint);
      1: (
        WParamLo: Word;
        WParamHi: Word;
        LParamLo: Word;
        LParamHi: Word;
        ResultLo: Word;
        ResultHi: Word);
  end;
i really douted in that DockSource is a big class reference.
does it's length equal to LongWord? and can we typecast class reference to LongWord;

way to gold shines more than gold
 
An object is a pointer and you can cast it to an untyped pointer or to any 4 bytes integer... or store it in any 4 bytes adress space.

buho (A).

 
oh yeah.
really good information.
so we can transmit big data between tow processes by this way?

way to gold shines more than gold
 


Nope.

You can send a pointer (casted as a dword) from process A to process B... but the address space pointed by it is still in process A, so any attmpt to derreference the pointer in process B will end in a memory fault.

To send reasonable amounts of data (handful of kbytes) between processes, the best way is WM_COPYDATA, check it in the SDK.

To send big amounts of data, you can use memory mapped files (we have a thread about laying around somewhere in the forum) or to resort to sockets or pipes (personally I hate pipes to death).

buho (A).
 
i'm puzzled by the knowledge u remarked.
can i get all knowledge u remarked from MSDN?
i'm a chinese program, MSDN really not comfortable to me,hehe .

way to gold shines more than gold
 


Actually, MSDN and the SDK help files Delphi install are useful basically if you know what you are searching for.

Say, if you want to remember how WM_COPYDATA works, MSDN and the SDK are a real help, but if you are trying to found what options you have for interprocess comunication, they are not so helpful.

The best ways to knowledge are still good books and experience, the third best is "googling" the newsgroups and fora (like Tek-Tips). Most of the times NGs/fora will give you better answers than MSDN. (NGs/fora are driven by the experience the programmers have while MSDN is written in a somewhat abstract informational paradigm).

buho (A).
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top