Re: Managing multiple windows in the same process (v17r5)

[Kirk Brooks via 4D_Tech]

Wayne,
That's true but it's easy to hand off tasks like that to Workers. And the
worker uses CALL FORM to hand back the results.

On Fri, Aug 2, 2019 at 10:22 AM Wayne Stewart via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> Hi,
>
> One disadvantage is that there is only one execution stream with multiple
> windows in the one process.
>
> If something is taking time in one window (a sequential search or sort or a
> even just a long method) execution will stop in all other windows, the UI
> will freeze etc
>
>
>
> On Sat, 3 Aug 2019 at 02:29, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com
> >
> wrote:
>
> > Hi Pat,
> > For something like that I would think about using a palette or
> toolbar-ish
> > window as the 'root', if you will, for the UI process.
> > That could actually simplify things - if the user attempts to close it
> you
> > confirm they want to quit. And then you don't have to fuss around with
> > counting windows opened and closed.
> >
> > On Fri, Aug 2, 2019 at 9:19 AM Pat Bensky via 4D_Tech <
> > 4d_tech@lists.4d.com>
> > wrote:
> >
> > > I also have a question about this ...
> > > In our database we require at least one user window to always be open.
> > When
> > > a user closes a window, the close method counts the number of user
> > windows
> > > and if there is only one, it doesn't allow it to be closed.
> > > However ...
> > > If the user has opened another window within the same process (for a
> > > preview, for example), 4D now thinks there are two user windows open,
> and
> > > it allows the user to close it ... which of course closes both of the
> > > windows.
> > > Other than keeping track of all open windows-within-windows, which is
> > > messy, is there any way to differentiate main windows and their
> > associated
> > > windows within the same process?
> > >
> > > PB
> > >
> > > On Wed, 26 Jun 2019 at 16:08, Kirk Brooks via 4D_Tech <
> > > 4d_tech@lists.4d.com>
> > > wrote:
> > >
> > > > Hi Chris,
> > > > Good questions. Here are my thoughts on them based on what I've
> picked
> > up
> > > > from the World Tour and Summits.
> > > >
> > > > On Wed, Jun 26, 2019 at 12:31 AM Chris Belanger via 4D_Tech <
> > > > 4d_tech@lists.4d.com> wrote:
> > > >
> > > > > 1) What is the reasonable limit as to how many windows/dialogs
> should
> > > get
> > > > > opened in the same process?
> > > > >
> > > > This is going to be limited by the resources available to 4D. A
> laptop
> > > with
> > > > the minimum RAM and processor is going to have a lower limit than a
> > nice
> > > > new Mac Pro by a long way.
> > > >
> > > > But there's no reason to be opening a huge number of windows. A
> window
> > is
> > > > really a UI portal as it were. We no longer need to hack certain
> > > operations
> > > > with 'offscreen' or 'hidden' windows so a good design should open a
> > > window
> > > > for something useful.
> > > >
> > > > On top of that now it's really easy and fast to completely repurpose
> > > what a
> > > > window is 'doing' anyway. You could design a window interface to be a
> > lot
> > > > like the OS window interfaces are - you display something and then
> > > > completely change it based on a user action. But now we could revert
> to
> > > any
> > > > previous window content like the back button on a Finder window. You
> > > would
> > > > have to retain the displayed form and the Form contents but with that
> > > info
> > > > you could reload a past window.
> > > >
> > > > So I think this is a case where the technical limit on the number of
> > > > windows is less important than building a good design for the
> > interface.
> > > >
> > > >
> > > > > 2) do windows that share the same process also share processing
> time?
> > > > What
> > > > > I mean is: If window A is executing, does window B have to wait
> until
> > > > > Window A is done before any processing it does would start (think
> > CALL
> > > > FORM
> > > > > ( window ) )?
> > > > >
> > > > > For example: Window A is doing a QUERY that takes a few seconds.
> Does
> > > > that
> > > > > make Window B (in the same process) unresponsive until Window A has
> > > > > finished the QUERY?
> > > > >
> > > > Prior to preemptive processes each instance of 4D ran on a single
> core
> > of
> > > > the machine. How the CPU cycles were allocated and prioritized was
> > > between
> > > > 4D and OS. To us it looked like multiple processes were running
> > > 'parallel'
> > > > but it was all happening on a single core. The only way you could
> truly
> > > > have parallel processing was by using server side processes or
> EXECUTE
> > ON
> > > > CLIENT and each of those instances were limited in the same way.
> > > >
> > > > With a preemptive process you can truly have different processes
> > running
> > > > concurrently on different cores. Thomas Maul has some great demos of
> > > this.
> > > > If you aren't a Partner (they may be walled off from non-partners)
> > check
> > > > out a presentation he did for 4DMethod . He
> > 

