Modal dialog dilemma

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Modal dialog dilemma

4D Tech mailing list
Using v 13.5 ...

I have a modal dialog which displays info from [Table A] and contains a
pop-up menu listing items form [Table B]. Sometimes it is necessary to
modify a [Table B] record, or add a new one, within that dialog. So we
change the window size (if necessary), find the record to be edited, or
create a new one, edit it and then either Save or Cancel, then resize the
window back to what it was (if necessary) and redisplay the original [Table
A] form. For the most part this works fine. However in some circumstances
the Save or Cancel from the second form "bleeds through" to the first one
and the dialog window closes. We have to have an ACCEPT or CANCEL in the
second form otherwise it won't unload.

Specifically, if a [Table B] record is edited - no problem. But if a new
[Table B] record is created and then edited - without saving the [Table A]
record first - then we have the bleed-through problem.

Note that when a new [Table B] record is added in this way, it's saved
before it can be edited - so it isn't a new record when it is edited. I
can't figure out why this behaves differently for a newly added record! Any
ideas?

Thanks
Pat

--
*************************************************
CatBase - The Database Publishing Solution
tel: +44 (0) 207 118 7889
w: http://www.catbase.com
skype: pat.bensky
*************************************************
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
Pat:

‘Bleed Through’ or as I have called it the ‘Butteryfly Effect’, has always been a nasty surprise and something that takes experience (and discipline) in large systems to not bite you from time to time. I know I have been bitten too many times. Pat without knowing for certain why this is happening to you I will discuss what we are doing to prevent this from happening at least with one cause.

We are rewriting our starting shell at this time. The bleed through is something we are trying to set up the shell to never have. Bold statement ‘never’. There are a few things that we are using to put the stop to this:

1. On all forms we never use variables. This is a very big step to help prevent this. Therefore the Accept or Cancel buttons on forms are never having the same name (well not likely to have the same name). This means that the ‘Accept’ button on one form in the same process does not get a value and it bleeds through to the other form(s).

2. We have a generic form that has several objects on it. At runtime we will make objects visible or not, and change their titles, positions, etc. This permits us to have one form that handles Alerts, Requests, and Confirms. We provide more features than that with these dialogs (like help buttons, trace, etc). This means this dialog gets used extensively. To date we have not found any bleed through from it.

3. In our code we do not use Process Variables (and about 15 Interprocess Variables). This goes a long way to reduce bleed through from one process method/form into another.

4. Dialogs that a process call up though will need to get the input from the user. We accomplish this through an object we call our Process Object. Inside the process object a object is created for every running process. When a form is opened within the process an object is created for that form. When a dialog is opened an object is created within that form object. There we set what all the dialog objects are to be, and we also return the results from the user input. The form that called the dialog gets the information it is looking for from this object. Once the information is obtained that dialog object is deleted from memory.

It seems complex and it would be if we had to write the code each time. We have written nice generic methods for its use. We also created macros as we do for all this stuff that makes it very quick to build a request dialog (for example) in our code.

To date we have not seen any bleed through. This was the main reason for developing this type of dialog.

In Summary:

1. Writing code without any Process Variables on Forms.
2. Writing code with a very limited use of Interprocess Variables.
3. Always using named objects rather than variables on Forms.
4. Using Objects extensively.

This is a code style we started back in 2004, but having the advantage of starting a shell from scratch in v15 (now v16R2) we have carried the above 4 goals to the maximum extreme. One of the reasons for this was ‘Bleed through’, which we have not seen to date. The design expectation is that it should be impossible for it to happen.

From your description, it is my opinion that this is something you could implement in your code (as long as you use 4D v12 or greater) to resolve the issue within the limited scope you describe. As you learn to like it, then you could expand it as you have time to rewrite old code, and in anything new that your write.

Jody


