How can I abort a loop just through pressing a button? I'm searching for something like Delphi's "application.processmessages"


/Delight
Posted on 2001-09-04 07:41:55 by Delight
im not sure what you're trying to do here...

1. exit a loop
2. break a project (ctrl+break in visual basic)
3. "unfreeze" a loop (doevents in visual basic)

any of those?
Posted on 2001-09-04 08:11:09 by vcv
just check msg.message, and then if it is true, .break



.while 1
.if msg.message == WM_KEYUP
.break
.endif
.endw
Posted on 2001-09-04 08:12:53 by Kenny
I'm sorry if wasn't clear enough. I'm have a procedure that is drawing some stuff on the screen, and when I click on a button, I would like to abort the loop in the proc. I can't do this now because the whole app is freezed while processing the loop.


/Delight
Posted on 2001-09-04 08:24:39 by Delight
Delight,

To do what you need, you will have to put either the drawing operation or the button to stop it into a seperate thread. What is happening at the moment is that you are using the thread to draw with and it will not respond until its finished.

Regards,

hutch@pbq.com.au
Posted on 2001-09-04 08:32:14 by hutch--
I hate to say this, but I think your only option is to create a seperate thread for drawing on the screen, this will prevent the whole program from freezing I believe. As far as stopping when a button is clicked, well. Create a global variable, when the button is clicked, set it to a certain value, in the loop for drawing on the screen, .BREAK .IF variable==value something like that (assuming you're using masm).

edit: hutch beat me to it >:|
Posted on 2001-09-04 08:35:29 by vcv
OK. I'll try that.

Thanks!


/Delight
Posted on 2001-09-04 08:40:32 by Delight
You can also use PeekMessage and a modifyied message loop to do a background draw operation.

this has the advantage that your messages are still processed while you draw and you can stop the draw based on a global flag variable

And its easyer to do then Threads ;)

Threads can be tricky and slow sometimes ...
Posted on 2001-09-04 14:10:58 by BogdanOntanu
Bogdan, redesigning your message loop this way is not always possible,
eg if you have some *very* lengty operations you need to perform.
Sure, threads can be tricky, but better get a firm grip of them, as
they are a very useful tool. And the only way to put multi-processor
systems to good use :).

Now, it sounds like the problem in question could be solved via
modifying the message loop, and it wouldn't be a too bad way to
handle it. For longer operations, however, run the "lengthy" task
in a separate thread. You can use TerminateThread to abort a thread,
but beware that this is pretty brutal, and a "check global variable"
approach is desirable, so you can perform any necessary cleanup.
Posted on 2001-09-04 15:02:30 by f0dder
Modifying a message loop using PeekMessage can be used for ANY kind of background operations for any length...We used it a lot for our GDI and first 2 DirectX versions of HE with no problem whatsoever... we changed that for reasons of Game Programming and Design and not for technical reasons

the only problem is that code is not totally separated from the main thread like in threads, because of this code separation threads look easyer to use for lazy programmers...but they are not...tere is a common missconception betwwen "advanced programmers" that one should use threads with ease...

1.Any Thread make your App go 1/2 speed from what it had before unless you put it to sleep

2.Threads can generate very nasty and very hard to debug errors
Errors that will appear ONLY on some systems and only every 10 days or so

3.Threads are fast to need the use of CriticalSections and Mutex and Spemaphores...that logically complicates and bloats your code

4. Threads are notoriouse hard to start stop without bugs..
(mostly stop)

All that and many more just to stop a background operation...get real ;)

Bottom line:
Use Threads ONLY if you are SURE you NEED THEM BADLY

PS. We use threads in HE but ONLY because we need them ;)
Posted on 2001-09-04 15:40:37 by BogdanOntanu
Bogdan, let's say you need to load a 200 meg file. How would you
do this in the MessageLoop and still be able to process the UI messages?
The only way I can think of would end up very very messy.

