Remove 'callback'

[BackupUser]

Restored from previous forum. Originally posted by Don.

This might be a completely impractical suggestion, but ....

Something I think is a bit 'messy' with PB is the fact that if you want to do any more 'adventurous' event handling, you have to code a separate callback routine. I've written many PB apps which have a standard PB event loop plus a separate callback procedure. I'm often not sure which events the standard PB event loop will capture compared to the callback, so I have to use trial & error to see what happens. Also, the fact that you end up effectively with two event loops to deal with makes the code much harder to maintain (eg. if you need to communicate between the two event loops using global variables etc.).

I think PB would be much more elegant if there was only ever one type of event loop. At the moment, we have WaitWindowEvent() and WindowEvent() which pick up various events, most commonly PB gadget events. What if these could take an argument like this:

Code: Select all

Event = WaitWindowEvent(#PB_SimpleEvents)

where #PB_SimpleEvents is the default and could be omitted for backward compatibility,

or

Code: Select all

Event = WaitWindowEvent(#PB_AllEvents)

which would pick up everything, including the kind of event we get in a callback. The arguments used in a callback - WindowID, Message, wParam, lParam - would all still be easily available using WindowID(), the value returned by WaitWindowEvent, EventwParam() and EventlParam().

Does this make any sense to anyone?

Don

[BackupUser]

Restored from previous forum. Originally posted by Franco.

Well I spend a lot of time this week with this and found out that it's the best to look first what event is catched by PB and than, if not catched, put your event in the callback procedure.
It works but this method is really time consuming. (trial & error)

My ComboBox event #WM_COMMAND/#CBN_SELCHANGE is in a separate Procedure and it works.

The bad thing about that:
it seems that only 1 SetWindowCallback(@Procedure) command is possible in a PB application.
That's why I put under the topic General Discussion\SetWindowCallback this question.

As long PB is not catching all events please don't delete SetWindowCallback!

Or if Fred would tell the variable name for the 'lpfnWndProc' structure... we don't have to use WaitWindowEvent() or WindowEvent() - only our callback procedure


Have a nice day...
Franco

Sometimes you have to go a lonely way to accomplish genius things.

[BackupUser]

Restored from previous forum. Originally posted by Don.

Hi Franco

I see your problem

The PB 'WaitWindowEvent' type of event loop is quite good because it's easy for people to understand & you have quite a lot of flexibility with it ie.
- you can code your multi-window app to have just one event loop (you'd need to use UseWindow(#Window))
- you can code your multi-window app to have one event loop per window

it all depends on the design of your app.

The only problem is like you said, WaitWindowEvent() doesn't catch all events. If only one PB callback procedure is possible, then you'd probably have to use Windows subclassing. In Windows programming, windows of the same class normally use the same Windows procedure, but you can change this using SetWindowLong and CallWindowProc, but this isn't exactly a very 'PB-friendly' way of doing things.

I still just think it would be good to have a single method of getting ALL events in a programmer-friendly way.

Don

[BackupUser]

Restored from previous forum. Originally posted by PB.

> Event = WaitWindowEvent(#PB_AllEvents)

But what would then happen to Amiga and Linux use of this command?
Wouldn't it cause incompatibility problems? Callbacks, as far as
I know, are only used on Windows...


PB - Registered PureBasic Coder

[BackupUser]

Restored from previous forum. Originally posted by fred.

> Event = WaitWindowEvent(#PB_AllEvents)

But what would then happen to Amiga and Linux use of this command?
Wouldn't it cause incompatibility problems? Callbacks, as far as
I know, are only used on Windows...

That's the problem.

The Event loop will be updated in v3.1. For now, the Callback under Windows is necessary for REPAINT and SIZE event I guess (and more API complex example, but that's another story).


Fred - AlphaSND

[BackupUser]

Restored from previous forum. Originally posted by horst.

The Event loop will be updated in v3.1. For now, the Callback under Windows is necessary for REPAINT and SIZE event I guess (and more API complex example, but that's another story).


Fred - AlphaSND

Will ver 3.1 also support keyboard events? Like the Enter key?
When can we expect this version?

Horst.

[BackupUser]

Restored from previous forum. Originally posted by El_Choni.

AFAIK, PB suports keyboard events with ExamineKeyboard and KeyboardPushed (via DirectX).

Bye,

El_Choni

[BackupUser]

Restored from previous forum. Originally posted by horst.

AFAIK, PB suports keyboard events with ExamineKeyboard and KeyboardPushed (via DirectX).
El_Choni

Does that tell me which button gadget the focus was on, when the Enter key
was pressed? How can I find out whether the focus was moved by TAB to a
"continue" button or "cancel" button?

Does ExamineKeyboard avoid the annoying error beep when Enter is pressed
in a string gadget?

And I guess it does not fix the spacebar bug on option gadgets either...

Besides: I don't need DirectX.

[BackupUser]

Restored from previous forum. Originally posted by tinman.

hi Fred,

The Event loop will be updated in v3.1...

Could you give us any hints as to what will be in the new event loop handler? I do not fancy having to investigate and write a load of Windows API code to grab keyboard and mousemove events (hint hint only to have PB 3.1 released the day after I finish

Thanks.

--
It's not minimalist - I'm increasing efficiency by reducing input effort.