> 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
