PureBasic Forums - English

I would like to see a command to create a new PureBasic event and post it to the event queue.
I don't know if this has been asked before but I couldn't find it with the search function of the forum.

wilbert wrote:I don't know if this has been asked before but I couldn't find it with the search function of the forum.

Not has a Feature Request but I have propose the Idea here : http://www.purebasic.fr/english/viewtop ... +Injection

Event Injection to the PB Event Management System, it's possible with SDL by the way but it's only suitable for games not applications.

So, +1

Best regards.
Guimauve

My search was limited to the feature requests forum so that's why I probably didn't see it

It seemed useful to me in several situations but after I posted the idea I read somewhere PB events are limited to a thread and not application wide.
What I had in mind is if something is done in the background by a second thread or an api function with a callback, to let it post an event when the operation is completed so the main thread can handle the situation in the event loop.
Also on OS X, there's zero information in the SDK about gadget creation. If it would be possible to post events, you wouldn't need to create an official gadget. If something can be placed on a window and can send out an event when something happens, that probably should be enough.

I don't know if this is what you are looking for, but sometimes I used: And you can cause an event for example on a button, in this way: I find it useful when several different actions must do the same thing. For example, a button click and a keypress... and I don't want
to make a function or duplicate the same code.

Something like that but as an official command that is cross platform available.
The import instruction you gave doesn't work on OS X.

wilbert wrote:Something like that but as an official command that is cross platform available.

I agree -- a cross-platform command something like:
This would create a user event that is not related in any way to the operating system API.

I've used this construct in other languages, and it can be very useful for simplifying code or delaying actions until other events have been processed.

Options should allow for placing the event in the message queue for normal processing, or for delaying the event until all other messages in the queue have been processed.

Instead of linking user events to a specific gadget, they might be treated as a unique class of event in order to provide more flexibility in their use.

I've also had the need for this functionality, mainly to ensure some operation is performed in the main thread. My solution was to have an array of 'main thread requests' and a procedure that would add an entry to that array. The array structure includes fields for the request type and for integer, string and float variables. A global variable indicates how many unprocessed requests are in the array. A second procedure is called from the main event loop, and this procedure looks for unprocessed requests and executes them, usually by calling some procedure.

A mutex is used to control access to the array by these two procedures. This is because the procedure to add an entry to the array could be called from any thread. WaitWindowEvent in the main thread has a 10-millisecond timeout to ensure timely calls to the array processing procedure. You could use a linked list instead of an array, but I was used to arrays from my VB6 days and generally prefer them.

This solution is, of course, cross-platform as it just uses PB code. However, if PB had a CreateUserEvent() function or similar, that would save a lot of work. So +1 from me even though I've got a solution for now.

I would welcome this as well. The current way of raising an event requires tapping into PB internals, which is never a good idea if you want your code to compile in future versions. A new command such as RaiseEvent(#Gadget, EventType) would add power and flexibility to the language.

Of course, without such a feature it's still possible to accomplish the same thing with normal procedure calls, but the resulting code can sometimes be a little messy.