Re: Exploring CALL WORKER vs New process
Tim, I'm glad you reminded me of this one. I don't have problems with sending emails so much but the process for downloading them caused problems. I actually split that process off into a separate database - the downloads get processed into a watched folder. One of my first thoughts was to split that task into a preemptive process but I see that won't do any good for the time being. On Sat, May 20, 2017 at 12:54 AM, Tim Nevels via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Another area is with plugin calls like 4D Internet Commands -- in > particular the email commands. Many of them can block 4D waiting for a > reply from the email server. And since currently all plugin calls happen > running in the cooperative mode they block every process while waiting for > that slow email server. > > So if you are trying to send an email from 4D Server this blocking effects > ALL users. Users experience intermittent slowdowns and don't know why. I > had one situation where I had to move all email operations from 4D Server > to a 4D Client slave to stop this. > -- Kirk Brooks San Francisco, CA === *The only thing necessary for the triumph of evil is for good men to do nothing.* *- Edmund Burke* ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Exploring CALL WORKER vs New process
That was a kind of mashup of several ideas, but you covered them in the preceding paragraph. Thanks for the observations. Keith - CDI > On May 19, 2017, at 5:41 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > You call a window, not a form, not process. That's precisely so that you > can specify which window in a process you're trying to send the code to for > execution. If you aren't using multiple windows in a single process or if > you aren't using 'form variables', then it makes no difference. > > * The code executes in the context of the _process_ holding the > window/form. No matter which window/form it is. > * The code has access to the form variables of the form in the specified > window, if you want them. > > A form's local variables are outside the purview of the "Worker called". >> No event is triggered. Any variable changed need a Call Process (-1) for >> their display to change. >> On the other hand, this is where form object names make the context >> significant? >> > > I don't think that I follow what you're saying here. ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Exploring CALL WORKER vs New process
Nice one Tim. I have no idea when/if they'll free up 4DIC to run in preemptive mode (on another core), or allow plug-ins to do so generally. Since the answer is possibly "never" and is definitely "not at the moment", there _is _ something you can do. The docs say that HTTP Request and HTTP Get work today in preemptive mode. (Note: I haven't verified this myself, but I'm pretty sure the docs are right.) Depending on how much trouble it's worth to you, you can push your email queue out with a preemptive worker. Instead of doing right to your IMAP/SMTP server, you can: * Push data up to MailChip, etc. There are lots of services out there these days. * Push the data up to a stand-alone copy of 4D running somewhere on your network. It gets the data and can reuse your existing 4DIC code normally. So: Busy Database --> CALL WORKER to a preemptive thread --> HTTP Request to push data to stand alone 4D --> Web server catches data --> 4DIC calls like normal What could be simpler! ;-) It's not that bad if you can compile your existing source into a special stand-alone build that has a Web server. My main database source compiles to about 8 different projects at the moment. Yeah, it would be nice to have 4DIC, etc., but at least there is an option now - if it's worth the trouble in your case. P.S. I suspect what I've just described might fit in nicely with what your working on... P.P.S. You can cut out the whole CALL WORKER --> HTTP Request bit and just do the HTTP Request bit locally, but it might be nice to use CALL WORKER here. It unblocks your main code and should work very smoothly and quickly. Delegating the email dispatch to a second machine running it's own 4D build removes the blocking from the busy system entirely. If you have a ton of mail (or whatever, SMS messages, Web updates, etc.), you can put a few stand-alone machines into rotation. On Sat, May 20, 2017 at 5:54 PM, Tim Nevels via 4D_Tech < 4d_tech@lists.4d.com> wrote: > On May 20, 2017, at 1:25 AM, David Adams wrote: > > > Delegating various file system calls to a worker is, in my opinion, a > solid > > idea. Particularly if the operation is blocking, or if you find yourself > > constantly fighting/waiting for a read lock on the file. (Like the log > > example I go back to all of the time.) > > Another area is with plugin calls like 4D Internet Commands -- in > particular the email commands. Many of them can block 4D waiting for a > reply from the email server. And since currently all plugin calls happen > running in the cooperative mode they block every process while waiting for > that slow email server. > > So if you are trying to send an email from 4D Server this blocking effects > ALL users. Users experience intermittent slowdowns and don't know why. I > had one situation where I had to move all email operations from 4D Server > to a 4D Client slave to stop this. > > So once 4D updates 4D Internet Commands to run in preemptive mode -- if > that is even possible -- or adds native commands to 4D to replace 4D > Internet Commands that will be a great thing to push off to a worker. No > more blocking from slow email servers. > > Tim > > Sent from my iPad > ** > 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:4d_tech-unsubscr...@lists.4d.com > ** > ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Exploring CALL WORKER vs New process
On May 20, 2017, at 1:25 AM, David Adams wrote: > Delegating various file system calls to a worker is, in my opinion, a solid > idea. Particularly if the operation is blocking, or if you find yourself > constantly fighting/waiting for a read lock on the file. (Like the log > example I go back to all of the time.) Another area is with plugin calls like 4D Internet Commands -- in particular the email commands. Many of them can block 4D waiting for a reply from the email server. And since currently all plugin calls happen running in the cooperative mode they block every process while waiting for that slow email server. So if you are trying to send an email from 4D Server this blocking effects ALL users. Users experience intermittent slowdowns and don't know why. I had one situation where I had to move all email operations from 4D Server to a 4D Client slave to stop this. So once 4D updates 4D Internet Commands to run in preemptive mode -- if that is even possible -- or adds native commands to 4D to replace 4D Internet Commands that will be a great thing to push off to a worker. No more blocking from slow email servers. Tim Sent from my iPad ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Exploring CALL WORKER vs New process
> A method called by CALL WORKER
> $w:=Open Form Window("ShowRecord")
> Dialog("ShowRecord";*)
> So this is why when using CALL WORKER, the Dialog(*) windows hang around
after the method has been exited.
> This means moving the process ExitCode from the lines after Dialog into a
form's "On Unload" event.
The worker would still be alive even if your dialog is closed - or if you
never even displayed a dialog - that's in the nature of a 4D worker. There
is more to say here about killing/starting/restarting workers and what
happens to their contexts. Try and start them, leave them running, and kill
them only when you're shutting down. That's a good first approach while
sorting through the mechanics.
Fair warning: I haven't done much (anything?) with UI displayed by a
worker, so I may make mistakes. I use workers in their naked/headless form
so that they don't get gummed up with form stuff. If I need UI, I use a
form and use CALL FORM. Why not? A form (window) or a worker can receive
calls, so I pick the version that matches what I need. Forms when I need
UI, Workers when I don't.
Keep in mind that it is the nature of a worker to stay alive when its work
is done...it just waits for new work to arrive. That's in the docs, it's a
deliberate part of their design. That means that if you have, for example,
a loaded record in read write, it blocks any other process from getting a
write on that record. If you want to clear out a worker, you can use KILL
WORKER on the worker itself and that does the trick.
> > but there are functionally two loops
> A forms execution environment could be visualized as:
> If (Worker called)
> // do worker method
> Else
> // do form method
> End if
>
I know absolutely nothing about the 4D internals, I'm only offering a
description based on observable behavior. The things to keep in mind here
are that
1) CALL FORM doesn't trigger a form event.
2) Form methods do *not* catch CALL FORM calls.
> > The method has
> > access to all of the process values (variables, etc.) and the "form
> > variables" of the specific form in the specified window.
>
> If several forms were open in a process, would it matter which form was
> called?
You call a window, not a form, not process. That's precisely so that you
can specify which window in a process you're trying to send the code to for
execution. If you aren't using multiple windows in a single process or if
you aren't using 'form variables', then it makes no difference.
* The code executes in the context of the _process_ holding the
window/form. No matter which window/form it is.
* The code has access to the form variables of the form in the specified
window, if you want them.
A form's local variables are outside the purview of the "Worker called".
> No event is triggered. Any variable changed need a Call Process (-1) for
> their display to change.
> On the other hand, this is where form object names make the context
> significant?
>
I don't think that I follow what you're saying here.
> Handy use example:
> A method that saves a file, processes it, and deletes the file got a
> significant performance boost when the delete part was handed off to a CALL
> WORKER invoked method.
>
Delegating various file system calls to a worker is, in my opinion, a solid
idea. Particularly if the operation is blocking, or if you find yourself
constantly fighting/waiting for a read lock on the file. (Like the log
example I go back to all of the time.)
**
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:4d_tech-unsubscr...@lists.4d.com
**
Re: Exploring CALL WORKER vs New process
> On May 18, 2017, at 5:38 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
> * Workers don't die when their work is done, they wait.
A method called by New Process
$w:=Open Form Window("ShowRecord")
Dialog("ShowRecord")
ExitCode
A method called by CALL WORKER
$w:=Open Form Window("ShowRecord")
Dialog("ShowRecord";*)
So this is why when using CALL WORKER, the Dialog(*) windows hang around after
the method has been exited.
This means moving the process ExitCode from the lines after Dialog into a
form's "On Unload" event.
> but there are functionally two loops
A forms execution environment could be visualized as:
If (Worker called)
// do worker method
Else
// do form method
End if
> The method has
> access to all of the process values (variables, etc.) and the "form
> variables" of the specific form in the specified window.
If several forms were open in a process, would it matter which form was called?
A form's local variables are outside the purview of the "Worker called". No
event is triggered. Any variable changed need a Call Process (-1) for their
display to change.
On the other hand, this is where form object names make the context significant?
Handy use example:
A method that saves a file, processes it, and deletes the file got a
significant performance boost when the delete part was handed off to a CALL
WORKER invoked method.
Thanks,
Keith - CDI
**
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:4d_tech-unsubscr...@lists.4d.com
**
Re: Exploring CALL WORKER vs New process
On Fri, May 19, 2017 at 4:41 AM, Timothy Penner via 4D_Tech < 4d_tech@lists.4d.com> wrote: +1 Tim nailed it and offered a really clear explanation, I think. I use workers in a headless mode without windows and use forms when I do need a window. In both cases, the 'messages' are *not* interrupts. They do *not* get injected into a running routine. Instead, they are appended to the end of the context's thread of control and are executed only when the rest of the process is done. Or, more briefly, "What Tim said" ;-) To keep in mind about workers: * Workers are like New process in most ways, you're right about that. * Workers don't die when their work is done, they wait. Wait for a block of code to execute that is sent via CALL WORKER. * CALL WORKER is, in practice, EXECUTE METHOD IN WORKER. * There's a bunch of stuff in the manuals about preemptive mode which you can ignore if you don't care about preemptive mode. To keep in mind about forms: * I don't know how it works internally, but there are functionally two loops: Form event cycle and 'wait for code sent via CALL FORM' loops. * Both of these internal loops are invisible to us and managed by 4D. * They're not the same. There is no form event for CALL FORM. * CALL FORM would be easier to understand as EXECUTE METHOD IN WINDOW. * The call isn't picked up by the form, it's a method that executes in the context of the process in the window that you've specified. The method has access to all of the process values (variables, etc.) and the "form variables" of the specific form in the specified window. * CALL PROCESS+On Outside Call suck and always did. Now we have a better alternative for messaging and it's easy to use. Yeah! A couple of other points: * Only workers and windows can receive calls, but anything can send calls. * You can bridge communications to other places using a worker. Imagine that you have a Web page or a log file that you want to update automatically based on events on various forms or processes. Send all of the info to a single worker and have that worker update the Web page. So, the information is flowing from froms, processes, workers to your Web page. The target worker takes care of the "bridge". By the way Keith, it's great to see questions on this subject and to see you thinking through a novel way of using the tools. (I hadn't thought of what you proposed or ever tried it.) There are a lot of creative ways to use these tools and a bit of a learning curve to absorbing what they do and how. So thanks for sharing another spin on them. ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Exploring CALL WORKER vs New process
OK - I have to take that back. I recall that calling Dialog(TableOrProjectForm;plain window;*) always closed the window immediately after it was opened, unless it was called from a "main" window. I just tried it anyway, and it stayed open. Will rethink... Keith - CDI > On May 18, 2017, at 3:36 PM, Keith Culotta via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > In just about all UI processes Dialog(TableOrProjectForm;plain window) is the > only way a window gets opened. I suppose this has simulated calling > DIALOG(*) from a [I forget what kind of] window. These can call their own > DIALOG(*) windows too. Wanting to use CALL WORKER would change that > approach. It looks like it will be best to find a window number and use CALL > FORM after all. ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Exploring CALL WORKER vs New process
In just about all UI processes Dialog(TableOrProjectForm;plain window) is the only way a window gets opened. I suppose this has simulated calling DIALOG(*) from a [I forget what kind of] window. These can call their own DIALOG(*) windows too. Wanting to use CALL WORKER would change that approach. It looks like it will be best to find a window number and use CALL FORM after all. Keith - CDI > On May 18, 2017, at 2:26 PM, Timothy Penner wrote: > >>> Sure enough, Dialog puts the brakes on it. >> Maybe using the * parameter to DIALOG will allow your design to function? > > Actually, you would also need to remove the call to KILL WORKER because that > command will effectively close the open Window. ** 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:4d_tech-unsubscr...@lists.4d.com **
RE: Exploring CALL WORKER vs New process
> > Sure enough, Dialog puts the brakes on it. > Maybe using the * parameter to DIALOG will allow your design to function? Actually, you would also need to remove the call to KILL WORKER because that command will effectively close the open Window. -Tim ** 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:4d_tech-unsubscr...@lists.4d.com **
RE: Exploring CALL WORKER vs New process
> Sure enough, Dialog puts the brakes on it. Maybe using the * parameter to DIALOG will allow your design to function? -Tim ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Exploring CALL WORKER vs New process
Tim, Sure enough, Dialog puts the brakes on it. Keith - CDI > On May 18, 2017, at 1:41 PM, Timothy Penner via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > For example, if the Worker is running DIALOG then the method will not > complete until after the window is closed. Like in your example: ** 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:4d_tech-unsubscr...@lists.4d.com **
RE: Exploring CALL WORKER vs New process
Hi Keith,
> Communication to a process seems easier if the process is started using CALL
> WORKER. Not only can any of its windows be called with CALL FORM, but the
> process can also be called with CALL WORKER, without knowing which window, if
> any, is open.
I have not tried what you describe but the way I understand it is...
CALL WORKER doesn't actually communicate something to the running worker,
instead it puts a message in the workers message box (Queue). The worker must
finish its current task/method before checking the message box (Queue).
When the Worker is done with its current work (i.e. the method has completed)
then the Worker checks the Queue for the next item to work on and then starts
executing the next method.
So if you were trying to send a message to worker to have it unload a locked
record, and the worker is currently executing a method, then the message would
only be read AFTER the current worker method finishes executing...
For example, if the Worker is running DIALOG then the method will not complete
until after the window is closed. Like in your example:
//--wOpen - displays the record on the screen
PROCESS PROPERTIES ( Current Process ; $key ; $p1 ; $p2 )// $key gets the
Process Name
Query([Table];[Table]PriKey=$key)
$w:=Open Form Window("ShowRecord")
Dialog("ShowRecord")
KILL WORKER
The project method would be waiting for the DIALOG to be closed before
continuing its execution (I assume this can be worked around by using DIALOG
with a * parameter).
So, based on the above, I think it would be better to use CALL FORM to execute
a method in the context of the open window, instead of placing a message in the
Workers message box.
Just my 2 cents.
-Tim
**
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:4d_tech-unsubscr...@lists.4d.com
**
Re: Exploring CALL WORKER vs New process
Kirk,
wOpen lets a user modify a record in a window in a new process. This DB would
have only a few records that could be picked from a floating list.
When the floating list process wants to change the record:
If the record is locked by a wOpen type process, the floating list could use
CALL WORKER to send the change request to the process that has possession of
the record. If the record is not in use, the change could be made from the
floating list (R/W, load record, change, unload, R/O).
To reduce chaos, a record will only be used by a single process.
The process name would be the record's Primary Key.
No heavy processing, single user application.
Communication to a process seems easier if the process is started using CALL
WORKER. Not only can any of its windows be called with CALL FORM, but the
process can also be called with CALL WORKER, without knowing which window, if
any, is open.
It got me to wondering if, in general, "CALL WORKER" has all the advantages
over "New process" to manage processes.
Thanks,
Keith - CDI
--some corrections in the sample code below--
> On May 18, 2017, at 11:41 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> Keith,
>
> First off I'm not clear what the intent of wOpen is - are we modifying the
> record or simply displaying it?
>
> If it's only being displayed you don't need CALL WORKER to change it - any
> process that can load it can change it. The issue becomes notifying the
> display process to refresh itself - which would probably be an On timer
> event (if you're running on 4D server it would have to be) or On outside
> call (or CALL FORM...) if it's standalone.
>
> If wOpen is allowing the user to edit the record I'd say that's a bad idea
> to have outside processes modify a record the user has open - at least
> without the user having control and knowledge of what's going on. As I
> think about it if this is a case where you're handing off some processor
> intensive operation from the form you want to run by CALL WORKER and then
> get the results back that's plausible. Personally I'd rather have the input
> form receive the data and handle updating the record at the form level than
> allow another process to load, modify and unload the record.
>
> It still seems like a lot of extra coding for not much benefit - but I may
> not fully get your intention. I do a lot of this sort of thing already
> using Execute on server to move the heavy processing off the client and
> avoid moving lots of data over the network.
>
> On Thu, May 18, 2017 at 8:22 AM, Keith Culotta via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
>> Are there good reasons to keep using "New process" in a situation like the
>> following, or can it be replaced by "CALL WORKER"?
>>
>> //--Base process that shows a list of records from [Table]. Pick a record
>> and
>> $p:=New process("wOpen";0;[Table]PriKey;*)
>>
>> //--wOpen - displays the record on the screen
>> PROCESS PROPERTIES ( Current Process ; $key ; $p1 ; $p2 )
>> Query([Table];[Table]PriKey=$key)
>> $w:=Open Form Window("ShowRecord")
>> Dialog("ShowRecord")
>>
>> Now, "Base process" would like to tell the new process to change a value
>> in the record.
>> After "Base process" gets the value of $w, it could use "CALL FORM" to
>> accomplish that.
>> However, if I had used: CALL WORKER ( [Table]PriKey ; wOpen) instead of
>> "New process" to create the process, I could, with minor changes in wOpen,
>> use "CALL WORKER" to get the process to change the record's values.
>>
>> //--process that shows a list of records from [Table]. Pick a record and
>> CALL WORKER ( [Table]PriKey ; wOpen)
>>
>> //--wOpen - displays the record on the screen
>> PROCESS PROPERTIES ( Current Process ; $key ; $p1 ; $p2 )// $key Process Name
>> Query([Table];[Table]PriKey=$key)
>> $w:=Open Form Window("ShowRecord")
>> Dialog("ShowRecord")
>> KILL WORKER
>>
>> Thanks,
>> Keith - CDI
>
>
>
> --
> Kirk Brooks
> San Francisco, CA
> ===
>
> *The only thing necessary for the triumph of evil is for good men to do
> nothing.*
>
> *- Edmund Burke*
**
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:4d_tech-unsubscr...@lists.4d.com
**
Re: Exploring CALL WORKER vs New process
Keith,
First off I'm not clear what the intent of wOpen is - are we modifying the
record or simply displaying it?
If it's only being displayed you don't need CALL WORKER to change it - any
process that can load it can change it. The issue becomes notifying the
display process to refresh itself - which would probably be an On timer
event (if you're running on 4D server it would have to be) or On outside
call (or CALL FORM...) if it's standalone.
If wOpen is allowing the user to edit the record I'd say that's a bad idea
to have outside processes modify a record the user has open - at least
without the user having control and knowledge of what's going on. As I
think about it if this is a case where you're handing off some processor
intensive operation from the form you want to run by CALL WORKER and then
get the results back that's plausible. Personally I'd rather have the input
form receive the data and handle updating the record at the form level than
allow another process to load, modify and unload the record.
It still seems like a lot of extra coding for not much benefit - but I may
not fully get your intention. I do a lot of this sort of thing already
using Execute on server to move the heavy processing off the client and
avoid moving lots of data over the network.
On Thu, May 18, 2017 at 8:22 AM, Keith Culotta via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> Are there good reasons to keep using "New process" in a situation like the
> following, or can it be replaced by "CALL WORKER"?
>
> //--Base process that shows a list of records from [Table]. Pick a record
> and
> $p:=New process("wOpen";0;[Table]PriKey;*)
>
> //--wOpen - displays the record on the screen
> $key:=$1
> Query([Table];[Table]PriKey=$key)
> $w:=Open Form Window("ShowRecord")
> Dialog("ShowRecord")
>
> Now, "Base process" would like to tell the new process to change a value
> in the record.
> After "Base process" gets the value of $w, it could use "CALL FORM" to
> accomplish that.
> However, if I had used: CALL WORKER ( [Table]PriKey ; wOpen) instead of
> "New process" to create the process, I could, with minor changes in wOpen,
> use "CALL WORKER" to get the process to change the record's values.
>
> //--process that shows a list of records from [Table]. Pick a record and
> CALL WORKER ( [Table]PriKey ; wOpen)
>
> //--wOpen - displays the record on the screen
> PROCESS PROPERTIES ( Current Process ; $key ; $p1 ; $p2 )// $key gets the
> Process Name
> Query([Table];[Table]PriKey=$key)
> $w:=Open Form Window("ShowRecord")
> Dialog("ShowRecord")
> KILL WORKER
>
> Thanks,
> Keith - CDI
> **
> 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:4d_tech-unsubscr...@lists.4d.com
> **
--
Kirk Brooks
San Francisco, CA
===
*The only thing necessary for the triumph of evil is for good men to do
nothing.*
*- Edmund Burke*
**
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:4d_tech-unsubscr...@lists.4d.com
**
Exploring CALL WORKER vs New process
Are there good reasons to keep using "New process" in a situation like the
following, or can it be replaced by "CALL WORKER"?
//--Base process that shows a list of records from [Table]. Pick a record and
$p:=New process("wOpen";0;[Table]PriKey;*)
//--wOpen - displays the record on the screen
$key:=$1
Query([Table];[Table]PriKey=$key)
$w:=Open Form Window("ShowRecord")
Dialog("ShowRecord")
Now, "Base process" would like to tell the new process to change a value in the
record.
After "Base process" gets the value of $w, it could use "CALL FORM" to
accomplish that.
However, if I had used: CALL WORKER ( [Table]PriKey ; wOpen) instead of "New
process" to create the process, I could, with minor changes in wOpen, use "CALL
WORKER" to get the process to change the record's values.
//--process that shows a list of records from [Table]. Pick a record and
CALL WORKER ( [Table]PriKey ; wOpen)
//--wOpen - displays the record on the screen
PROCESS PROPERTIES ( Current Process ; $key ; $p1 ; $p2 )// $key gets the
Process Name
Query([Table];[Table]PriKey=$key)
$w:=Open Form Window("ShowRecord")
Dialog("ShowRecord")
KILL WORKER
Thanks,
Keith - CDI
**
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:4d_tech-unsubscr...@lists.4d.com
**
