Re: Modal dialog dilemma
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 > <4d_tech@lists.4d.com> 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 <4d_tech@lists.4d.com> >> 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:4d_tech-unsubscr...@lists.4d.com **
Re: Modal dialog dilemma
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 <4d_tech@lists.4d.com> > 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:4d_tech-unsubscr...@lists.4d.com **
Re: Modal dialog dilemma
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 listboxe
Re: Modal dialog dilemma
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 <4d_tech@lists.4d.com> > 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:4d_tech-unsubscr...@lists.4d.com >> ** > --- > 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: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: Modal dialog dilemma
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:4d_tech-unsubscr...@lists.4d.com > ** --- 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:4d_tech-unsubscr...@lists.4d.com **
Re: Modal dialog dilemma
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 < 4d_tech@lists.4d.com> 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 touch 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:4d_tech-unsubscr...@lists.4d.com **
Re: Modal dialog dilemma
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 > To: 4D iNug Technical <4d_tech@lists.4d.com> > Subject: Modal dialog dilemma > Message-ID: > 6wllmn5evhdobutgru7wrvhlsbb+jaku...@mail.gmail.com> > 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: joaquin.men...@asemat.es *** ** 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: Modal dialog dilemma
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 <4d_tech@lists.4d.com> 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 < > 4d_tech@lists.4d.com> 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 b
Re: Modal dialog dilemma
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 <4d_tech@lists.4d.com> > 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 > *
Modal dialog dilemma
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:4d_tech-unsubscr...@lists.4d.com **
