Primarily, cross platform debugging. I’ve also used the remote debugger to debug cross site.
Executables built with Xojo are fundamentally single threaded and procedural. Xojo Event handlers are merely functions and subroutines that the Xojo framework knows how and in what order to call.
A GUI requires some form of multi-tasking. Xojo GUI applications use co-operative multi-tasking, similar to Win16 (Win 3 and Win 95). Xojo Event handlers must return control to the framework in a timely manner to allow the framework to update GUI elements Etc, otherwise the application will fail to respond to GUI events. Xojo Timers and Xojo Threads are particular types of event handler that abstract the single-threaded-ness and ease the burdens of chopping up multiple tasks into small slices of execution time.
Co-operative multi-tasking can provide Xojo applications with the appearance of doing two things simultaneously. However, the single thread is also used for i/o that is relatively slow. Semaphores provide a structure for controlling acccess to resources shared by separate tasks. For instance you might have two event handlers holding the same file open and attempting to write chunks to it between returns to the framework.
When you really do want a separate thread.
In simple terms. Xojo GUI applicaitons are event driven. A Worker provides a way to break out of the co-operative event driven paradigm. A worker is compiled as a separate Xojo console application - A separate executable task that is assigned a separate thread by the operating system. The worker application does not have a GUI, so does not need to cooperate with Xojo’s GUI framework.
An example of a Xojo worker? I’ve never used the Xojo Worker facility but was using the design pattern well before it became integrated into the IDE. I have some applications that separate the GUI from network communcations. Let’s say I want to provide an interface to gather user input before kicking off a series of non-visual sequential tasks - For instance, uploading files in a particular order. The GUI applicaiton gathers the input, writes a control file and then triggers a separate console application to sequence the uploads. The operating system spawns a new thread for the upload sequence, leaving the GUI app to carry on regardless, responding to GUI events.
Delegates are similar to function pointers in C and C++. Event handlers are essentially pointers to functions which the framework knows how to call. A Delegate is the type of the address the pointer is pointing to. Delegates provide a powerful means to implement polymorphism by hooking event handlers and registering call backs.
Yes. That sequential upload using a seperate console application I mentioned earlier. Let’s say I want to message the GUI application to let the user know the sequence completed successfully or with some error or other. I could use an IPC socket to do that.
A memory block is the closest thing Xojo has to a void type. A use case? That sequential upload application once more. Rather than writing a control structure to a file, I could write the control structure to a memory block and write the memory block to an IPC Socket connected to the console application.
Do test early and often. Don’t expect everything to work perfectly or consistently.