Re: Worker and UI
Jeremy: "When Jenner was dithering about vaccination, he was told “Don’t think; try the experiment”.” Great quote. "I may yet run foul of some hidden gremlin which bares its fangs when 4D19 appears, but I tried the experiment and thus far it works like a dream.” Oh, ye of little faith! Glad that it worked out. -- Douglas von Roeder 949-910-4084 On Sat, Mar 28, 2020 at 9:31 AM Jeremy Roussak via 4D_Tech < 4d_tech@lists.4d.com> wrote: > When Jenner was dithering about vaccination, he was told “Don’t think; try > the experiment”. > > I may yet run foul of some hidden gremlin which bares its fangs when 4D19 > appears, but I tried the experiment and thus far it works like a dream. > > Step 1: at startup, call the worker to get things set up (mostly just > opening a window, miles offscreen, containing a VP area and use DIALOG > (…;*) to show it and let it initialise itself). > > Step 2: when required, call the worker to load data into the > pre-initialised VP area, work on it, open a window and display it in a form > which allows for user interaction. When the form is closed, the worker > hangs around waiting for the next usage and the window containing the VP > area is still open. > > Thanks for all the input. > > Jeremy > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
Tim, That would seem a very sensible explanation. I’ve just tried setting my worker method to “can be run in preemptive processes” and, as you would have expected, it will no longer compile. So workers intended to do number-crunching and run headless may be marked “can be pre-emptive” and those which may want to display their own windows can’t. Seems perfectly fair. My concern about future versions arose because I was bitten by it a while ago. I wanted to get costings for anything which had a price of zero. New to 4D, I wrote QUERY([Items];[Items]price=0) APPLY TO SELECTION([Items];GetPriceFromUser) or some such, where GetPriceFromUser opened a window and demanded an answer. It worked like a charm until a later version, which suddenly started throwing a bizarre error. It took me a while, and input from the ever-helpful Miyako, to track it down to a ban on user interaction within APPLY TO SELECTION. Of course, I’d do it very differently now anyway; and as to pistols, I’ll take your word for it! Jeremy > On 28 Mar 2020, at 22:19, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> wrote: > > On Mar 28, 2020, at 2:00 PM, Jeremy Roussak wrote: > >> When Jenner was dithering about vaccination, he was told “Don’t think; try >> the experiment”. >> >> I may yet run foul of some hidden gremlin which bares its fangs when 4D19 >> appears, but I tried the experiment and thus far it works like a dream. >> >> Step 1: at startup, call the worker to get things set up (mostly just >> opening a window, miles offscreen, containing a VP area and use DIALOG (…;*) >> to show it and let it initialise itself). >> >> Step 2: when required, call the worker to load data into the pre-initialised >> VP area, work on it, open a window and display it in a form which allows for >> user interaction. When the form is closed, the worker hangs around waiting >> for the next usage and the window containing the VP area is still open. > > Good point Jeremy. Rather than talk about things you “think” you know about, > but really don’t know about, go do a test and learn about it. Then talk about > it. So that’s what I did to make sure my understand was correct. > > My understanding was that the “no UI for workers” rule only applied to > workers running in a preemptive thread. And the only way you can do that is > when running compiled and you have specified that the method you are using in > CALL WORKER has its “Execution mode” set to “Can be run in preemptive > processes”. In this case you can’t have any UI. And 4D enforces this by not > even allowing you to compile the database. > > ... > It is sort of like the grip safety on the popular 1911 .45 ACP pistols. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
On Mar 28, 2020, at 2:00 PM, Jeremy Roussak wrote: > When Jenner was dithering about vaccination, he was told “Don’t think; try > the experiment”. > > I may yet run foul of some hidden gremlin which bares its fangs when 4D19 > appears, but I tried the experiment and thus far it works like a dream. > > Step 1: at startup, call the worker to get things set up (mostly just opening > a window, miles offscreen, containing a VP area and use DIALOG (…;*) to show > it and let it initialise itself). > > Step 2: when required, call the worker to load data into the pre-initialised > VP area, work on it, open a window and display it in a form which allows for > user interaction. When the form is closed, the worker hangs around waiting > for the next usage and the window containing the VP area is still open. Good point Jeremy. Rather than talk about things you “think” you know about, but really don’t know about, go do a test and learn about it. Then talk about it. So that’s what I did to make sure my understand was correct. My understanding was that the “no UI for workers” rule only applied to workers running in a preemptive thread. And the only way you can do that is when running compiled and you have specified that the method you are using in CALL WORKER has its “Execution mode” set to “Can be run in preemptive processes”. In this case you can’t have any UI. And 4D enforces this by not even allowing you to compile the database. But if you set “Execution mode” for the worker method to “Indifferent” or “Cannot be run in preemptive processes” then you can compile and use CALL WORKER to call this method and it will display a UI and work just like any other process. It is just not running in preemptive mode. My understanding proved to be accurate. Here is the example database I created in v17.3 to test this. https://dl.dropboxusercontent.com/s/s9auizcabpnj2in/Worker_with_UI_Example.zip As it is delivered, if you try to compile you get errors. But if you change the “Execution mode” method property of WorkerMethod to “Indifferent” it will complie and you can run it compiled and see the UI from CALL WORKER. Use “Run” menu from Design to Restart Compiled or Restart Interpreted and use Test Application to show a menu bar f and the File menu “Show Simple Dialog” to do just that. If you have a method you want to run in a preemptive thread — and you want it to have a UI — you need to use the CALL FORM to a different process that is NOT running in a preemptive thread and have that process show your UI. That’s the reason the CALL FORM command was created. But you can also use it from a non-preemptive process too, so it’s useful everywhere and is more elegant that the old CALL PROCESS command. It is sort of like the grip safety on the popular 1911 .45 ACP pistols. https://gunbelts.com/blog/grip-safeties/ The weapon won’t fire unless your hand is squeezing the grip. You can drop it — when it is loaded and cocked — and it won’t fire. The 4D compiler is like a grip safety. You can’t fire that worker method in a preemptive thread unless 4D confirms your hand is on the grip — i.e. it checks that there are no UI related commands in the worker method. Then when you “fire" the worker method with CALL WORKER, it fires as expected instead of unexpectedly crashing. Tim * Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com * ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
When Jenner was dithering about vaccination, he was told “Don’t think; try the experiment”. I may yet run foul of some hidden gremlin which bares its fangs when 4D19 appears, but I tried the experiment and thus far it works like a dream. Step 1: at startup, call the worker to get things set up (mostly just opening a window, miles offscreen, containing a VP area and use DIALOG (…;*) to show it and let it initialise itself). Step 2: when required, call the worker to load data into the pre-initialised VP area, work on it, open a window and display it in a form which allows for user interaction. When the form is closed, the worker hangs around waiting for the next usage and the window containing the VP area is still open. Thanks for all the input. Jeremy ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
Peter: I’ve been using Call worker to display a large ALP Area - 3k to 30k rows and 115 columns. The UI supports a palette that communicates with all of the windows and the windows communicate with each other so that when a value is changed in one window, Call form is used to initiate the update of the display in the other windows. Some of the windows are array-based AreaList Pro areas, others use AreaList Pro displaying records. "But will try to do a simple test database to check it out.” Sounds like a good idea. -- Douglas von Roeder 949-910-4084 On Fri, Mar 27, 2020 at 2:19 PM Peter Bozek wrote: > > > On Fri, Mar 27, 2020 at 9:14 PM Douglas von Roeder > wrote: > >> Peter: >> >> "My understanding of a worker is a process that can (potentially) run on >> different core or processor - what means, communicating with other >> processes with messages only, limited ability to share data, no >> interprocess variables, no GET / SET PROCESS VARIABLE and no UI.” >> I don’t see anything that indicates that the means by which a process is >> created impacts whether or not that process runs preemptively. Most UI >> commands are not preemptive. >> > > I believe that above commands cannot be used with workers even if worker > does not run preemptive method. > > >> "However, thinking about it, as user process is a worker, and it should >> be able to display UI, collaborative workers may be able to display UI.” >> Process 1 will display UI in V18, compiled. >> >> "But all 4D examples of worker's code use CALL FORM to display UI, so I >> would not try to display UI from a worker." >> Call form is a means of communicating with a form. It doesn’t tie back to >> how a process is invoked. >> > > In the examples, worker never displays UI, rather uses CALL FORM to > display its status in form displayed in another process. As I understand > it, it is not just because examples wanted to demonstrate communication > between worker and another process, but a feature of worker - it needs > another process to display UI. But will try to do a simple test database to > check it out. > > Peter Bozek > > ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
On Fri, Mar 27, 2020 at 9:14 PM Douglas von Roeder wrote: > Peter: > > "My understanding of a worker is a process that can (potentially) run on > different core or processor - what means, communicating with other > processes with messages only, limited ability to share data, no > interprocess variables, no GET / SET PROCESS VARIABLE and no UI.” > I don’t see anything that indicates that the means by which a process is > created impacts whether or not that process runs preemptively. Most UI > commands are not preemptive. > I believe that above commands cannot be used with workers even if worker does not run preemptive method. > "However, thinking about it, as user process is a worker, and it should be > able to display UI, collaborative workers may be able to display UI.” > Process 1 will display UI in V18, compiled. > > "But all 4D examples of worker's code use CALL FORM to display UI, so I > would not try to display UI from a worker." > Call form is a means of communicating with a form. It doesn’t tie back to > how a process is invoked. > In the examples, worker never displays UI, rather uses CALL FORM to display its status in form displayed in another process. As I understand it, it is not just because examples wanted to demonstrate communication between worker and another process, but a feature of worker - it needs another process to display UI. But will try to do a simple test database to check it out. Peter Bozek ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
Peter: "My understanding of a worker is a process that can (potentially) run on different core or processor - what means, communicating with other processes with messages only, limited ability to share data, no interprocess variables, no GET / SET PROCESS VARIABLE and no UI.” I don’t see anything that indicates that the means by which a process is created impacts whether or not that process runs preemptively. Most UI commands are not preemptive. "However, thinking about it, as user process is a worker, and it should be able to display UI, collaborative workers may be able to display UI.” Process 1 will display UI in V18, compiled. "But all 4D examples of worker's code use CALL FORM to display UI, so I would not try to display UI from a worker." Call form is a means of communicating with a form. It doesn’t tie back to how a process is invoked. The fact that a given command can be used to create a preemptive process doesn’t mean that it can’t be used to launch a process that supports a user interface. The New process command can also run code in a preemptive process. -- Douglas von Roeder 949-910-4084 On Fri, Mar 27, 2020 at 12:30 PM Peter Bozek wrote: > > > On Fri, Mar 27, 2020 at 8:01 PM Douglas von Roeder > wrote: > >> Peter: >> >> "Worker cannot display anything.” >> Why do you say that? >> > > My understanding of a worker is a process that can (potentially) run on > different core or processor - what means, communicating with other > processes with messages only, limited ability to share data, no > interprocess variables, no GET / SET PROCESS VARIABLE and no UI. > > However, thinking about it, as user process is a worker, and it should be > able to display UI, collaborative workers may be able to display UI. But > all 4D examples of worker's code use CALL FORM to display UI, so I would > not try to display UI from a worker. > > Peter Bozek > > ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
On Fri, Mar 27, 2020 at 8:01 PM Douglas von Roeder wrote: > Peter: > > "Worker cannot display anything.” > Why do you say that? > My understanding of a worker is a process that can (potentially) run on different core or processor - what means, communicating with other processes with messages only, limited ability to share data, no interprocess variables, no GET / SET PROCESS VARIABLE and no UI. However, thinking about it, as user process is a worker, and it should be able to display UI, collaborative workers may be able to display UI. But all 4D examples of worker's code use CALL FORM to display UI, so I would not try to display UI from a worker. Peter Bozek ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
Peter: "Worker cannot display anything.” Why do you say that? -- Douglas von Roeder 949-910-4084 On Fri, Mar 27, 2020 at 11:50 AM Peter Bozek via 4D_Tech < 4d_tech@lists.4d.com> wrote: > On Fri, Mar 27, 2020 at 5:29 PM Jeremy Roussak via 4D_Tech < > 4d_tech@lists.4d.com> wrote: > > > v18.1, Mac > > > > What can a worker process do by way of UI? Are there any restrictions? > > > > I am not sure what you want to achieve, but yes, there is a restriction: no > UI for worker. None. Worker cannot display anything. > > Peter Bozek > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
I’ve used Call worker with the dialog command. Call worker seems to be "yet another way" to open a process but it doesn’t return a process ID. Similar to New process, you can name the process and pass parameters. If you’re closing the dialog and want the process to terminate, just call Kill worker after the Dialog or Close window command. -- Douglas von Roeder 949-910-4084 On Fri, Mar 27, 2020 at 9:29 AM Jeremy Roussak via 4D_Tech < 4d_tech@lists.4d.com> wrote: > v18.1, Mac > > What can a worker process do by way of UI? Are there any restrictions? > > Situation: I have a task which takes a while to set up but which, once set > up, runs swiftly, perhaps quite often. At present, I just wait for the > setup to complete, but while it’s only a few seconds, it’s boring. > Initialisation involves opening a window offscreen, containing a View Pro > area for use in importing Excel spreadsheets. Getting data involves > importing the spreadsheet and extracting and analysing the data, and is > very fast. > > So, I thought this might do. At startup, CALL WORKER to get the window > opened (using DIALOG(…; *). > > When data import is wanted, CALL WORKER with the path to the spreadsheet. > The worker then does the “getting data” bit of the task. > > It then has to pass the data back to the waiting caller, which may then > show it in a dialog. If before calling the worker, the caller has opened a > window, there’s no problem: the worker can use CALL FORM. But sometimes, > there will be no data to display and it will look ugly if the window opens > and then closes. > > One solution would be for the caller process to be hidden until it has > data to show in the window, and then to call SHOW PROCESS on itself. > > But it might be easier if the worker process simply did the display > itself, if it opened the window and interacted with the user, avoiding the > need to pass anything back to the caller. The caller could simply issue the > CALL WORKER message and exit. > > Is there any objection to that method of doing things? The documentation > doesn’t suggest that workers can’t have a UI. Maybe I’m stretching the use > of a worker process past that which was intended. > > Any thoughts, or indeed comments on the idiocy of my thinking and my > foolishness in having missed an obviously easy solution, gratefully > received. > > Jeremy > > PS: why does it take 4D nearly 3 seconds between showing a form after a > call to DIALOG, a form which has no form method and contains only a View > Pro area, and the On VP Ready event? > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
On Fri, Mar 27, 2020 at 5:29 PM Jeremy Roussak via 4D_Tech < 4d_tech@lists.4d.com> wrote: > v18.1, Mac > > What can a worker process do by way of UI? Are there any restrictions? > I am not sure what you want to achieve, but yes, there is a restriction: no UI for worker. None. Worker cannot display anything. Peter Bozek ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Worker and UI
I don't see why it would not work. I'm not aware of any real difference between a worker and a regular 4D process except that a worker has queue of requests and lives until killed whereas a regular process executes one request and exists. I tend to use the 4D progress component with some wrappers that allow it to be used by any process or worker including hidden and preemptive. It can also monitor and cancel jobs executing on the server. A lot of work to set up, but usable for almost anything once it is in place. John DeSoi, Ph.D. > On Mar 27, 2020, at 11:29 AM, Jeremy Roussak via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > Is there any objection to that method of doing things? The documentation > doesn’t suggest that workers can’t have a UI. Maybe I’m stretching the use of > a worker process past that which was intended. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Worker and UI
v18.1, Mac What can a worker process do by way of UI? Are there any restrictions? Situation: I have a task which takes a while to set up but which, once set up, runs swiftly, perhaps quite often. At present, I just wait for the setup to complete, but while it’s only a few seconds, it’s boring. Initialisation involves opening a window offscreen, containing a View Pro area for use in importing Excel spreadsheets. Getting data involves importing the spreadsheet and extracting and analysing the data, and is very fast. So, I thought this might do. At startup, CALL WORKER to get the window opened (using DIALOG(…; *). When data import is wanted, CALL WORKER with the path to the spreadsheet. The worker then does the “getting data” bit of the task. It then has to pass the data back to the waiting caller, which may then show it in a dialog. If before calling the worker, the caller has opened a window, there’s no problem: the worker can use CALL FORM. But sometimes, there will be no data to display and it will look ugly if the window opens and then closes. One solution would be for the caller process to be hidden until it has data to show in the window, and then to call SHOW PROCESS on itself. But it might be easier if the worker process simply did the display itself, if it opened the window and interacted with the user, avoiding the need to pass anything back to the caller. The caller could simply issue the CALL WORKER message and exit. Is there any objection to that method of doing things? The documentation doesn’t suggest that workers can’t have a UI. Maybe I’m stretching the use of a worker process past that which was intended. Any thoughts, or indeed comments on the idiocy of my thinking and my foolishness in having missed an obviously easy solution, gratefully received. Jeremy PS: why does it take 4D nearly 3 seconds between showing a form after a call to DIALOG, a form which has no form method and contains only a View Pro area, and the On VP Ready event? ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