It's not true that creating an extra thread will make your application
go half speed. Sure, there's a little extra overhead in the thread/task
scheduling, but it's so little you can hardly feel it (you're not doing
realtime tasks under windows, are you?). If you have, say, two
math intensive threads running at the same time, they might run
at "half speed" - but you'd be finished in about the same time as
if you run them sequentially. When creating a thread for "heavy-duty
processing" and have the MessageLoop in the main thread, the
main thread will be asleep most of the time in the GetMessage call.
Which is a good reason to use GetMessage instead of PeekMessage -
the system can sleep a thread on GetMessage, and thus spare CPU
cycles, but it can't do this on PeekMessage.

Threads can generate very nasty and hard to debug bugs... but this
is not due to the threads, it's due to bad programming. Admitted,
it can be very hard to get threads working right when doing more
complicated stuff, but the only way around this is experience. So
don't try to crawl away from threads :). Use them if they make life
easier or can speed up your app. Not for the heck of it. But don't
invent "weird schemes" to get away from threads.

Yes, threads will very often need various synchronization objects,
which can take away any benefit the multi-threading would give.
Because of that, one should always do some pre-planning and
analyzis before implementing a threaded scheme.

Threads can be hard to stop... well, this depends on how you use
them :).
Posted on 2001-09-04 17:07:07 by f0dder
As allways i get into Crusades with fodder :(

The only reason i answer is because i hope beginners can learn from it

As i stated before we use Threads in HE and i am not against Threads "pro domo"


Bogdan, let's say you need to load a 200 meg file. How would you
do this in the MessageLoop and still be able to process the UI messages?
The only way I can think of would end up very very messy.


I think this is very easy:




;************************************
; WinMain MESSAGE LOOP STARTS HERE
;************************************

msg_loop:

;============================================
; we use PeekMessage in order to detect idle (no messages)
; time we can use to do background tasks
; standard method i you dont want to use threads
;============================================
push PM_NOREMOVE
push 0
push 0
push 0
push offset msg
call PeekMessageA

;===============================
; test: do we have messages?
;==============================
cmp eax, 0
je nu_sunt_msg
;happy jump if we dont

; ===============================
; but no so happy..
; if we have to handle them
; ===============================
push 0
push 0
push 0
push offset msg
call GetMessageA

;===================================
; test: is this message WM_QUIT ?
; =================================
cmp eax,0
; GetMessageA will return zero if it is...?
je end_loop
; EXIT PROGRAM IF TRUE!!!!

;=========================================
; default action (let windows do it's dirty job)
; for all other messages
;======================================
push offset msg
call TranslateMessage

push offset msg
call DispatchMessageA

;======================================
; and jump back to do it all over again
;======================================
jmp msg_loop

;=================================
; Here ENDS Our Program (normaly)
;==================================
end_loop:
push [msg.msWPARAM]
call ExitProcess
;exit to windows

;===================================
; we should never reach this point
;===================================
ret


;=========================================
; so...there are no win messages....
; HERE we do our GAME MAIN LOOP
; OR load a 200 mega file here ;) fodder
;=========================================

nu_sunt_msg:
push eax
push ebx
push ecx
push edx

push esi
push edi

;===================================
; test if we must do it
; the procedure should read 1Mega at a time?
;=====================================
.IF [we_must_load_file]==1
Call Our_Mighty_File_Loader_by_small_pieces
.ELSE

;==================================
; just return to WIN message loop
; this push /pop is just for safety
; and usually not required
;=================================
pop edi
pop esi
pop edx
pop ecx
pop ebx
pop eax
;====================================
; return to main Message Loop
;====================================
jmp msg_loop





It's not true that creating an extra thread will make your application
go half speed. Sure, there's a little extra overhead in the thread/task
scheduling, but it's so little you can hardly feel it (you're not doing
realtime tasks under windows, are you?). If you have, say, two
math intensive threads running at the same time, they might run
at "half speed" - but you'd be finished in about the same time as
if you run them sequentially. When creating a thread for "heavy-duty
processing" and have the MessageLoop in the main thread, the
main thread will be asleep most of the time in the GetMessage call.
Which is a good reason to use GetMessage instead of PeekMessage -
the system can sleep a thread on GetMessage, and thus spare CPU
cycles, but it can't do this on PeekMessage.


IF 2 threads will not sleep and will both have the same priority the programm will get EXACTLY 1/2 speed....or even less

Anything can be done on PeekMessage

