On Sat, May 6, 2017 at 6:24 AM, Tim Nevels via 4D_Tech <[email protected] > wrote:
You are correct. This is exactly how JPR described it. > This reminds me to tell a story I've shared before. My first job at 4D was working in the Tech Support 'pit'. And again, apologies to anyone that reached me :-0 The Tech Support manager back then was Thom Hickey, who some of you may know or remember. He gave me about the best advice I've ever gotten: "Hey man, never lie! If someone calls and you don't know or aren't sure, put them on hold and try it. Create a small database from scratch and try it out. Never. Lie." Solid advice. If you're not sure, check it out. I very quickly not to be afraid to create little databases and throw them away. I _still_ do this. If I want to try out a new 4D feature, I don't do it in a real code base, I do it in a scratch database. I know I'll throw it away (if not immediately, a bit down the track) so I've got no investment. I can let my hair down and be messy. The whole point is to focus on one thing and move fast. For something like CALL FORM and CALL WORKER, I must have made more than a dozen disposable databases. I've also done a couple of really massive ones with real code to test out more intricate questions - but a lot can be done with throw-away databases. Case in point: I was wondering "Huh. You can post code to the execution hopper with CALL FORM before a form is loaded. Will it execute before On Load or after?" There is no way to know a priori and it's not in the docs. So I tried it. It took less time than writing this up - just a few minutes. Well, On Load runs first. It didn't have to be that way, but it turns out that it is that way. I wrote to Thomas Maul and he confirmed with Engineering that the behavior is something that we can rely on. I tried to update the docs with a comment, didn't know how...and never got back to doing it. The point is that a lot of this stuff isn't a mystery, it just isn't well documented. But you can find out for yourself in a few minutes or an hour. It's fun! But then again, I'm a fan of black-box testing... So, like yesterday, I strongly encourage people to try out CALL FORM and CALL WORKER in a scratch database. If you've got 30-60 minutes when you're feeling awake, relaxed, and curious - see what you can figure out first-hand. There's nothing like trying stuff out directly to build a solid mental model. And mastery of these commands does require building an accurate mental concept of how it all works. With this in mind, I'd also encourage people to try and ignore the documentation's "mailbox" metaphor. It's not entirely wrong, but it's more wrong than it is right. For anyone that's ever dealt with a request queue, we don't have that. You need to understand that there is a queue *underneath* to understand how multi-process-calls and self-call work, but that's it. Instead, try to think about a *thread of control.* Namely, a process. Either worker or a window with a form. A worker is easier to explain but the concepts apply either way. Imagine that you are a worker. What are you? You're a process that executes code, like any code. But instead of dying when the code runs out, you go to sleep. It's like 4D has put your code in a magic repeat loop: Repeat Run code <-- this is the worker code that you write Sleep Until (shutting down) CALL WORKER does this: Repeat Run code <-- this is the worker code that you write Sleep Wake up <-- this is what CALL WORKER provokes --- Go back to the top of the loop and 'run code' provided by CALL WORKER Until (shutting down) Imagine now that you're developing and the debugger comes up in your worker. What happens to CALL WORKER requests to the worker? They proceed normally as there is no result from CALL WORKER. The 'queue' (within 4D) gets a new entry. But that's it, nothing gets processed and the queue keeps getting bigger and bigger. But you can't detect that, can's see the queue, can't do anything to it. Well, you can kill the worker, clear the queue and let 4D restart it, but that's it. Try to think about workers *from their point of view.* The queue is from *4D's* point of view. And, for anyone that's used queues before, you just don't have the facilities you would expect. There is no On Message event or routine. There is no chance to inspect the code before it executes. It just runs. The CALL commands are *code dispatchers*. They move a block of code from one place (where you run it) to another place (at the end of a thread of execution in the same or a different process.) They're like unregulated remote procedure calls. You can use them to send IP messages (I do) but, by their nature, that's not what they are - they're little blocks of code that you're moving into another process. That can be great because you have the full context of that process - like selections, variables, etc. It can also be dangerous because the called process can't block, suspend, reject, or inspect 'messages'. They just run. Probably a good place to remind people that CALL FORM does *not* run in the form method and does *not* provoke a form event. It runs the method name you pass in the process that manages the window you specify. Okay, I got deep into the weeds again - sorry. I just wanted to encourage people to try this stuff out first-hand. You don't need all of the details to make it work. Plus, these commands are fun! Try them out, you'll like them! They're super handy and fun. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