Re: Managing multiple windows in the same process (v17r5)

[Wayne Stewart via 4D_Tech]

Hi,

One disadvantage is that there is only one execution stream with multiple
windows in the one process.

If something is taking time in one window (a sequential search or sort or a
even just a long method) execution will stop in all other windows, the UI
will freeze etc



On Sat, 3 Aug 2019 at 02:29, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Hi Pat,
> For something like that I would think about using a palette or toolbar-ish
> window as the 'root', if you will, for the UI process.
> That could actually simplify things - if the user attempts to close it you
> confirm they want to quit. And then you don't have to fuss around with
> counting windows opened and closed.
>
> On Fri, Aug 2, 2019 at 9:19 AM Pat Bensky via 4D_Tech <
> 4d_tech@lists.4d.com>
> wrote:
>
> > I also have a question about this ...
> > In our database we require at least one user window to always be open.
> When
> > a user closes a window, the close method counts the number of user
> windows
> > and if there is only one, it doesn't allow it to be closed.
> > However ...
> > If the user has opened another window within the same process (for a
> > preview, for example), 4D now thinks there are two user windows open, and
> > it allows the user to close it ... which of course closes both of the
> > windows.
> > Other than keeping track of all open windows-within-windows, which is
> > messy, is there any way to differentiate main windows and their
> associated
> > windows within the same process?
> >
> > PB
> >
> > On Wed, 26 Jun 2019 at 16:08, Kirk Brooks via 4D_Tech <
> > 4d_tech@lists.4d.com>
> > wrote:
> >
> > > Hi Chris,
> > > Good questions. Here are my thoughts on them based on what I've picked
> up
> > > from the World Tour and Summits.
> > >
> > > On Wed, Jun 26, 2019 at 12:31 AM Chris Belanger via 4D_Tech <
> > > 4d_tech@lists.4d.com> wrote:
> > >
> > > > 1) What is the reasonable limit as to how many windows/dialogs should
> > get
> > > > opened in the same process?
> > > >
> > > This is going to be limited by the resources available to 4D. A laptop
> > with
> > > the minimum RAM and processor is going to have a lower limit than a
> nice
> > > new Mac Pro by a long way.
> > >
> > > But there's no reason to be opening a huge number of windows. A window
> is
> > > really a UI portal as it were. We no longer need to hack certain
> > operations
> > > with 'offscreen' or 'hidden' windows so a good design should open a
> > window
> > > for something useful.
> > >
> > > On top of that now it's really easy and fast to completely repurpose
> > what a
> > > window is 'doing' anyway. You could design a window interface to be a
> lot
> > > like the OS window interfaces are - you display something and then
> > > completely change it based on a user action. But now we could revert to
> > any
> > > previous window content like the back button on a Finder window. You
> > would
> > > have to retain the displayed form and the Form contents but with that
> > info
> > > you could reload a past window.
> > >
> > > So I think this is a case where the technical limit on the number of
> > > windows is less important than building a good design for the
> interface.
> > >
> > >
> > > > 2) do windows that share the same process also share processing time?
> > > What
> > > > I mean is: If window A is executing, does window B have to wait until
> > > > Window A is done before any processing it does would start (think
> CALL
> > > FORM
> > > > ( window ) )?
> > > >
> > > > For example: Window A is doing a QUERY that takes a few seconds. Does
> > > that
> > > > make Window B (in the same process) unresponsive until Window A has
> > > > finished the QUERY?
> > > >
> > > Prior to preemptive processes each instance of 4D ran on a single core
> of
> > > the machine. How the CPU cycles were allocated and prioritized was
> > between
> > > 4D and OS. To us it looked like multiple processes were running
> > 'parallel'
> > > but it was all happening on a single core. The only way you could truly
> > > have parallel processing was by using server side processes or EXECUTE
> ON
> > > CLIENT and each of those instances were limited in the same way.
> > >
> > > With a preemptive process you can truly have different processes
> running
> > > concurrently on different cores. Thomas Maul has some great demos of
> > this.
> > > If you aren't a Partner (they may be walled off from non-partners)
> check
> > > out a presentation he did for 4DMethod . He
> also
> > > includes a demo of why pre-emptive processing only matters on actual
> > > hardware, not virtualized machines. I forget if that's in the 4DMethod
> > > preso or I saw it at a Summit. Bottom line: preemptive is meaningless
> on
> > a
> > > virtual machine because the virtual machine is running virtual cores
> and
> > > then entire virtual machine is running on a single instance of the host
> > > machine. So, if you plan to deploy on AWS or the like don't worry about
> > > 

