Major BUG in Delphi, while clicking on a Titlebar

[Meni Meller]

Hi,

I have an application which i have written and it deals with
communication.
for some reason I found out that when a user clicks on the title bar,
and keeps the mouse down, my communication just stops.
I made it easier...
just created a new applciation,
put a timer on it, and in the timer's event I wrote something like
Label1.Caption := TimeToStr (now) ;
ran it, it worked and showed me the time.
if i clicked on the titlebar, the timer event didnt occur... and i got
no updates to the screen...
and i know that the timer event didnt occur --> for sure.
it was not just that there were no updates or something like that..
please help me as soon as possible ...

and if u may, reply to both email and NG.

Regards,

Meni .

[Rick Rogers [TeamB]]

In article <66oed3$1n...@forums.borland.com>, Meni Meller wrote:
> for some reason I found out that when a user clicks
> on the title bar

*sigh*

Once again, someone has reported a "Major BUG in Delphi" which isn't a bug
and has nothing to do with Delphi.

The behavior you've described is present in all Windows applications.
Windows is base on co-operative, not pre-emptive, multi-tasking. When a user
clicks in the non-client area of a window, Microsoft Windows doesn't
co-operatively share, which means until the user releases the mouse, no
other Windows messages are processed.

--
Rick Rogers (TeamB) | Fenestra Technologies

[Krasimir Stoyanov]

Hello,

This is not a bug in Delphi. I've noticed other application have the same behavior.
Try Netscape Communicator.
Also try when the form is maximized.

Regards,
Krasimir Stoyanov

[Erik Turner]

This is not a bug. This is a Windows "feature".

If you are using Windows 95, create a seperate thread
to handle communication (or whatever).

By the way, your timer probably did not stop. TTimer posts
a message to your window and your window isn't responding
to "low-priority" messages, you don't see any results until you
release the window title bar.

--
Erik Turner
etu...@nospam.metrolink.net (remove "nospam." to reply)

Meni Meller wrote in message <66oed3$1n...@forums.borland.com>...

[Rick Rogers [TeamB]]

In article <66oed3$1n...@forums.borland.com>, Meni Meller wrote:

> Major BUG

*sigh* You need to contribute $1 to the TeamB retirement fund for
reporting a "major Delphi bug" which is neither related to Delphi nor a
bug.

[Peter Below]

Meni,

that is Windows getting in your way. If you hold down the mouse on the
caption bar or drop down a menu Windows goes into a tight message loop of
its own that only processes mouse messages. This loop runs until the mouse
goes up again, so any processing that depends on the main message loop will
stop while the mouse is down. You get informed when such a loop is entered
or terminated by messages Windows sends to your form: WM_ENTERMENULOOP,
WM_EXITMENULOOP, WM_ENTERSIZEMOVE, WM_EXITSIZEMOVE. I think you could
cancel the operation by sending a WM_CANCELMODE to the form in response to
the WM_ENTER* messages but that will impact the corresponding functions of
your application. Mouse down events on the non-client area can also be
trapped by handing messages like WM_NCLBUTTONDOWN and not passing them on
to the inherited handler while your app is in a sensitive state.

Peter Below (TeamB) 10011...@compuserve.com)