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 > ************************************************* > ********************************************************************** > 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 **********************************************************************