Re: Managing multiple windows in the same process (v17r5)

[Kirk Brooks via 4D_Tech]

Hi Pat,
For something like that I would think about using a palette or toolbar-ish
window as the 'root', if you will, for the UI process.
That could actually simplify things - if the user attempts to close it you
confirm they want to quit. And then you don't have to fuss around with
counting windows opened and closed.

On Fri, Aug 2, 2019 at 9:19 AM Pat Bensky via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> I also have a question about this ...
> In our database we require at least one user window to always be open. When
> a user closes a window, the close method counts the number of user windows
> and if there is only one, it doesn't allow it to be closed.
> However ...
> If the user has opened another window within the same process (for a
> preview, for example), 4D now thinks there are two user windows open, and
> it allows the user to close it ... which of course closes both of the
> windows.
> Other than keeping track of all open windows-within-windows, which is
> messy, is there any way to differentiate main windows and their associated
> windows within the same process?
>
> PB
>
> On Wed, 26 Jun 2019 at 16:08, Kirk Brooks via 4D_Tech <
> 4d_tech@lists.4d.com>
> wrote:
>
> > Hi Chris,
> > Good questions. Here are my thoughts on them based on what I've picked up
> > from the World Tour and Summits.
> >
> > On Wed, Jun 26, 2019 at 12:31 AM Chris Belanger via 4D_Tech <
> > 4d_tech@lists.4d.com> wrote:
> >
> > > 1) What is the reasonable limit as to how many windows/dialogs should
> get
> > > opened in the same process?
> > >
> > This is going to be limited by the resources available to 4D. A laptop
> with
> > the minimum RAM and processor is going to have a lower limit than a nice
> > new Mac Pro by a long way.
> >
> > But there's no reason to be opening a huge number of windows. A window is
> > really a UI portal as it were. We no longer need to hack certain
> operations
> > with 'offscreen' or 'hidden' windows so a good design should open a
> window
> > for something useful.
> >
> > On top of that now it's really easy and fast to completely repurpose
> what a
> > window is 'doing' anyway. You could design a window interface to be a lot
> > like the OS window interfaces are - you display something and then
> > completely change it based on a user action. But now we could revert to
> any
> > previous window content like the back button on a Finder window. You
> would
> > have to retain the displayed form and the Form contents but with that
> info
> > you could reload a past window.
> >
> > So I think this is a case where the technical limit on the number of
> > windows is less important than building a good design for the interface.
> >
> >
> > > 2) do windows that share the same process also share processing time?
> > What
> > > I mean is: If window A is executing, does window B have to wait until
> > > Window A is done before any processing it does would start (think CALL
> > FORM
> > > ( window ) )?
> > >
> > > For example: Window A is doing a QUERY that takes a few seconds. Does
> > that
> > > make Window B (in the same process) unresponsive until Window A has
> > > finished the QUERY?
> > >
> > Prior to preemptive processes each instance of 4D ran on a single core of
> > the machine. How the CPU cycles were allocated and prioritized was
> between
> > 4D and OS. To us it looked like multiple processes were running
> 'parallel'
> > but it was all happening on a single core. The only way you could truly
> > have parallel processing was by using server side processes or EXECUTE ON
> > CLIENT and each of those instances were limited in the same way.
> >
> > With a preemptive process you can truly have different processes running
> > concurrently on different cores. Thomas Maul has some great demos of
> this.
> > If you aren't a Partner (they may be walled off from non-partners) check
> > out a presentation he did for 4DMethod . He also
> > includes a demo of why pre-emptive processing only matters on actual
> > hardware, not virtualized machines. I forget if that's in the 4DMethod
> > preso or I saw it at a Summit. Bottom line: preemptive is meaningless on
> a
> > virtual machine because the virtual machine is running virtual cores and
> > then entire virtual machine is running on a single instance of the host
> > machine. So, if you plan to deploy on AWS or the like don't worry about
> > preemptive, just use CALL WORKER.
> >
> > So all the windows in the UI process will work, essentially, like the
> > windows in the separate processes we used to use. 4D has optimized things
> > like query a lot, for example. And the speed is improved significantly. I
> > hear in v18 ORDA may be as fast as classic 4D queries.
> >
> >
> > > 3) I used separate processes before because it was possible to do
> > > ‘parallel processing’ that way. Because windows were in separate
> > processes,
> > > anything one window was working on would not impact the responsiveness
> of
> > > other windows.
> > > Is 

