Hi people. Is there a Xojo way of doing something like this, as Xojo does not produce shared libs (DLLs) ?
Background Processes in the Module’s or with GUI too?
As shown. Context aware, accessing same shared (public) data, calling current code, etc in the same process, interacting with with the current context even the current GUI. I believe that the current answer is no. The usual way I always heard of is having multiple executables and jumping from one to another losing context and data or creating APIs to enable data transfer between new processes trying to emulate something to fake things like that.
Do we have some Feature Request for something like this?
My objective could be reached even by the use of some non-standard way, like a loadXojoModule(“mod1.xojo_module”).
IPCSocket/API’s for DataTransfer is a huge workaround, i agree. What work’s for me as a workaround is a context class with loading and executing xojo script, i know thats not the same but if you have to have a lot of reuseable ‘modules’ that may be a workaround for you too. Not having linkable libs was a huge frustration when i started with xojo, now after some weeks i get used to have a well organized file/folder structure, i saw future requests for this but learned that this won’t happen next xmas… If you find a other solution pls. share!
I may be mistaken, but DLLs do not require unload, as they are not loaded in the first place. They are simply called.
XojoScript could be a way, but really what you describe seems more feasible with helper programs. With some measure of IPC, it looks quite possible to have a nice running modular app that could tap into the power of multicore architecture in a multithreaded way, something that a unique application loading and unloading libraries (if that was possible) cannot.
If you don’t unload a DLLs all the request loses the effect. every loaded dll will consume a new segment of memory until a lack of memory space.
As for Windows and DLLs. I know the following: “LoadLibrary() gives you a reliable handle to the DLL and works correctly even if the module name of the DLL is ambiguous. It makes the Windows loader increasing the internal reference count on that DLL. You can then FreeLibrary() to decrease the reference count to 0, passing it the IntPtr you got from LoadLibrary(). That unloads the DLL, as well as any dependent DLLs that got loaded.”
Why bother? Why not let Xojo in combination with the OS manage it as it already does?
A non-Xojo example (but one that uses DLL’s and VB.NET) is a HUGE application we wrote in-house where I work.
It is 10’s of thousands of lines of code, dozens of DLL’s some we wrote, many from 3rd party vendors, hundreds of forms (windows), multpile database connections, and being used by over 400 users across our nationwide network. And at no time did we feel the need to consider such an architecture.
Dave, I could let the OS manage the unload of a DLL if I could have the option to make one. That’s why I said <<My objective could be reached even by the use of some non-standard way, like a loadXojoModule(“mod1.xojo_module”).>>. And probably this way Xojo probably would ask me to handle the unload except when something got out of scope, like the final Exit().
[quote=140510:@Michel Bujardet]I may be mistaken, but DLLs do not require unload, as they are not loaded in the first place. They are simply called.
[/quote]
They have to be in memory (loaded) to be called
Linux approach is Open and Close (unload) a library. Once you don’t need it anymore, close it. dlopen(), dlclose().
dlclose is a decrement of the ref count
when ref count = 0 then it can be unloaded
You could write that code to load, find the exported entry points & call them then close the dll
Just the dll can’t be written in Xojo and the only way to share memory is to pass vars
Maybe references but then you might as well write a plugin since accessing data in Xojo from a reference will be nasty in a dll if you don’t
You COULD get more exotic & use shared memory or IPC Sockets or lots of other schemes but most have impediments in one way or another
I don’t want to write a <“C” code> in Xojo. Or C++ systems with a Xojo GUI. 
I wished Xojo could think about this matter as something really useful that should be in the list of “We need to support this” and create language extension to support such features. But I don’t feel Xojo desire to do it. 
This smacks of premature optimization. In general, the OS will swap an unused dll out of memory, even if not formally “unloaded”. Do you have an active use case where memory management is a problem?
Have you read the thread?
Ah, I see now. You want a Xojo module, not a DLL. That has been brought up before and while not promised, the new compiler will be a step toward making it possible. But, no, it is not possible currently. Nor should you count on it for the future.
Of course.
Just a correction. I wanted modular programming with generation of dynamic loadable code. Modules compiled as DLLs, SO, and such, could be one way of doing it. 
This is 100% incorrect
It IS something we have thought about <https://xojo.com/issue/1210>
It’s just not trivial to implement
[quote=140602:@Norman Palardy]This is 100% incorrect
It IS something we have thought about <https://xojo.com/issue/1210>
It’s just not trivial to implement[/quote]
The case is private 