> On Jun 17, 2017, at 9:53 AM, Pat Bensky via 4D_Tech <[hidden email]> wrote:
>
> Using v 13.5 ...
>
> I have a modal dialog which displays info from [Table A] and contains a
> pop-up menu listing items form [Table B]. Sometimes it is necessary to
> modify a [Table B] record, or add a new one, within that dialog. So we
> change the window size (if necessary), find the record to be edited, or
> create a new one, edit it and then either Save or Cancel, then resize the
> window back to what it was (if necessary) and redisplay the original [Table
> A] form. For the most part this works fine. However in some circumstances
> the Save or Cancel from the second form "bleeds through" to the first one
> and the dialog window closes. We have to have an ACCEPT or CANCEL in the
> second form otherwise it won't unload.
>
> Specifically, if a [Table B] record is edited - no problem. But if a new
> [Table B] record is created and then edited - without saving the [Table A]
> record first - then we have the bleed-through problem.
>
> Note that when a new [Table B] record is added in this way, it's saved
> before it can be edited - so it isn't a new record when it is edited. I
> can't figure out why this behaves differently for a newly added record! Any
> ideas?
>
> Thanks
> Pat
>
> --
> *************************************************
> CatBase - The Database Publishing Solution
> tel: +44 (0) 207 118 7889
> w: http://www.catbase.com
> skype: pat.bensky
> *************************************************
> **********************************************************************
> 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:[hidden email]
> **********************************************************************

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
Thanks for your thoughtful and detailed reply Jody. I will experiment with
your suggestions.

I did a quick test of deleting the variable names for the Save and Cancel
buttons on the affected forms ... didn't help ):

We're in the process of moving to v16 but in the mean time ... stuck on v13.

Pat

On 17 June 2017 at 22:35, Jody Bevan via 4D_Tech <[hidden email]>
wrote:

> Pat:
>
> ‘Bleed Through’ or as I have called it the ‘Butteryfly Effect’, has always
> been a nasty surprise and something that takes experience (and discipline)
> in large systems to not bite you from time to time. I know I have been
> bitten too many times. Pat without knowing for certain why this is
> happening to you I will discuss what we are doing to prevent this from
> happening at least with one cause.
>
> We are rewriting our starting shell at this time. The bleed through is
> something we are trying to set up the shell to never have. Bold statement
> ‘never’. There are a few things that we are using to put the stop to this:
>
> 1. On all forms we never use variables. This is a very big step to help
> prevent this. Therefore the Accept or Cancel buttons on forms are never
> having the same name (well not likely to have the same name). This means
> that the ‘Accept’ button on one form in the same process does not get a
> value and it bleeds through to the other form(s).
>
> 2. We have a generic form that has several objects on it. At runtime we
> will make objects visible or not, and change their titles, positions, etc.
> This permits us to have one form that handles Alerts, Requests, and
> Confirms. We provide more features than that with these dialogs (like help
> buttons, trace, etc). This means this dialog gets used extensively. To date
> we have not found any bleed through from it.
>
> 3. In our code we do not use Process Variables (and about 15 Interprocess
> Variables). This goes a long way to reduce bleed through from one process
> method/form into another.
>
> 4. Dialogs that a process call up though will need to get the input from
> the user. We accomplish this through an object we call our Process Object.
> Inside the process object a object is created for every running process.
> When a form is opened within the process an object is created for that
> form. When a dialog is opened an object is created within that form object.
> There we set what all the dialog objects are to be, and we also return the
> results from the user input. The form that called the dialog gets the
> information it is looking for from this object. Once the information is
> obtained that dialog object is deleted from memory.
>
> It seems complex and it would be if we had to write the code each time. We
> have written nice generic methods for its use. We also created macros as we
> do for all this stuff that makes it very quick to build a request dialog
> (for example) in our code.
>
> To date we have not seen any bleed through. This was the main reason for
> developing this type of dialog.
>
> In Summary:
>
> 1. Writing code without any Process Variables on Forms.
> 2. Writing code with a very limited use of Interprocess Variables.
> 3. Always using named objects rather than variables on Forms.
> 4. Using Objects extensively.
>
> This is a code style we started back in 2004, but having the advantage of
> starting a shell from scratch in v15 (now v16R2) we have carried the above
> 4 goals to the maximum extreme. One of the reasons for this was ‘Bleed
> through’, which we have not seen to date. The design expectation is that it
> should be impossible for it to happen.
>
> From your description, it is my opinion that this is something you could
> implement in your code (as long as you use 4D v12 or greater) to resolve
> the issue within the limited scope you describe. As you learn to like it,
> then you could expand it as you have time to rewrite old code, and in
> anything new that your write.
>
> Jody
>
>
> > On Jun 17, 2017, at 9:53 AM, Pat Bensky via 4D_Tech <
> [hidden email]> wrote:
> >
> > Using v 13.5 ...
> >
> > I have a modal dialog which displays info from [Table A] and contains a
> > pop-up menu listing items form [Table B]. Sometimes it is necessary to
> > modify a [Table B] record, or add a new one, within that dialog. So we
> > change the window size (if necessary), find the record to be edited, or
> > create a new one, edit it and then either Save or Cancel, then resize the
> > window back to what it was (if necessary) and redisplay the original
> [Table
> > A] form. For the most part this works fine. However in some circumstances
> > the Save or Cancel from the second form "bleeds through" to the first one
> > and the dialog window closes. We have to have an ACCEPT or CANCEL in the
> > second form otherwise it won't unload.
> >
> > Specifically, if a [Table B] record is edited - no problem. But if a new
> > [Table B] record is created and then edited - without saving the [Table
> A]
> > record first - then we have the bleed-through problem.
> >
> > Note that when a new [Table B] record is added in this way, it's saved
> > before it can be edited - so it isn't a new record when it is edited. I
> > can't figure out why this behaves differently for a newly added record!
> Any
> > ideas?
> >
> > Thanks
> > Pat
> >
> > --
> > *************************************************
> > CatBase - The Database Publishing Solution
> > tel: +44 (0) 207 118 7889
> > w: http://www.catbase.com
> > skype: pat.bensky
> > *************************************************
> > **********************************************************************
> > 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:[hidden email]
> > **********************************************************************
>
> **********************************************************************
> 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:[hidden email]
> **********************************************************************