Re: Managing multiple windows in the same process (v17r5)

[John DeSoi via 4D_Tech]

You can use the Window process command to determine that both windows are in 
the same process.

John DeSoi, Ph.D.


> On Aug 2, 2019, at 11:18 AM, Pat Bensky via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> I also have a question about this ...
> In our database we require at least one user window to always be open. When
> a user closes a window, the close method counts the number of user windows
> and if there is only one, it doesn't allow it to be closed.
> However ...
> If the user has opened another window within the same process (for a
> preview, for example), 4D now thinks there are two user windows open, and
> it allows the user to close it ... which of course closes both of the
> windows.
> Other than keeping track of all open windows-within-windows, which is
> messy, is there any way to differentiate main windows and their associated
> windows within the same process?

**
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: Managing multiple windows in the same process (v17r5)

[Pat Bensky via 4D_Tech]

I also have a question about this ...
In our database we require at least one user window to always be open. When
a user closes a window, the close method counts the number of user windows
and if there is only one, it doesn't allow it to be closed.
However ...
If the user has opened another window within the same process (for a
preview, for example), 4D now thinks there are two user windows open, and
it allows the user to close it ... which of course closes both of the
windows.
Other than keeping track of all open windows-within-windows, which is
messy, is there any way to differentiate main windows and their associated
windows within the same process?

PB

On Wed, 26 Jun 2019 at 16:08, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com>
wrote:

> Hi Chris,
> Good questions. Here are my thoughts on them based on what I've picked up
> from the World Tour and Summits.
>
> On Wed, Jun 26, 2019 at 12:31 AM Chris Belanger via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>
> > 1) What is the reasonable limit as to how many windows/dialogs should get
> > opened in the same process?
> >
> This is going to be limited by the resources available to 4D. A laptop with
> the minimum RAM and processor is going to have a lower limit than a nice
> new Mac Pro by a long way.
>
> But there's no reason to be opening a huge number of windows. A window is
> really a UI portal as it were. We no longer need to hack certain operations
> with 'offscreen' or 'hidden' windows so a good design should open a window
> for something useful.
>
> On top of that now it's really easy and fast to completely repurpose what a
> window is 'doing' anyway. You could design a window interface to be a lot
> like the OS window interfaces are - you display something and then
> completely change it based on a user action. But now we could revert to any
> previous window content like the back button on a Finder window. You would
> have to retain the displayed form and the Form contents but with that info
> you could reload a past window.
>
> So I think this is a case where the technical limit on the number of
> windows is less important than building a good design for the interface.
>
>
> > 2) do windows that share the same process also share processing time?
> What
> > I mean is: If window A is executing, does window B have to wait until
> > Window A is done before any processing it does would start (think CALL
> FORM
> > ( window ) )?
> >
> > For example: Window A is doing a QUERY that takes a few seconds. Does
> that
> > make Window B (in the same process) unresponsive until Window A has
> > finished the QUERY?
> >
> Prior to preemptive processes each instance of 4D ran on a single core of
> the machine. How the CPU cycles were allocated and prioritized was between
> 4D and OS. To us it looked like multiple processes were running 'parallel'
> but it was all happening on a single core. The only way you could truly
> have parallel processing was by using server side processes or EXECUTE ON
> CLIENT and each of those instances were limited in the same way.
>
> With a preemptive process you can truly have different processes running
> concurrently on different cores. Thomas Maul has some great demos of this.
> If you aren't a Partner (they may be walled off from non-partners) check
> out a presentation he did for 4DMethod . He also
> includes a demo of why pre-emptive processing only matters on actual
> hardware, not virtualized machines. I forget if that's in the 4DMethod
> preso or I saw it at a Summit. Bottom line: preemptive is meaningless on a
> virtual machine because the virtual machine is running virtual cores and
> then entire virtual machine is running on a single instance of the host
> machine. So, if you plan to deploy on AWS or the like don't worry about
> preemptive, just use CALL WORKER.
>
> So all the windows in the UI process will work, essentially, like the
> windows in the separate processes we used to use. 4D has optimized things
> like query a lot, for example. And the speed is improved significantly. I
> hear in v18 ORDA may be as fast as classic 4D queries.
>
>
> > 3) I used separate processes before because it was possible to do
> > ‘parallel processing’ that way. Because windows were in separate
> processes,
> > anything one window was working on would not impact the responsiveness of
> > other windows.
> > Is it still advisable to break out windows under its own process if it
> may
> > need to do substantial processing at times?
> >
> It would be better to break out the heavy operations using CALL WORKER.
> This is really what it's designed for.
>
> Underlying all this is the question of memory management. I have the
> impression 4D is committed to optimizing memory use. New process
> 
> recommends 0 for the stack size, "Pass 0 in stack to use a default stack
> size, suitable for most applications (recommended setting)." The docs go on
> to say 

