Many thanks for so much helpful feedback! It is wonderful to hear the different opinions, viewpoints (and the respective justifications) from seasoned developers on a variety of best practices for the 4D language framework.
We used to be in the habit of chipping away at compiler errors before releasing a new version, but had grown out of practice as there some that are quite tricky (and time consuming) to track down (and even more difficult to test that the original intended functionality still remains). However, after some sleuthing, we have just 32 syntax errors. 4D is remarkable in that it does allow for a very small team (or even a single person) to be very productive and to bring a lot of functionality in a short amount of time. Although, when there have been several 'cooks in the kitchen' developing one application over 20 years, it is quite daunting to consider the network of dependencies that exist (and what 'might break' if we make a change). Ad-hoc patching is highly unfavorable, but that is how it was set up when I arrived. Currently, the users can happily continue working without interruption and there is no compelling reason to make a change in the existing architecture right now. Thank you for confirming that there is nothing major changing between v15 and v16. We originally observed that (for at least one window) what worked in v11-v15 was not working in v16. It was simple to 'patch' fix, but as many of you have pointed out, we likely have some type coercion taking place. I have traced the issue (what this original email was about) in the debugger. There is a parent window with a tabbed interface, the variable in question was declared as a local variable in the form method, the 'on load' event. When selecting a different tab, the variable became 'UN-initialized" and produced a runtime error. It was a very common variable name, so maybe we can take a different route of investigation (after getting through the compiler checks). Most of the errors are along the lines of "The result of the function is not compatible with the expression" Again, Many thanks to the community of folks who added to this thread! On Wed, Aug 1, 2018 at 1:40 PM Keisuke Miyako via 4D_Tech < 4d_tech@lists.4d.com> wrote: > no, nothing major has changed with regards to form events and scope of > variables between v15 and v16. > > I am not saying that running interpreted is good or bad. > > when you run "syntax check" the only thing it checks is typing integrity. > on other words, the hundreds of errors it reports are basically all typing > errors. > > you could track the execution sequence with debug logging (database > parameter #34) or TRACE, > but the order of form events is really not the issue the here. > > you can forgive the typing integrity and do an ad hoc patch (like you > described in the original post) or face the typing issue head on, > but dealing with the error as if it was because of "scoping of variable > initialisation and form events" is the wrong approach, in my opinion. > > 2018/08/01 23:34、Noah via 4D_Tech <4d_tech@lists.4d.com<mailto: > 4d_tech@lists.4d.com>>のメール: > > Is is really 'that bad' to run in interpreted mode? > My original question was simply about the scoping of variable > initialization and form events in version 16. > > > > ********************************************************************** > 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 > ********************************************************************** ********************************************************************** 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 **********************************************************************