--
*************************************************
CatBase - Top Dog in Data Publishing
tel: +44 (0) 207 118 7889
w: http://www.catbase.com
skype: pat.bensky
*************************************************
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
In reply to this post by 4D Tech mailing list
I have seen this behaviour when both buttons have the same name. Changing
one of them solved the problem.

Date: Sat, 17 Jun 2017 16:53:18 +0100

> From: Pat Bensky <[hidden email]>
> To: 4D iNug Technical <[hidden email]>
> Subject: Modal dialog dilemma
> Message-ID:
>         <CANEBDtOFreimxF=
> [hidden email]>
> Content-Type: text/plain; charset="UTF-8"
>
> Using v 13.5 ...
>
> I have a modal dialog which displays info from [Table A] and contains a
> pop-up menu listing items form [Table B]. Sometimes it is necessary to
> modify a [Table B] record, or add a new one, within that dialog. So we
> change the window size (if necessary), find the record to be edited, or
> create a new one, edit it and then either Save or Cancel, then resize the
> window back to what it was (if necessary) and redisplay the original [Table
> A] form. For the most part this works fine. However in some circumstances
> the Save or Cancel from the second form "bleeds through" to the first one
> and the dialog window closes. We have to have an ACCEPT or CANCEL in the
> second form otherwise it won't unload.
>
> Specifically, if a [Table B] record is edited - no problem. But if a new
> [Table B] record is created and then edited - without saving the [Table A]
> record first - then we have the bleed-through problem.
>
> Note that when a new [Table B] record is added in this way, it's saved
> before it can be edited - so it isn't a new record when it is edited. I
> can't figure out why this behaves differently for a newly added record! Any
> ideas?
>
> Thanks
> Pat
>
> --
> *************************************************
> CatBase - The Database Publishing Solution
> tel: +44 (0) 207 118 7889
> w: http://www.catbase.com
> skype: pat.bensky
> ************************************************
>
--
*******************************************************************
Joaquín Mendes Castro
ASEMAT, S.A.                                     tlf: 34-91-4015099
Agustina de Aragón 3, Bajo C                     fax: 34-91-4018646
28006 Madrid (SPAIN)               e-mail: [hidden email]
*******************************************************************
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
In reply to this post by 4D Tech mailing list
Jody,

​Nice post. I've also implemented several of these ​ideas but you're really
going more deeply than I have. My motivation didn't have anything to do
with bleed through. They came about as I was working more and more with
objects and dynamic variables.

On Sat, Jun 17, 2017 at 2:35 PM, Jody Bevan via 4D_Tech <
[hidden email]> wrote:

> 1. On all forms we never use variables.
>
​Assuming you're talking about process variables. I agree mostly but there
are some times when they are still useful. Most recently as a dataChanged
flag. But that could be stored in the process object you t​ouch on later.

>
> 2. We have a generic form that has several objects on it. At runtime we
> will make objects visible or not, and change their titles, positions, etc.
> This permits us to have one form that handles Alerts, Requests, and
> Confirms. We provide more features than that with these dialogs (like help
> buttons, trace, etc). This means this dialog gets used extensively.
>
​I've played with this idea a bit too. Could you talk more about what kinds
of forms or records you're using this for? They are easy enough to
implement in concept but to make them look nice and such has been a
challenge for me. ​

