However, I felt this object serialization code, in and of itself, is so nifty and cool, I felt it deserved its own thread. People who may be looking for something like this probably aren't going to find it buried in a seemingly unrelated thread.
This code was posted by Jussi Lahtinen in 2013. I've put it in a project and modified it to handle Date variables, and to identify any unknown variable types it may encounter, using the Print command. It isn't complete in the sense that it handles all variables, but can easily be modified to do so.
The reason I call this a "pending" solution to the Task_Test problem is because the LoadValues and SaveValues object serialization functions need to be able to handle not just a structured class, but a structured class array. I'm not quite sure how to approach that. So I thought I'd post a project example here, which saves and loads a non-array class structure. With a request for someone to check out the project and modify it to work with arrays as well.
Then, I'll use it to modify the Task_Test project in my other thread to fix the bug and get it fully functional.
Here's some background as to why Task_Test fails, and I'll also include this info in the other thread along with a working project.
To quote from a Perl thread regarding this exact same problem someone encountered with using Fork:
So in reality, the variables inside Task_Test aren't even being altered by the Task method. Task copies these processes and hands them over to the system (allowing the bypassing of the 1 thread limitation of Gambas). The system completes these tasks and then they vanish, along with all their variables and any alterations done to them. The Gambas program, and the variables within it, remain unchanged for all practical purposes. That's why variables that were seemingly packed with data a microsecond before apparently return back to their empty undeclared state immediately. They've not actually been touched.It's not a matter of scoping, it's a matter of different processes. Parallel::ForkManager uses fork() (hence the name). This means that each version running in parallel is actually a separate process (a separate invocation of the perl interpreter) and thus separate memory. The variables will have the same name in each process, but they won't point to the same place in memory.
One solution to this problem is to use the same solution cogier came up with, allowing a parent program to communicate to and from satellite programs, which was to use File.Save and File.Load. The problem with this in the case of Task_Test is: the structured class arrays I use are too complex to be handled by File.Save and File.Load. Object serialization is the solution, and a nifty one at that.
Thanks for any help. Here's the example project.