I get the idea of parameters in functions, but I don't know what an event is. I have also heard of JavaScript function events but since I have no js experience, I don't know what they are.
There is nothing special in Lua that can be called 'event'. I guess you are talking about general events (from Wikipedia):
In computing an event is an action that is usually initiated outside the scope of a program and that is handled by a piece of code inside the program
An example of events are a mouse click, key press, download finished, anything you can imagine.
In order to react to an event, you need to write a so-called handler, sometimes also called listener or callback, which is a piece of code that you register to react to a certain event. The available events, handling process and handler registration are all dictated by the library/framework you are using, i.e. it's not Lua specific, but Lua does provide functions as way to write handlers.
For example, in Corona SDK (overview of events/listeners), you can handle the 'touch' event as follows:
Runtime:addEventListener("touch", function(event)
print("A touch event is being handled")
...
end)
There is no such thing as an 'event' in a standard Lua function. Perhaps there is some library that provides you with them, or you could script your way around to emulate the wanted behaviour.
You can get more concrete answers if you provide info about what you want to accomplish, and show some code.
Related
If one is attempting to build a desktop program with a semi-complex GUI, especially one in which users can open multiple instances of identical GUI components such as having a "project" GUI and permitting users to open multiple projects concurrently within the main window, is it good practice to push the event listeners further up the widget hierarchy and use the event detail to determine upon which widget the event took place, as opposed to placing event listeners on each individual widget?
For example, in doing something similar in a web browser, there were no event listeners on any individual project GUI elements. The listeners were on the parent container that held the multiple instances of each project GUI. A project had multiple tabs within its GUI, but only one tab was visible within a project at a time and only one project was visible at any one time; so, it was fairly easy to use classes on the HTML elements and then the e.matches() method on the event.target to act upon the currently visible tab within the currently visible project in a manner that was independent of which project it was that was visible. Without any real performance testing, it was my unqualified impression as an amateur that having as few event listeners as possible was more efficient and I got most of that by reading information that wasn't very exact.
I read recently in John Ousterhout's book that Tk applications can have hundreds of event handlers and wondered whether or not attempting to limit the number of them as described above really makes any difference in Tcl/Tk.
My purpose in asking this question is solely to understand events better in order to start off the coding of my Tcl/Tk program correctly and not have to re-code a bunch of poorly structured event listeners. I'm not attempting to dispute anything written in the mentioned book and don't know enough to do so if I wanted to.
Thank you for any guidance you may be able to provide.
Having hundreds of event handlers is usually just a mark that there's a lot of different events possibly getting sent around. Since you usually (but not always) try to specialize the binding to be as specific as possible, the actual event handler is usually really small, but might call a procedure to do the work. That tends to work out well in practice. Myself, my rule of thumb is that if it is not a simple call then I'll put in a helper procedure; it's easier to debug them that way. (The main exception to my rule is if I want to generate a break.)
There are four levels you can usually bind on (plus more widget-specific ones for canvas and text):
The individual widget. This is the one that you'll use most.
The widget class. This is mostly used by Tk; you'll usually not want to change it because it may alter the behaviour of code that you just use. (For example, don't alter the behaviour of buttons!)
The toplevel containing the widget. This is ideal for hotkeys. (Be very careful though; some bindings at this level can be trouble. <Destroy> is the one that usually bites.) Toplevel widgets themselves don't have this, because of rule 1.
all, which does what it says, and which you almost never need.
You can define others with bindtags… but it's usually not a great plan as it is a lot of work.
The other thing to bear in mind is that Tk supports virtual events, <<FooBarHappened>>. They have all sorts of uses, but the main one in a complex application (that you should take note of) is for defining higher-level events that are triggered by a sequence of low-level events occasionally, and yet which other widgets than the originator may wish to take note of.
I keep hearing V8 has its rudimentary event loop implementation but
couldn't find it
doesn't really make sense to me. Methinks, the simplest design of a JS engine would be to simply run synchronously and let the "embedder" write their own event loop - like nodejs got libuv.
Is there an event loop implementation in v8? If so, could you point me at it?
Your intuition is right that the event loop is something that embedders should have control over. However, it is also a fundamental abstract concept of the JavaScript programming model. V8's solution is to provide a default implementation that embedders can override; you can find it in the "libplatform" component: https://chromium.googlesource.com/v8/v8/+/master/src/libplatform/default-platform.cc#140
See also Relationship between event loop,libuv and v8 engine
Could you give me an example of the way I should code into the pfc_Validation event? This is an event that I have never used. For example here is something I have coded in the ue_itemchanged event.
if dwo.name = 'theme' then
This.Setitem(row,"theme",wf_clean_up_text(data))
end if
if dwo.name = 'Comments' then
This.Setitem(row,"Comments",wf_clean_up_text(data))
end if
Which is the proper way of coding those validations in the pfc_Validation event , so that they are performed only on save-time?
You're asking something outside of native PowerBuilder, so there's no guarantee my assumptions are correct. (e.g. anyone could create a pfc_Validation event and have it fire when the user draws circles with his mouse) There is a pfc_Validation event coded as part of the Logical Unit of Work (LUW) service in PowerBuilder Foundation Classes (PFC). If you want to find out more about it, I've written an article on the LUW.
Firstly, your question: Everything in the LUW service is only fired at save time, so you're in good shape there.
Having said that, from the looks of the code, this isn't validation, but data preparation for the update. On that basis, I'd suggest the appropriate place for this logic is pfc_UpdatePrep.
As for converting the code, it's pretty simple. (Now, watch me mess it up.)
FOR ll = 1 to RowCount()
Setitem(ll,"theme",wf_clean_up_text(GetItemString (ll, "theme")))
Setitem(ll,"comments",wf_clean_up_text(GetItemString (ll, "comments")))
NEXT
Good luck,
Terry.
I am working on a program which is essentially single-threaded, and its only thread is the main event-loop thread. Consequently, all its data structures are basically not protected by anything like critical region.
Things work fine until it recently integrates some new functions based on DirectShow API. Some DirectShow APIs open a second event-loop and within that second loop it dispatch messages (i.e. invoke other event-handling callbacks unpredictably). So when a second event-handling function is invoked, it might damage the data struct which is being accessed by the function that invokes the DirectShow API.
I have some experience in kernel programming. And what comes in my mind is that, for a single-threaded program, how it should deal with its data structure is very like how kernel should deal with per-CPU data structure. And in kernel, when a function accesses per-CPU data, it must disable the interrupt (very like the message-dispatching in a second event-loop). However, I find there is no easy way to either avoid invoke DirectShow API or to prevent the create of a second event-loop within them, is there any way?
mutexes. semaphores. locking. whatever name you want to call it, that's what you need.
There are several possible solutions that come to mind, depending on exactly what's going wrong and your code:
Make sure your data structures are in a consistent state before calling any APIs that run a modal loop.
If that's not possible, you can use a simple boolean variable to protect the structure. If it's set, then simply abort any attempt to update it or queue the update for later. Another option is to abort the previous operation.
If the problem is user generated events, then disable the problematic menus or buttons while the operation is in progress. Alternatively, you could display a modal dialog.
Let's say I have an event and the corresponding function is called. This function interacts with the outside world and so can sometimes have long delays. If the function waits or hangs then my UI will freeze and this is not desirable. On the other hand, having to break up my function into many parts and re-emitting signals is long and can break up the code alot which would make hard to debug and less readable and slows down the development process. Is there a special feature in event driven programming which would enable me to just write the process in one function call and be able to let the mainThread do its job when its waiting? For example, the compiler could reckognize a keyword then implement a return then re-emit signals connected to new slots automatically? Why do I think this would be a great idea ;) Im working with Qt
Your two options are threading, or breaking your function up somehow.
With threading, it sounds like your ideal solution would be Qt::Concurrent. If all of your processing is already in one function, and the function is pretty self-contained (doesn't reference member variables of the class), this would be easy to do. If not, things might get a little more complicated.
For breaking your function up, you can either do it as you suggested and break it into different functions, with the different parts being called one after another, or you can do it in a more figurative way, but scattering calls to allow other processing inside your function. I believe calling processEvents() would do what you want, but I haven't come across its use in a long time. Of course, you can run into other problems with that unless you understand that it might cause other parts of your class to run once more (in response to other events), so you have to treat it almost as multi-threaded in protecting variables that have an indeterminate state while you are computing.
"Is there a special feature in event driven programming which would enable me to just write the process in one function call and be able to let the mainThread do its job when its waiting?"
That would be a non-blocking process.
But your original query was, "How can I implement a blocking process in a single slot without freezing the GUI?"
Perhaps what you're looking for a way to stop other processing when some - any - process decides it's time to block? There are typically ways to do this, yes, by calling a method on one of the parental objects, which, of course, will depend on the specific objects you are using (eg a frame).
Look to the parent objects and see what methods they have that you'd like to use. You may need to overlay one of them to get your exactly desired results.
If you want to handle a GUI event by beginning a long-running task, and don't want the GUI to wait for the task to finish, you need to do it concurrently, by creating either a thread or a new process to perform the task.
You may be able to avoid creating a thread or process if the task is I/O-bound and occasional callbacks to handle I/O would suffice. I'm not familiar with Qt's main loop, but I know that GTK's supports adding event sources that can integrate into a select() or poll()-style loop, running handlers after either a timeout or when a file descriptor becomes ready. If that's the sort of task you have, you could make your event handler add such an event source to the application's main loop.