4. Dialogs that a process call up though will need to get the input from
> the user. We accomplish this through an object we call our Process Object.
> Inside the process object a object is created for every running process.
> When a form is opened within the process an object is created for that
> form. When a dialog is opened an object is created within that form object.
> There we set what all the dialog objects are to be, and we also return the
> results from the user input. The form that called the dialog gets the
> information it is looking for from this object. Once the information is
> obtained that dialog object is deleted from memory.
>
​I caught a lot of flak last year when I suggested process variables had
become passe in favor of a single process object for managing the random
bits of information they are usually used for. I must admit I hadn't
thought about this approach. I like it. The form becomes more like a
reflection of the data (stored in the object) instead of the data actually
residing on the form. ​

Are you willing to talk about how you manage the fields and data in the
process object?

​This opens up a lot of options for things like inherited forms too as I
think of it. Instead of having different inherited forms in different sizes
there can be one and the objects simply sized as appropriate. ​

>
> It seems complex and it would be if we had to write the code each time. We
> have written nice generic methods for its use. We also created macros as we
> do for all this stuff that makes it very quick to build a request dialog
> (for example) in our code.
>
​What are some examples of the generic form methods you are using?​

​You know, this also allows for you to create a hell of an error log - you
could ​write the process object to the error record in addition to the
other stuff.

