Eugene Kotlyarov wrote:
Does anyone have ideas why TIcsWndControl.ProcessMessages could
hang sometimes when socket is used in separate thread?
>>
>>> Have you followed the rules: create TWSocket within the thread's
>>> execute method OR call ThreadAttach ?
>>
>> Yes socket is created wi
> Looks like you try to workaround the asynchronous nature of TWSocket
> which were a bad idea. Where do you call this and what do you want
> to achieve?
Waiting for all sockets to close cleanly may be necessary before
terminating an application, to ensure continuously streamed data is not
lost.
On 7/13/2011 7:23, Francois PIETTE wrote:
AFAIR the workaround was to do your own ARP request first in order
to check whether the destination exists or not, utilizing the IP
Helper API.
Yes, that what I did.
How can I confirm that this is what's happening with me?
In my case, the block
AFAIR the workaround was to do your own ARP request first in order
to check whether the destination exists or not, utilizing the IP
Helper API.
Yes, that what I did.
How can I confirm that this is what's happening with me?
In my case, the blocking was occuring in the main thread. TO see i
On 7/13/2011 11:46, Francois PIETTE wrote:
AFAIR the workaround was to do your own ARP request first in order
to check whether the destination exists or not, utilizing the IP
Helper API.
Yes, that what I did.
How can I confirm that this is what's happening with me?
In my case, the blocki
Angus Robertson - Magenta Systems Ltd wrote:
>> Looks like you try to workaround the asynchronous nature of TWSocket
>> which were a bad idea. Where do you call this and what do you want
>> to achieve?
>
> Waiting for all sockets to close cleanly may be necessary before
> terminating an applicatio
Merijn Bosma wrote:
>>> Now the interesting part is that on another Windows 7 machine the
>>> call to closesocket() is not blocking. When looking with wireshark I
>>> see that the 3 arp requests are sent, but closesocket() simply does
>>> not wait for them.
>>
>> I'm happy you see the same behavio
> > Waiting for all sockets to close cleanly may be necessary before
> > terminating an application, to ensure continuously streamed data
> > is not lost.
>
> I do not see a reason why one must wait in a loop processing
> messages with calls to sleep()in order to achieve that, that's
> often a
On 7/13/2011 12:13, Arno Garrels wrote:
Merijn Bosma wrote:
Now the interesting part is that on another Windows 7 machine the
call to closesocket() is not blocking. When looking with wireshark I
see that the 3 arp requests are sent, but closesocket() simply does
not wait for them.
I'm happy you
I don't think it is a hardware issue. It is likely a software issue. One
of the layer between winsock and the network card has a bug. That is why
you see it on one computer and not another.
Determining which layer is faulty will be a difficult task ! I don't know
what to say to help you :-(
On 7/13/2011 13:17, Francois PIETTE wrote:
I agree that it's not a hardware issue. Do you know what layers are
there approximately? I've already ruled out the driver of the NIC
itself.
I was mentioning the chipset since there is also software applicable
(driver of the chipset). Also strange is
Thanks for the links, it's an interesting read. What still goes beyond me
though, is that all I see in the diagram seems to be hardware independent
stuff, so how could it ever happen that it behaves different on different
machines?
That's the point: IMO the issue comes from the software which
On 7/13/2011 15:07, Francois PIETTE wrote:
Thanks for the links, it's an interesting read. What still goes
beyond me though, is that all I see in the diagram seems to be
hardware independent stuff, so how could it ever happen that it
behaves different on different machines?
That's the point:
On 7/13/2011 15:43, Merijn Bosma wrote:
On 7/13/2011 15:07, Francois PIETTE wrote:
Thanks for the links, it's an interesting read. What still goes
beyond me though, is that all I see in the diagram seems to be
hardware independent stuff, so how could it ever happen that it
behaves different on
I just made a nice discovery. I found out that I had another machine (same
model, but mini tower) sitting here somewhere. I checked, and the problem
does not show there.
So I took the hard drive from the not working one and put it in the
working one and it booted nicely (since hardware is iden
Angus Robertson - Magenta Systems Ltd wrote:
>>> Waiting for all sockets to close cleanly may be necessary before
>>> terminating an application, to ensure continuously streamed data
>>> is not lost.
>>
>> I do not see a reason why one must wait in a loop processing
>> messages with calls to sleep
Greetings.. I have been using the ICS package for a few weeks now and
find it very nice to use.
I have an old application that was passed to me to maintain... (aka, you
are the support... we lost the source, good luck)
Well up until recently things went well.. to a point. Now alot of
changes
Well I can only make it work if I use the edit options and manually dink
with these until it works.. then if i resize the form, do it all over
again. Change the font size to be smaller or bigger, and tweak each other
property until all is good. For the end user, that wont be acceptable.
Is ther
18 matches
Mail list logo
