mirrors/fltk
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed indentation and comments (src/Fl_Win32.cxx).

Browse Source 
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6667 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This commit is contained in:
Albrecht Schlosser 2009-02-21 10:01:57 +00:00
parent d060bcbdfd
commit f04bc53457
1 changed files with 119 additions and 117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
src/Fl_win32.cxx
View File

@ -76,21 +76,23 @@
//
// USE_ASYNC_SELECT - define it if you have WSAAsyncSelect()...
// USE_ASYNC_SELECT is OBSOLETED in 1.3 for the following reasons:
/**
This feature was supposed to provide an efficient alternative to the current polling method,
but as it has been discussed (Thanks Albrecht!) :
- the async mode would imply to change the socket select mode to non blocking mode,
this can have unexpected side effects for 3rd party apps, especially if it is set on-the-fly when
socket service is really needed, as it is done today and on purpose, but still
the 3rd party developer wouldn't easily control the sequencing of socket operations.
- Finer granularity of events furthered by the async select is a plus only for socket 3rd party impl.,
it is simply not needed for the 'light' fltk use we make of wsock, so here
it would also be a bad point, because of all the logic add-ons necessary for
using this functionality, without a clear benefit.
/*
This feature was supposed to provide an efficient alternative to the current
polling method, but as it has been discussed (Thanks Albrecht!) :
- the async mode would imply to change the socket to non blocking mode.
This can have unexpected side effects for 3rd party apps, especially
if it is set on-the-fly when socket service is really needed, as it is
done today and on purpose, but still the 3rd party developer wouldn't easily
control the sequencing of socket operations.
- Finer granularity of events furthered by the async select is a plus only
for socket 3rd party impl., it is simply not needed for the 'light' fltk
use we make of wsock, so here it would also be a bad point, because of all
the logic add-ons necessary for using this functionality, without a clear
benefit.
So async mode select would not add benefits to fltk, worse,
it can slowdown fltk because of this finer granularity and instrumentation code
to be added for async mode proper operation, not mentioning the side effects...
So async mode select would not add benefits to fltk, worse, it can slowdown
fltk because of this finer granularity and instrumentation code to be added
for async mode proper operation, not mentioning the side effects...
*/
// dynamic wsock dll handling api:
@ -388,7 +390,7 @@ int fl_wait(double time_to_wait) {
time_to_wait = 0.0;
// if there are no more windows and this timer is set
// to FOREVER, continue through or look up indefinetely
// to FOREVER, continue through or look up indefinitely
if (!Fl::first_window() && time_to_wait==1e20)
time_to_wait = 0.0;
@ -401,7 +403,7 @@ int fl_wait(double time_to_wait) {
fl_lock_function();
// Execute the message we got, and all other pending messages:
// have_message = PeekMessage(&fl_msg, NULL, 0, 0, PM_REMOVE);
// have_message = PeekMessage(&fl_msg, NULL, 0, 0, PM_REMOVE);
have_message = PeekMessageW(&fl_msg, NULL, 0, 0, PM_REMOVE);
if (have_message > 0) {
while (have_message != 0 && have_message != -1) {
@ -1424,9 +1426,9 @@ Fl_X* Fl_X::make(Fl_Window* w) {
wcw.cbSize = sizeof(WNDCLASSEXW);
RegisterClassExW(&wcw);
class_name_list.add_name((const char *)class_namew);
}
}
// const char* message_name = "FLTK::ThreadWakeup";
// const char* message_name = "FLTK::ThreadWakeup";
// if (!fl_wake_msg) fl_wake_msg = RegisterWindowMessage(message_name);
if (!fl_wake_msg) fl_wake_msg = RegisterWindowMessageW(message_namew);