hi all,
1.
my program do allot of stuff in the background while sometimes shows the user few of feedback (such as progress bar)
i came to conclusion that when i minimize my app to bar the application finish its job like 70% faster!.
why is the reason for that? and is there a way to get around it? (i dont want to auto minimize every time i do something).
at WM_PAINT I return (no drwaing), what message could slow things down?
* the main calcs are done in a worker thread.

2. when i do use the minimize with api ShowWindow and flag SW_MINIMIZE once done -> SW_MAXIMIZE my dialog doesn't become focused, how would i make it active when i maximized?

thnx
Posted on 2003-09-12 09:41:35 by wizzra
2. Make a call to SetForeGroundWindow after the ShowWindow

Don't know about #1.
Posted on 2003-09-12 10:20:59 by JimmyClif
thnx JimmyClif :)
Posted on 2003-09-12 10:48:02 by wizzra
If you do not call ValidateRect or BeginPaint upon getting WM_PAINT, it will not be cleared and you'll get the message again. You can pass this message to DefWindowProc as it will validate the update region.
Posted on 2003-09-12 12:52:05 by Sephiroth3
hm..
this doesn't seems to get the job working.
invalidating the area/region will not solve the prob, the speed remains the same while if i minimize
the app and maximize right away, the speed jumps to like 80% faster (i see the progerss bar 3% -> 20% +-)
it seems like when we minimize no messages are sent to the client area and stuff get fast?
Posted on 2003-09-12 15:30:11 by wizzra
I think hen the app is minimized all WM_PAINT messages merge into one, that is processed when the app is restored (and all the client area must be redrawn). If your working thread is causing a time consuming redraw every time, that CPU usage of your GUI thread is slowing down everything... perhaps you should think of a way to consume less resources in your drawing proc. Perhaps just update the position of the progress bar every 5% or so. Also make sure you are not redrawing more than you need (i.e. don't repaint something that was OK like that. If the progress bar is already showing the position you wanted, don't set it again).
Posted on 2003-09-12 17:04:03 by QvasiModo
hi QvasiModo & all.

i'll put a visual of my prog to show u the spots that gets updated (repainted)
that may cause the slow down.
i never coded such task to remove specific regions/rects from being updated but than
i must keep the user updated as thats what my progs need to.
hope to get some more ideas.
thnx
Posted on 2003-09-12 19:34:55 by wizzra
I usally use separate thread when there is some heavily work to be done in dialogs.
This way dialog does not block and its repainted more oftenly.
Maybe you should try that approach.
Posted on 2003-09-12 20:01:44 by Mikky
heya,
well, i do use thread :) but the paint messages slow it down :(
Posted on 2003-09-13 03:45:26 by wizzra
mmm, maybe can help use PeekMessage instead of GetMessage.


Also i am thinking that you have some 'global' variable that say you if you are doing your 'large operation', or if no, have a var that hold the state filtering for the messages.


Message Filtering
An application can choose specific messages to retrieve from the message queue (while ignoring other messages) by using the GetMessage or PeekMessage function to specify a message filter. The filter is a range of message identifiers (specified by a first and last identifier), a window handle, or both. GetMessage and PeekMessage use a message filter to select which messages to retrieve from the queue. Message filtering is useful if an application must search the message queue for messages that have arrived later in the queue. It is also useful if an application must process input (hardware) messages before processing posted messages.

The WM_KEYFIRST and WM_KEYLAST constants can be used as filter values to retrieve all keyboard messages; the WM_MOUSEFIRST and WM_MOUSELAST constants can be used to retrieve all mouse messages.

Any application that filters messages must ensure that a message satisfying the message filter can be posted. For example, if an application filters for a WM_CHAR message in a window that does not receive keyboard input, the GetMessage function does not return. This effectively "hangs" the application.



And this one from PeekMessage. Is the last parameter.

wRemoveMsg
Specifies how messages are handled. This parameter can be one of the following values.
PM_NOREMOVE
Messages are not removed from the queue after processing by PeekMessage.
PM_REMOVE
Messages are removed from the queue after processing by PeekMessage.
You can optionally combine the value PM_NOYIELD with either PM_NOREMOVE or PM_REMOVE. This flag prevents the system from releasing any thread that is waiting for the caller to go idle (see WaitForInputIdle).

By default, all message types are processed. To specify that only certain message should be processed, specify one or more of the following values.

PM_QS_INPUT
Windows 98/Me, Windows 2000/XP: Process mouse and keyboard messages.
PM_QS_PAINT
Windows 98/Me, Windows 2000/XP: Process paint messages.
PM_QS_POSTMESSAGE
Windows 98/Me, Windows 2000/XP: Process all posted messages, including timers and hotkeys.
PM_QS_SENDMESSAGE
Windows 98/Me, Windows 2000/XP: Process all sent messages.



Then when you start doing your operation, you need modify the variable that hold the status of filtering for some like:

%define ALL_MESSAGES PM_QS_INPUT | PM_QS_PAINT | PM_QS_POSTMESSAGE | PM_QS_SENDMESSAGE
%define NO_PAINT_MESSAGES PM_QS_INPUT | PM_QS_POSTMESSAGE | PM_QS_SENDMESSAGE

and do a mov dword, ALL_MESSAGES in the start of your aplication and after the operation is terminated and do a mov dword, NO_PAINT_MESSAGES when you start your prosses, remember that you ned that the value of varOfStateMsgFiltering need be preserved and only changed by the thread (when begin and when ends), this is a global var i think.

---- The varOfStateMsgFiltering is pased to PeekMessage----

I dont know much about this, but hope this help.

Nice day.
Posted on 2003-09-13 09:52:27 by rea
thnx hgb i will look at it! :)
Posted on 2003-09-13 10:39:28 by wizzra
Just checking the obvious has been covered: the worker thread should post messages to the GUI thread, not send them. SendMessage (and all APIs that use it implicitly) block the sender thred until the message has been processed.
In case you can't avoid some calls to SendMessage, remember there's an API to release the calling thread in that case (I don't remember the name of it, but search in MSDN functions related to message handling and you will find it).
Posted on 2003-09-13 11:10:17 by QvasiModo
hi QvasiModo,
Posting Messages (PostMessage) will actually makes things even slower.
the gui will be frozen and no speedup in any case.
do i need to process them right after i post them?



loop_in_Thread:
..
;do operations
invoke PostMessage ... addr mytext
invoke PostMessage ... PBM_SETSTEP,1,0
...
...
; should i process the messages here?
loop loop_in_Thread


as i said i never works with such prob so i aint that good in messages processing.dispatching.
so i still trying to find something that works.
thnx
Posted on 2003-09-13 12:19:43 by wizzra
How often do you update the progressbar? I once did a program that processed several thousands of files and when I changed the progressbar so it was only updated once per one thousen files, I got a 50% speed increase.
Posted on 2003-09-13 12:31:56 by Delight
hi,
I update the progress bar every time (at the end of the loop.)
mabye i will update the progress bar when a 1% changes only?

i also looked at the internet to find some uses of the PeekMessage in games,



MSG mssg;

// prime the message structure
PeekMessage( &mssg, NULL, 0, 0, PM_NOREMOVE);

// run till completed
while (mssg.message!=WM_QUIT) {

// is there a message to process?
if (PeekMessage( &mssg, NULL, 0, 0, PM_REMOVE)) {

// dispatch the message
TranslateMessage(&mssg);
DispatchMessage(&mssg);

} else {

// create the Thread here
}
}


do think this is a good sulotion?
wizzra.
Posted on 2003-09-13 12:40:14 by wizzra

Perhaps just update the position of the progress bar every 5% or so. Also make sure you are not redrawing more than you need (i.e. don't repaint something that was OK like that. If the progress bar is already showing the position you wanted, don't set it again).

:grin:
Don't want to say "I told you so", but you should read a little more carefully...
Yes, you shouldn't update unless you have to. Try to find a way to update as less as possible.
Posted on 2003-09-13 13:41:30 by QvasiModo

hi QvasiModo,
Posting Messages (PostMessage) will actually makes things even slower.
the gui will be frozen and no speedup in any case.
do i need to process them right after i post them?

I am puzzled at this. :confused:

This is what I figured about your program. You have 2 threads, a "worker" and a "GUI". Th GUI is perhaps the one first created by the system when your process starts. The Worker is created by GUI at some point (perhaps at WM_CREATE processing?). Then GUI just sits there and wait for messages (the message loop), and Worker does it's stuff and
updates the bar with SendMessage.

In this context, replacing SendMessage with PostMessage should work just fine, in fact should work better. When PostMessage is called, the message is stored in GUI's message queue, and Worker keeps... well... working :) . They GUI picks up that message and process it while Worker is doing something else (that's the point of all this), so they don't lock each other. This happens because Worker is just posting the messages for GUI to process, so this works in two different loops.