--
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
In reply to this post by 4D Tech mailing list
how about:
in first form:
b_accepct_form_1 (no action - code does an accept
b_cancel_form_1 (no action) - cade does cancel

second form:
b_accepct_form_2 (no action - code does an accept
b_cancel_form_2 (no action) - cade does cancel

Note :
- No automatic action(s)
- different button names

this *should* stop the bleed through


On Sat, 17 Jun 2017 16:53:18 +0100, Pat Bensky via 4D_Tech wrote:

> Using v 13.5 ...
>
> I have a modal dialog which displays info from [Table A] and contains a
> pop-up menu listing items form [Table B]. Sometimes it is necessary to
> modify a [Table B] record, or add a new one, within that dialog. So we
> change the window size (if necessary), find the record to be edited, or
> create a new one, edit it and then either Save or Cancel, then resize the
> window back to what it was (if necessary) and redisplay the original [Table
> A] form. For the most part this works fine. However in some circumstances
> the Save or Cancel from the second form "bleeds through" to the first one
> and the dialog window closes. We have to have an ACCEPT or CANCEL in the
> second form otherwise it won't unload.
>
> Specifically, if a [Table B] record is edited - no problem. But if a new
> [Table B] record is created and then edited - without saving the [Table A]
> record first - then we have the bleed-through problem.
>
> Note that when a new [Table B] record is added in this way, it's saved
> before it can be edited - so it isn't a new record when it is edited. I
> can't figure out why this behaves differently for a newly added record! Any
> ideas?
>
> Thanks
> Pat
>
> --
> *************************************************
> CatBase - The Database Publishing Solution
> tel: +44 (0) 207 118 7889
> w: http://www.catbase.com
> skype: pat.bensky
> *************************************************
> **********************************************************************
> 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:[hidden email]
> **********************************************************************
---------------
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing
**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
Interestingly we discovered one source of bleed through was our users.
Some of our users would double click the accept or cancel button.
So, I set the button in the background window to disabled, and enabled it
about 1 second after the foreground window was closed.

Dave Porter
Tailored Solutions, Inc.
Business Management Software for Label Converters
http://www.labeltraxx.com/                414-774-9997

> On Jun 19, 2017, at 9:55 AM, Chip Scheide via 4D_Tech <[hidden email]> wrote:
>
> how about:
> in first form:
> b_accepct_form_1 (no action - code does an accept
> b_cancel_form_1 (no action) - cade does cancel
>
> second form:
> b_accepct_form_2 (no action - code does an accept
> b_cancel_form_2 (no action) - cade does cancel
>
> Note :
> - No automatic action(s)
> - different button names
>
> this *should* stop the bleed through
>
>
> On Sat, 17 Jun 2017 16:53:18 +0100, Pat Bensky via 4D_Tech wrote:
>> Using v 13.5 ...
>>
>> I have a modal dialog which displays info from [Table A] and contains a
>> pop-up menu listing items form [Table B]. Sometimes it is necessary to
>> modify a [Table B] record, or add a new one, within that dialog. So we
>> change the window size (if necessary), find the record to be edited, or
>> create a new one, edit it and then either Save or Cancel, then resize the
>> window back to what it was (if necessary) and redisplay the original [Table
>> A] form. For the most part this works fine. However in some circumstances
>> the Save or Cancel from the second form "bleeds through" to the first one
>> and the dialog window closes. We have to have an ACCEPT or CANCEL in the
>> second form otherwise it won't unload.
>>
>> Specifically, if a [Table B] record is edited - no problem. But if a new
>> [Table B] record is created and then edited - without saving the [Table A]
>> record first - then we have the bleed-through problem.
>>
>> Note that when a new [Table B] record is added in this way, it's saved
>> before it can be edited - so it isn't a new record when it is edited. I
>> can't figure out why this behaves differently for a newly added record! Any
>> ideas?
>>
>> Thanks
>> Pat
>>
>> --
>> *************************************************
>> CatBase - The Database Publishing Solution
>> tel: +44 (0) 207 118 7889
>> w: http://www.catbase.com
>> skype: pat.bensky
>> *************************************************
>> **********************************************************************
>> 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:[hidden email]
>> **********************************************************************
> ---------------
> Gas is for washing parts
> Alcohol is for drinkin'
> Nitromethane is for racing
> **********************************************************************
> 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:[hidden email]
> **********************************************************************

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
In reply to this post by 4D Tech mailing list
Kirk Brooks:

Thank you for your kind words. My son (Adam Bevan) and I have multiple motivation for writing our shell the way we are. ‘Bleed Through/Butterfly effect’ were one of them. It is likely that our very large application we previously had showed us that it can bite one too easily without strict discipline in coding.

Once we got comfortable with v12 we started creating forms with dynamic variables. With the multiple ongoing jurisdictional requirement changes and certifications we just never got enough time to implement them much. Therefore when rewriting the shell which I usually did ever ~ 5 years, we are doing the most ambitious rewrite. Every line of code is being rewritten in a clean room concept. We want to encourage ourselves to write all the code with the latest tools 4D provides us.

Another reason for not using process Variables is to reduce the memory foot print. As every process variable no matter how little it is used gets memory reserved for it in every process, no matter how small the process is or little the process is.

It is always easy to slip in to old tried and proven paths (ruts) when coding. There are times when we have slipped into putting in some process variables. I just looked at our COMPILER_Prov_Var method. We currently have 7 Process Variables. I know we had more but as the shell reaches its feature set we are removing them.

I understand what you are saying about flag variables. It is so easy and convenient to use a process variable for this. On our journey of writing the shell we have done that. At times though we have reassessed our use of them. It made us take some time and say how else can we do this. Our Object module is evolving very nicely. We are getting very used to putting flags, and many other things into these objects and then looking for them there. It is becoming natural to do so now.

One of the first items that Adam built was dot notation object handlers (Set/Get/Clear). I am sure he could have used Cannon’s highly rated module, but he wanted to do for himself. The next was to create an Object Viewer. The Object Viewer supports viewing a whole tree in the dot notation, and diving deeper into the tree to focus on specifics. It also permits us to modify the object values which is a huge time saver when initially developing a new feature.

A side benefit of the Object Viewer is that it is available in a compiled application. Therefore all of these flags, etc are available to be viewed at runtime in the compiled application. So great to getting a view of all this management information that we have. We are building our shell to handle all of the things that we encountered in our previous regulatory world out of the box. As we encountered back then there are jurisdictions that have little regulation so users would opt for little controls (typically a small 2 user site where trust was implicit). Therefore the shell is designed to have items turned on or off. All of this control data is stored in a few objects so that they are quick to access and modify. We something strange happens it is easy for us to at least see what the settings are.

We are also including many of the wonderful interface features that we accumulated over the years in our previous shell. These are things that I would hate not to have if I was working with the system. This includes things like the size and position of a window that the user likes for that specific window. How many items in a popup list they want as a maximum, after which it will be a scrollable selection dialog. There are literally hundreds of these options / features that we are building in.

As a user logs out and another use in, the objects are changed out and the application behaves differently. The Object feature of 4D makes this all very possible and efficient (we used ObjectTools in the past).

There are several forms. The first three are the most heavily used:

- Single Output Form.
- Included Button Tool Bar form
- Alert/Request/Confirm Dialog

Single Output Form

There is only one Output form for the whole application. We use selection Listbox. Of course every table will have different possible fields to be loaded into the output form. Not only that each person will have a different requirement for which fields they are permitted to see, or would like to see. In addition to this there may be calculated values (non-field data) that they would like displayed.

Therefore like all our listboxes in the shell they are built dynamically via code. This ability lets the users feel like they have control over the application rather than the other way around. The system administrator sets up default output forms for each role of users. Therefore if they are not so included to set them up they are done for them. We also have a ‘factor setting’ so that even the System Administrator does not have to do this work.

With all the controls available for controlling listboxes we can provide many user controllable features (min / max width), default width, alternate colours, font, font style, font size, sort orders, column positions, and many more.

Of course underneath all of this is the security of records. Who can view who cannot view, are there fields of data they cannot view etc. This is all handled for all the tables with the one Output Form.

We also have many standard features that are available on the form. Security underpins it all and removes the items that the user does not have access to. Therefore a user with little access will always have a very simple form which means much less training for them, less clutter for them to filter out.

Many of these features will automatically appear once the user adds an item (saved search, saves sets, saved reports, etc). The user / system Admin can determine which users have access to these items as well. The beauty of this is that all tables have exactly the same appearance as all others - simply because there is only one form.

If there is a bug we fix it once - done. If we add a feature we only need to add it in one place - it is everywhere.

This is the shell we plan on using to develop other applications for. It is only good as a shell if it saves time. The Single Output Form is a huge time saver in so many ways.

The form itself has zero process variables or interprocess variables. All flags etc are stored in our standard objects. Therefore once you get to know where this is you know exactly where to look. I am writing the programmers manual for the shell as we write the shell.

Inherited Button Tool Bar Form

This really should be considered as much more than just the button tool bar, but that is the biggest part. We could have gone the way of having a single form for the whole application (like the Output), but for now at least, we decided not to go that far with it. Input forms can have such dramatically different features. Having said that we know from training and supporting thousands of users on our last system that consistency is critical to faster learning, more complete usage, and fewer support calls.

To this end having a specific button bar is key,  (with custom designed buttons). Again the same data in the objects is used to control the visibility of the various buttons, popups, administrative tools in the input.

As you might be getting, security is a foundational concern. Therefore which fields show up for a specific user or user’s role is controlled by the information in the objects. This is where we have a strict object naming convention for our fields, and labels. By doing this when the security code is gone through the appropriate fields, labels, groups, etc are made visible, non-visible, enterable, non-enterable.

We recognized that the same form may be opened in different processes, and in some cases within the same process. Therefore our object structure needed to support this. One of the key ideas was that we have a process object. This object contains process specific items. Which forms open, sets, named selections, form open, window Ids (important for Call Worker / Call Form), Process Ids, Table number, table name, Status of the form, status of specific form objects, and so much more. Having all this information in one easy to access location makes coding issues so much easier to handle.

Trying to write this for each input form would be a huge job. By writing it from scratch with this in mind from the beginning makes this a joy when creating a new input form. Our ‘Inherited input Form’ makes so much of the work easier. It even has built in vertical and horizontal guides for helping us place objects on each form in a consistent manner. Really all we need to deal with on an Input form is the table / form specific items. This saves us lots of time - a key requirement of a shell.

Alert/Request/Confirm Dialog

We have one form for these three types of dialogs. Each part of the form is ‘controlled’ by the data in our Parameter Object.
        - Window Type, Window Title, Which of the 4 buttons to show (with their title), Message to User, User Response, Button Access to Help, Which button clicked, Response by the user.

We have a DEV Macro that sets this all up so setting up the code for a dialog and for responding to the dialog takes 2 seconds to place the code. Then just set up the specifics in the code by highlighting and changing as appropriate.

The form has no process variables. This ensures there is no butterfly effect ever. The code is easy to write as we just get a pointer to each object that we know what the name of the object is. The form itself will change it’s size up to a defined limit if the message to or from the user is longer text.

The code that sets up the control for the dialog creates a sub object within the process object. Once the response from the user is obtained by the calling method that specific object is deleted from memory. This way there is not a problem with multiple dialogs open within the whole application or within a process.

These are just some of the forms we do this with. We have several others that we have developed within the shell. Of course when an application is created with the shell the same approach will be taken.


re: I caught a lot of flak last year when I suggested process variables had
> become passe in favor of a single process object for managing the random
> bits of information they are usually used for.

I am not certain if I understand you or you understand me. I do not think that for other than some forms we have gone to not having field information on it. We have though removed all process variables by placing form variables on screen that do not get an object name instead of a variable name. With some of our forms it is true that the data on the form is contained in an object and the form is really just a temporary container for that object information.

An example where we do this is for all the Preferences we have in the system. There are hundreds of them. Some are boolean, some are ‘pictures’, others colours, numbers, and text. All of the preferences are stored in an object. Therefore the form when displaying them is just displaying what is in the object. The Listbox with the 4D View Pro feature set of being able to have an object column that displays different controls based on the type of data in the object is a great enhancement to the user interface. Way back in v12 we had 50 pages of preferences (System Admin, Organization, Site, Computer, and User) all totalled. The feature set of Listboxes in 16R2 is critical to being able to do all of this - as it is all dynamic within code.

Now we have one preference page for each of the types. On each page is a single Listbox with a Group selector popup. We may move this onto a single input form just changing the titles etc in the future. For now though we see great advantage in time saving, and simplicity for the user over what we had previously. Now we can add a new preference and it will typically just show up in the appropriate place. No extra space on a form, no coding on the form to handle it.

We wanted this as our vision for the shell is that it will be used to create many different application - simple to very sophisticated, from one user to thousands of users at once. Our goal is that we can use the shell to jump start a project with all of these features while not burdening them down with things they do not want.

I cannot see any reason to have a process variable on a form any more. Now that we have our Object Viewer and the underlying Object ‘Dynamic Library’ there is no need. Too many advantages in doing it this way compared to a variable on a form.


re: Are you willing to talk about how you manage the fields and data in the
> process object?

I suppose I have my head too deep into our project to understand what you are asking for. It now just all seems so obvious. Having said that if you talk to my son a year ago he would likely have expressed frustration by my lack of getting it. It is a paradigm shift working with objects for storing the data rather than variables.

re: ​This opens up a lot of options for things like inherited forms too as I
>
> think of it. Instead of having different inherited forms in different sizes
> there can be one and the objects simply sized as appropriate. ​

Absolutely! This way of coding reduces the number of forms greatly. I expect that the memory footprint used by applications developed by the shell will be significantly reduced from what it would be.

re: What are some examples of the generic form methods you are using?​

There are many that we have. So many that we created a DEV Macro palette that we use while coding. When we need a new Input form we just select the macro for that type of a form. The code is in. If we need a listbox on a page we just use the DEV Macro Pallet to select the code for building a listbox. We currently have many generic methods. As this is the shell most of our code is generic. Some examples are:

- STD_inputMethod: This method calls a whole set of other generic methods. Based on object data, and object names it will do things like:
        - Set up the form help caller, add to the count of that user using the form
        - Handle security of access to the form (view/modify/delete), same for field access, Audit trail of access, window title, colours
                field background colours, Setup Menu, button access (and more). All of these tasks I mention are controlled by generic methods.
                Therefore the code is done, do not need to be touched for this code to be written for the form. LOVE THIS!

- Logging: This code is very standardized. This is a lesson we learned hard over the last 30 years. Logging of our code progress
        is critical for finding crashing, or problems. Therefore all our Dev Macros have calls to our logging. We have three types
        of logging that we do (beyond what is built into 4D itself). The logging can be turned on or off as required. As well we can
        set the level of the logging. Of course the logs can be sent back to us automatically. The importance of logs cannot be
        understated. LOVE THIS - even now while still programming!

- Listbox Setup: We have a few lines of code that we paste in from the DEV_Macros to setup a listbox. Need more columns, just copy a line, and adjust a few strings in the line.

- Listbox Configuration by User: This is all built into the Listbox Setup. The method for this is called automatically from within the Listbox. The user’s configuration for the listbox is all stored for each listbox for that user. They set it once and they have it just the way they like it. So jurisdiction requirements, user preferences, business type, business needs etc. All of this is handled within the generic code of our listbox. LOVE THIS!

- Clairvoyance for fields. This is a single set of code that is generic (of course). Pasting in from the Dev Macro and change a few strings and it is set up. It handles which lists, show description, or code, and much more. Very sophisticated. The whole feature set of the Clairvoyance fields was one of the favourite among our user base. Though not really clairvoyance, our date handler for fields is also very good. No more improperly entered dates / times, yet entering them is very very quick.

As I say there are many more. I just looked quickly at an input form. We have not written any application specific code as of yet so most of the code we have written are generic. This is all done without any process variables (other than the few I mentioned). We will delete these as we needed them initially to build and test our Object code, and other generic code. Now that we have the objects feature sophisticated enough, we do not need these process variables. The only Interprocess variables are the objects.


Kirk, I hope this is what you were looking for.

Sincerely

Jody


> On Jun 18, 2017, at 3:13 PM, Kirk Brooks via 4D_Tech <[hidden email]> wrote:
>
> Jody,
>
> ​Nice post. I've also implemented several of these ​ideas but you're really
> going more deeply than I have. My motivation didn't have anything to do
> with bleed through. They came about as I was working more and more with
> objects and dynamic variables.
>
> On Sat, Jun 17, 2017 at 2:35 PM, Jody Bevan via 4D_Tech <
> [hidden email]> wrote:
>
>> 1. On all forms we never use variables.
>>
> ​Assuming you're talking about process variables. I agree mostly but there
> are some times when they are still useful. Most recently as a dataChanged
> flag. But that could be stored in the process object you t​ouch on later.
>
>>
>> 2. We have a generic form that has several objects on it. At runtime we
>> will make objects visible or not, and change their titles, positions, etc.
>> This permits us to have one form that handles Alerts, Requests, and
>> Confirms. We provide more features than that with these dialogs (like help
>> buttons, trace, etc). This means this dialog gets used extensively.
>>
> ​I've played with this idea a bit too. Could you talk more about what kinds
> of forms or records you're using this for? They are easy enough to
> implement in concept but to make them look nice and such has been a
> challenge for me. ​
>
> 4. Dialogs that a process call up though will need to get the input from
>> the user. We accomplish this through an object we call our Process Object.
>> Inside the process object a object is created for every running process.
>> When a form is opened within the process an object is created for that
>> form. When a dialog is opened an object is created within that form object.
>> There we set what all the dialog objects are to be, and we also return the
>> results from the user input. The form that called the dialog gets the
>> information it is looking for from this object. Once the information is
>> obtained that dialog object is deleted from memory.
>>
> ​I caught a lot of flak last year when I suggested process variables had
> become passe in favor of a single process object for managing the random
> bits of information they are usually used for. I must admit I hadn't
> thought about this approach. I like it. The form becomes more like a
> reflection of the data (stored in the object) instead of the data actually
> residing on the form. ​
>
> Are you willing to talk about how you manage the fields and data in the
> process object?
>
> ​This opens up a lot of options for things like inherited forms too as I
> think of it. Instead of having different inherited forms in different sizes
> there can be one and the objects simply sized as appropriate. ​
>
>>
>> It seems complex and it would be if we had to write the code each time. We
>> have written nice generic methods for its use. We also created macros as we
>> do for all this stuff that makes it very quick to build a request dialog
>> (for example) in our code.
>>
> ​What are some examples of the generic form methods you are using?​
>
> ​You know, this also allows for you to create a hell of an error log - you
> could ​write the process object to the error record in addition to the
> other stuff.
>
> --
> Kirk Brooks
> San Francisco, CA

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
Wow Jody—impressive! So, when does your new shell go on sale? :)

Robert

Sent from my iPhone

> On Jun 19, 2017, at 11:08 AM, Jody Bevan via 4D_Tech <[hidden email]> wrote:
>
> Every line of code is being rewritten in a clean room concept. We want to encourage ourselves to write all the code with the latest tools 4D provides us.

**********************************************************************
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:[hidden email]
**********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Modal dialog dilemma

4D Tech mailing list
Robert:

We have two projects that we will use the new shell in once it is completed ~ 3 months. Once those projects are done then we will likely put the shell on sale. The two projects will be a good test of the utility of the shell and point out some holes that we do not see now.

Therefore I am expecting about the June 2018 timeline.

Jody

> On Jun 29, 2017, at 12:21 AM, Robert ListMail via 4D_Tech <[hidden email]> wrote:
>
> Wow Jody—impressive! So, when does your new shell go on sale? :)
>
> Robert
>
> Sent from my iPhone
>
>> On Jun 19, 2017, at 11:08 AM, Jody Bevan via 4D_Tech <[hidden email]> wrote:
>>
>> Every line of code is being rewritten in a clean room concept. We want to encourage ourselves to write all the code with the latest tools 4D provides us.
>

**********************************************************************
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:[hidden email]
**********************************************************************