And of course a sleeping thread dosent take CPU cycles (it takes a few) so we cant compare.

GetMessage is for Cooperative Multitasking.

It is well known (but forgotten a lot) that Cooperative multitasking is MUCH Faster then Preemptive Multitasking...but more complicated for the programmer....

well only a little as you see above i have never seen anybody cry for the existence of windows message loop...

Preemptive Multitasking is sometimes good for games and looks easyer to program ....

but it takes a LOT of CPU power to do the context switch every time ... also because programs do not know when they are switched out ... it is very EXPENSIVE and INEFICIENT...

modern Microprocessors TRY to compensate for this...but only with limited succes...as still they can never know WHEN is the RIGHT moment to SWITCH an Application



Threads can generate very nasty and hard to debug bugs... but this
is not due to the threads, it's due to bad programming. Admitted,
it can be very hard to get threads working right when doing more
complicated stuff, but the only way around this is experience. So
don't try to crawl away from threads. Use them if they make life
easier or can speed up your app. Not for the heck of it. But don't
invent "weird schemes" to get away from threads.


No "wierd schemes" here, its right from Petzold's Book
(something about programming windows for dummies)

Sure, on windows we can not get away from threads ... even if we want ...

i only want you to learn to use them WISELY

Threads NEVER Speed UP Application they ONLY SLOW Them DOWN...sometimes a LOT sometimes acceptable (like HE )

Thread generate BUGS just by themselfves because they are PARALLEL programming and this makes new bugs available to the user ...

errors will allways exist no matter how hard we try to avoid then... but threads makes them allmost IMPOSIBLE to DEBUG and find them. A thread error can show after 1 year of perfect running app, and after that show at every 10 second or after a new hardware upgrade make the system unstable ...

the same program but without THREADS will NEVER have those BUGS!

Most of today unstable windows systems are because of Threads usage


Yes, threads will very often need various synchronization objects,
which can take away any benefit the multi-threading would give.
Because of that, one should always do some pre-planning and
analyzis before implementing a threaded scheme.


They will take more away
and all this mambo jambo thread for what?

if its COMPLICATED AND SLOWER...then WHAT FOR my friend? ONLY because it can be done...and we want to be 133t?

Cooperative Multitasking using PeekMessage was the first implemented because it is more efective, faster, and less bugs ...and i have to say that MacOSs crashes al lot LESS then Windows and UNIXes

However UNIXes show that a good Preemptive Multitasking system will eventually work ;) but hellas we are not on Unixes here



Threads can be hard to stop... well, this depends on how you use
them :).


Yup

Dont get me Wrong....i use threads and i cry and i use threads and i cry....
Posted on 2001-09-04 18:41:52 by BogdanOntanu

As allways i get into Crusades with fodder :(


Hey, that's not necessarily a bad thing :). Either of us might learn
a thing or two. As for your solution to load the file (or whatever
intensive action), yes, this is how I was thinking it would be done.
However, loading the file (or whatever other action) in "small pieces"
might not be very eays. It might be so complicated that the multi-threaded
approach is justifyable. Handling a single "game frame", with redraws,
AI logic, etc, will usually fit well into this approach, though. Number
crunching, file loading/saving, etc, often won't (well, that's just my experience).


IF 2 threads will not sleep and will both have the same priority the programm will get EXACTLY 1/2 speed....or even less


Well okay, yes. What I meant (but didn't explain well enough :^))
is that your program will get both threads done the same time when
doing them parallel and if you did the serial (well, a very little bit
slower because of the extra overhead of threads, but this should
not be anything you can even feel). Obviously this can be unacceptable
in a game or other situations where you need to react quickly to
user input. In an editor, or "similar" application, it won't hurt.

Cooperative multitasking may be a bit "faster" if implemented correctly,
but it's too easy to have a system where a single bad app can take
down the whole system. And if your apps don't have enough calls
to functions that yield (peekmessage, yield, probably more), the
multitasking will NOT feel very smooth. And really, preemptive
multitasking doesn't take that much CPU power. Considering how
useful it is, I think those cpu cycles are well spent :). Processors
can't know when it's a good time to switch the process/thread, so
it's pretty lucky that it's the OS deciding this ;) (apart from the
hardware interrupts, of course). Win9x has a reasonable algorithm,
win2k seems to be somewhat smarter (subjective, feeling, not tested).

