Page 1 of 1

FlushWindowEvents()

Posted: Tue Jun 24, 2008 3:53 pm
by nco2k

Code: Select all

Macro FlushWindowEvents()
  While WindowEvent() : Wend
EndMacro
:D

c ya,
nco2k

Posted: Tue Jun 24, 2008 4:21 pm
by Kaeru Gaman
Image . . . Image . . . Image

Posted: Tue Jun 24, 2008 4:39 pm
by freak
Dropping all user events is a bad practise. We won't encourage that with a library command ;)

Posted: Tue Jun 24, 2008 4:44 pm
by milan1612
freak wrote:Dropping all user events is a bad practise. We won't encourage that with a library command ;)
But you need a command like this for example if you do a complicated calculation
that takes a lot of time and you don't want to use threads.
Otherwise it'll freeze up you user interface...

EDIT: Ah, OK. I misunderstood the question. Sorry...

Posted: Tue Jun 24, 2008 4:46 pm
by Kaeru Gaman
who is talking about userevents?

setting up a window with a hundred gadgets can cause a hundred events..
when you create the window invisible you may like to process all the events before unhiding the window...

Posted: Tue Jun 24, 2008 4:47 pm
by nco2k
@freak
you got it all wrong, its more like to get sure your main loop starts with 'zero'

Code: Select all

OpenWindow(...)
...
FlushWindowEvents()
Repeat
  WinEvent = WaitWindowEvent()
  ...
Until WinEvent = #PB_Event_CloseWindow
edit: @Kaeru Gaman exactly!

c ya,
nco2k

Posted: Tue Jun 24, 2008 4:53 pm
by Kaeru Gaman
yap, it's quite usual meanwhile...
it's the standard-answer to the monthly "my window creation is so slow"-question...

but in ohter cases it is more a dirty workaround, and it may be the wrong way to offer such a possibility to beginners...
maybe cause more problems than it solves....

Posted: Tue Jun 24, 2008 5:23 pm
by freak
milan1612 wrote:But you need a command like this for example if you do a complicated calculation
that takes a lot of time and you don't want to use threads.
Otherwise it'll freeze up you user interface...
If your user interface has even a single way of user interaction, you should not just ignore the events but process them using WindowEvent().
There is nothing more annoying than a gui button that you click and it gets ignored.

> who is talking about userevents?

I am.
If you add a command that that encourages misuse, people will do just that.
Especially with a command like this, which looks like a quick and easy way out of redraw problems for example, but is very often the wrong choise.

Posted: Tue Jun 24, 2008 5:42 pm
by nco2k
freak wrote:If you add a command that that encourages misuse, people will do just that.
well, maybe you should remove commands like DeleteFile(), DeleteDirectory() etc. :wink:

i dont see a big problem. just add a note in the helpfile, that this command is for advanced users only, like callbacks and many other stuff... you are not responsible, how the coder uses the pb commandset. if someone wants to use KillThread() or write a virus etc. you cant prevent it.

just my 2 cents.

c ya,
nco2k

Posted: Tue Jun 24, 2008 6:26 pm
by freak
I don't understand what DeleteFile() and DeleteDirectory() have to do with that.

You are exactly right with KillThread() though. This command should have never been added.
Its not like Callback commands or similar which just need some understanding to use them at all.
The problem with a command like KillThread() is that you have a potentially very dangerous command
which is very easy to use, and looks like a simple solution to many problems.
Yet in most of the situations, it is just the wrong command to use, and with some extra work its use can be avoided.

I have seen many many people using KillThread() out of pure lazyness, even people who should have known better.

Besides that, nobody keeps you from using "While WindowEvent(): Wend" if you want to.
Its not like such a command would add any more functionality.

Posted: Tue Jun 24, 2008 7:19 pm
by Kaeru Gaman
so, facit of this topic: we should remove KillThread() :mrgreen:

Posted: Tue Jun 24, 2008 10:15 pm
by PB
> Dropping all user events is a bad practise

But sometimes it's needed. For example: clicking an item in a ListIconGadget
returns two events. My app needs to drop everything after the first event or
my code will act twice, as if the user clicked the item twice, when he didn't.

> nobody keeps you from using "While WindowEvent(): Wend" if you want to

@Freak: Could you at least please do this request:
http://www.purebasic.fr/english/viewtopic.php?t=28930

So we can add our own Macros in a Residents file and have them autocomplete
and autocapitalize? It would then be easy for us to add our own commands.

Posted: Tue Jun 24, 2008 10:56 pm
by freak
PB wrote:> Dropping all user events is a bad practise

But sometimes it's needed. For example: clicking an item in a ListIconGadget
returns two events. My app needs to drop everything after the first event or
my code will act twice, as if the user clicked the item twice, when he didn't.
These are 2 different events (item change and click). You can use EventType() to pick the right one.

If you just drop all events form that point, it may work as you want in most cases,
but if the computer is slowed down for any reason and the events keep filling up the queue,
you are potentially ignoring quite a number of user events, which is just wrong.

Its just not a good practise.
PB wrote:@Freak: Could you at least please do this request:
http://www.purebasic.fr/english/viewtopic.php?t=28930

So we can add our own Macros in a Residents file and have them autocomplete
and autocapitalize? It would then be easy for us to add our own commands.
Yes, this is planned. Not for a specific version yet though.

Posted: Wed Jun 25, 2008 7:32 am
by blueznl
Kaeru Gaman wrote: so, facit of this topic: we should remove KillThread() :mrgreen:
Either that, or 'KillTopic' :D