> This is from the latest snapshot of ICS V8.
> 
> procedure TIcsTimer.UpdateTimer;
> begin
>     KillTimer(FIcsWndControl.Handle, UINT_PTR(Self));
>     if (FInterval <> 0) and FEnabled and Assigned(FOnTimer) then
>         if SetTimer(FIcsWndControl.Handle,
>                     Cardinal(Self), FInterval, nil) = 0 then 
> begin <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>             FEnabled := FALSE;
>             raise EIcsTimerException.Create('No more timers');
>         end
>         else
>             FLastEvent := IcsGetTickCount;
> end;
> 
> It should be:
> 
>    NativeUInt(Self), FInterval, nil) = 0 then begin 

Or UINT_PTR(Self)) as in the previous line.  

function SetTimer(hWnd: HWND; nIDEvent: UIntPtr; uElapse: UINT;
  lpTimerFunc: TFNTimerProc): UIntPtr; stdcall;
function KillTimer(hWnd: HWND; uIDEvent: UIntPtr): BOOL; stdcall;

> 1.       Do I really have the latest version of the file?

Yes.

> 2.       If so, and this bug exists, it begs the question: does 
> anybody use ICS in a 64-bit application? :-)

When I build new releases, I check all the runtime units will build
under the 64-bit compiler, and more rarely testing a couple of samples
under 64-bit, but I personally don't have any of my own 64-bit
applications which is how intensive testing of most ICS components is
done, on live servers and public applications.

There are few instances where 64-bit applications are beneficial,
unless you are processing massive amounts of data in memory, or writing
DLLs to interact with other 64-bit applications. 

I know one ICS developer that builds 64-bit servers since certain
customers think they are better, but not many others.  

Angus


-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to