If SendMessage is used, Worker has to wait for GUI to finish processing, so it's almost the same as having a single thread.

Am I missing something? Naturally this is a simplified version, but I wanted to picture the synchronization in messages between this two threads.
Posted on 2003-09-13 13:46:57 by QvasiModo
QvasiModo,
WOW!! i got it to work finally!!! you we're right, i used PostMessage and i added 1 thing to my message loop that made that boost (apperantly i forgot about it :D)



while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(hWnd, hAccel, &msg))
{
TranslateMessage (&msg);
DispatchMessage (&msg);
}
else DispatchMessage (&msg); // forgot to add this line!!!
}


hm.. what i need to fix now is that PostMessage wont show text on my labels.
hm... from msdn about PostMessage:

"make sure that the message parameters do not include pointers.
Otherwise, the functions will return before the receiving thread has had a chance to process the message "

hm..than i guess sending text (variable) won't work :( any other work around?

anyway,
thank you very much all on your help!!!
finally insted of w8ting 10min, i can w8 13sec :D
Posted on 2003-09-13 15:13:26 by wizzra

QvasiModo,
WOW!! i got it to work finally!!! you we're right, i used PostMessage and i added 1 thing to my message loop that made that boost (apperantly i forgot about it :D)



while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(hWnd, hAccel, &msg))
{
TranslateMessage (&msg);
DispatchMessage (&msg);
}
else DispatchMessage (&msg); // forgot to add this line!!!
}


I'm glad it works! :alright:
One suggestion:


while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(hWnd, hAccel, &msg))
{
TranslateMessage (&msg);
}
DispatchMessage (&msg);
}

hm.. what i need to fix now is that PostMessage wont show text on my labels.
hm... from msdn about PostMessage:

hm..than i guess sending text (variable) won't work :( any other work around?

anyway,
thank you very much all on your help!!!
finally insted of w8ting 10min, i can w8 13sec :D

It should work... perhaps you're using a local variable? Bear in mind that locals are gone on proc return, so you can't use them with asynchronous calls (like PostMessage). Perhaps at the time the message gets processed by the recipient, the local memory was gone.
Posted on 2003-09-15 17:58:31 by QvasiModo
hi,

hm, i did use local variable although using a global var will not work.
i send the message like this:


PostMessage(GetDlgItem(mainhWnd,IDC_MESSAGEX),WM_SETTEXT,0,(LPARAM)Buffer);


thus the return value is false on controls that i tried: label control / edit control
Posted on 2003-09-15 23:53:06 by wizzra