Well, you're not 100% correct that threads will never speed up
applications. Sure, there's overhead in threading, and in a uniprocessor
system, I can't see how threads can speed up an app. But in a multi-processor
system (these are slowly beginning to become common, even home
users are starting to get them), threads can make a radical speedup
if done correctly, as the threads can be distributed between processors.
You will probably not get a 2x improvement with two processors
because of the sync that needs to be done... but without threads,
you can only distribute processes on the CPUs, which is less efficient.


i only want you to learn to use them WISELY

And this is indeed very good advice! Don't use threads just because
you can, use them where they make sense :).

And well... threads will NEVER create bugs just out of the blue sky.
It's true that you can have weird situations that can appear after
10 seconds or 10 years, but it's *always* the fault of the programmer.
And yes, this is almost impossible to debug. Deadlocks, race conditions :(.
That's why any "serious" thread usage requires even more careful
planning than normal application design.


Most of today unstable windows systems are because of Threads usage

It's more generic than that. Most of today unstable windows systems
are because of sloppy prorgammers. Too bad win9x sucks so much
that a bad app can take the entire system down. I've yet to see an
app that can take win2k down (well, a "casual" app. If you write
something with the sole purpose of taking win2k down, it can probably
be done).


Cooperative Multitasking using PeekMessage was the first implemented because it is more efective, faster, and less bugs ...and i have to say that MacOSs crashes al lot LESS then Windows and UNIXes

You've been pretty lucky, then. I remember windows 3.x crashing
a lot because of badly behaving apps. I remember mac os crashing
a lot lot lot lot, either hanging, or just giving a stupid dialog with
a bomb and a reboot button. From something as simple as running
netscape navigator, hah.

My linux box never crashed. I had to reboot it once because I typed
a binary file to screen, which made the terminal all weird. If I had
known about the "reset" command (get terminal back into sane state),
I would not have needed the reboot. Last time my BSD box "crashed"
was because I accidentally flipped the reset switch. It had an uptime
of 9 days... which was as long as there had been BSD on the box.
Now it's up to 3 days again, and it just keeps working and working
and working. So don't diss unix. It serves it's purpose very well.
Posted on 2001-09-04 19:25:44 by f0dder
I thought I just would throw this in... PeekMessage to me is much easier to use. I hate threads! I'd rather code brain numbing code than to use threads :)
Posted on 2001-09-05 00:02:10 by Kenny

I thought I just would throw this in... PeekMessage to me is much easier to use. I hate threads! I'd rather code brain numbing code than to use threads :)


That can be more or less the same, kenny :D. Overcome your hatred
for threads, and understand them. Learn their powers and weaknesses.
Then in each case decide whether you want to use them or not
(which will hopefully most often be not). That is the way of the programmer *g*.
Posted on 2001-09-05 00:36:26 by f0dder
no need to use them yet, so I have no reason to learn anything :)

I'd rather figure out this BLASTED COM CRAP!
Posted on 2001-09-05 00:38:12 by Kenny
Take your time, and learn things in your own pace. But if I may give
you a piece of advice... learn things BEFORE you need to use them.
Only recently have i learned how much easier this will make your life ;).
Posted on 2001-09-05 00:46:31 by f0dder
If I listened to you, I wouldn't be talking to you right now. I have a ton of other things to do instead of trying to figure out this com stuff.

I have to animate some stuff for FJM before the 28th. I have to program about 60 hours of PHP stuff for a website launch in a week or so. I have 15 pages of papers to write before Friday. I have Finals in a week. I need to catch up on sleep. I can only go for so long on 3-4 hours a night :)
Posted on 2001-09-05 00:50:28 by Kenny
I know what it's like :). Do the best you can! I'm currently struggling
to get an asm build environment up and running for nt/2k kernel
mode drivers. There's a lot of work to do, but it's also a pretty
interesting field. The documentation is better than the win98ddk,
but still... it IS microsoft :)
Posted on 2001-09-05 01:05:15 by f0dder