FlushWindowEvents()

[nco2k]

Code: Select all

Macro FlushWindowEvents()
  While WindowEvent() : Wend
EndMacro

c ya,
nco2k

[Kaeru Gaman]

. . . . . .

[freak]

Dropping all user events is a bad practise. We won't encourage that with a library command

[milan1612]

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...

[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...

[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

[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....

[freak]

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.

[nco2k]

If you add a command that that encourages misuse, people will do just that.

well, maybe you should remove commands like DeleteFile(), DeleteDirectory() etc.

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

[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.

[Kaeru Gaman]

so, facit of this topic: we should remove KillThread()

[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.

[freak]

> 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.

@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.

[blueznl]

so, facit of this topic: we should remove KillThread()

Either that, or 'KillTopic'