Re: Managing multiple windows in the same process (v17r5)

[Kirk Brooks via 4D_Tech]

Hi Chris,
Good questions. Here are my thoughts on them based on what I've picked up
from the World Tour and Summits.

On Wed, Jun 26, 2019 at 12:31 AM Chris Belanger via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> 1) What is the reasonable limit as to how many windows/dialogs should get
> opened in the same process?
>
This is going to be limited by the resources available to 4D. A laptop with
the minimum RAM and processor is going to have a lower limit than a nice
new Mac Pro by a long way.

But there's no reason to be opening a huge number of windows. A window is
really a UI portal as it were. We no longer need to hack certain operations
with 'offscreen' or 'hidden' windows so a good design should open a window
for something useful.

On top of that now it's really easy and fast to completely repurpose what a
window is 'doing' anyway. You could design a window interface to be a lot
like the OS window interfaces are - you display something and then
completely change it based on a user action. But now we could revert to any
previous window content like the back button on a Finder window. You would
have to retain the displayed form and the Form contents but with that info
you could reload a past window.

So I think this is a case where the technical limit on the number of
windows is less important than building a good design for the interface.


> 2) do windows that share the same process also share processing time? What
> I mean is: If window A is executing, does window B have to wait until
> Window A is done before any processing it does would start (think CALL FORM
> ( window ) )?
>
> For example: Window A is doing a QUERY that takes a few seconds. Does that
> make Window B (in the same process) unresponsive until Window A has
> finished the QUERY?
>
Prior to preemptive processes each instance of 4D ran on a single core of
the machine. How the CPU cycles were allocated and prioritized was between
4D and OS. To us it looked like multiple processes were running 'parallel'
but it was all happening on a single core. The only way you could truly
have parallel processing was by using server side processes or EXECUTE ON
CLIENT and each of those instances were limited in the same way.

With a preemptive process you can truly have different processes running
concurrently on different cores. Thomas Maul has some great demos of this.
If you aren't a Partner (they may be walled off from non-partners) check
out a presentation he did for 4DMethod . He also
includes a demo of why pre-emptive processing only matters on actual
hardware, not virtualized machines. I forget if that's in the 4DMethod
preso or I saw it at a Summit. Bottom line: preemptive is meaningless on a
virtual machine because the virtual machine is running virtual cores and
then entire virtual machine is running on a single instance of the host
machine. So, if you plan to deploy on AWS or the like don't worry about
preemptive, just use CALL WORKER.

So all the windows in the UI process will work, essentially, like the
windows in the separate processes we used to use. 4D has optimized things
like query a lot, for example. And the speed is improved significantly. I
hear in v18 ORDA may be as fast as classic 4D queries.


> 3) I used separate processes before because it was possible to do
> ‘parallel processing’ that way. Because windows were in separate processes,
> anything one window was working on would not impact the responsiveness of
> other windows.
> Is it still advisable to break out windows under its own process if it may
> need to do substantial processing at times?
>
It would be better to break out the heavy operations using CALL WORKER.
This is really what it's designed for.

Underlying all this is the question of memory management. I have the
impression 4D is committed to optimizing memory use. New process

recommends 0 for the stack size, "Pass 0 in stack to use a default stack
size, suitable for most applications (recommended setting)." The docs go on
to say the size is not total process memory and is influenced by things
like number of windows, number of forms, and so on. This isn't anything new
and doesn't address the situation you start off asking about.

I expect the memory allocation when you pass 0 stack size has been
addressed but it would be good for someone closer to the engineering team
to weight in on it.

-- 
Kirk Brooks
San Francisco, CA
===

What can be said, can be said clearly,
and what you can’t say, you should shut up about

*Wittgenstein and the Computer *
**
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
**