Since the first release of the graphical versions of the TAS language going back to at least 2001, minimized forms loaded by the runtime engine including the main form of the initial main menu program would appear in the lower left hand corner of the Windows desktop with just a portion of the form caption and the restore, maximize and close buttons. The application itself remained in the taskbar, but clicking that button on/off it would reveal the minimize form in the lower left hand corner, but nothing more. Further, if additional forms were loaded from the main menu program or via a program that the main menu called (in the TAS environment typically via a "CHAIN" command), each minimized form would "stack" themselves horizontally from left to right. The main menu form or these other "child-like" forms could be restored by clicking on the desired form in the lower left hand corner of the screen. This location remained constant regardless of where the user might have positioned their Windows taskbar.
 |
| Example of main window form's minimize button |
The behavior described above is obviously not typical Windows behavior; but, it is also not an idiosyncracy or intentional implementation of form minimization within the TAS programming environment. Rather, it relates to the underlying development language where this is a potential default behavior. This is then complicated by the modular nature of the TAS language, where forms that are loaded are not necessarily child forms tied to a single application. In the Delphi language which TAS was ported to from its assembly language beginnings by Business Tools, Inc., the taskbar button belongs to a special application window and not the main form of the application, and only it by default has a special Windows extended style that is applied to it. Subsequently created forms do not have this style (nor is there a form property on the designed form to give it that style). Absent applying this style and hiding the main application window and more, subsequently loaded forms do not minimize to the task bar (and are also not detectable by cycling through running programs, e.g. ALT-TAB). Nothing in the modern TAS runtime engines is trying to minimize forms to the lower left hand portion of the screen.
With TAS Premier 7i rel. 8 that we released in April of 2013, in attempting to resolve some issues involving RUN programs (one of two different types of programs that the runtime engine can process), we were able to successfully make mounted screens (which actually are Windows forms) minimize to the task bar using extended Windows style API calls. However in trying to do that with the GUI-type RWN programs which load graphical screens (DFM's), we ran into some issues and decided to leave the handling for those alone.
The problem: Win 10 font display customization
In the past several months, however, a new issue has surfaced (and initially reported by two of our accounting software users) relating to customizing Windows 10 font display size whereby if the main menu form of the main menu program is minimized, the resized lower left hand corner form simply vanishes; and worse, it cannot be retrieved by clicking on the taskbar icon or in any other fashion.
 |
| Windows 10 at the standard non-customized 96 DPI (100%) setting: note that when minimized, the small resized form appearing at lower left |
Changing the font size in Windows 10:
 |
| Windows 10: changing the font size to 125% (120 dpi) |
 |
| Windows 10 Adv tool bar mode after font change |
 |
| Windows 10 at 125% (i.e. 120 dpi) of standard font size: minimize the initial program form and it disappears (lower left hand corner of screen is blank); and it can't be brought back by clicking on the taskbar icon, nor via ALT-TAB or the equivalent |
Curiously, users have been able to change their font DPI settings in Windows for some time and when increasing them in those prior Windows versions, this minimization issue did not present itself: the forms were still resized to the same expected, albeit unusual, location.
 |
| Windows 7 Pro custom DPI settings: increasing font sizes did not create minimization issues. Nor did similar setting changes impact XP Pro. |
Because this new problem meant that the application would become stuck in memory without the end user being able to regain access if they minimized a main menu form, we concluded that we had to come up with a workaround. Revisiting changes that we made in 2013 for RUN style forms, and after experimenting with numerous other options and making some other beneficial changes to the runtime, the answer was to apply extended Windows styles which not only solved the custom DPI settings issue in Windows 10, but also caused forms to minimize to the task bar. In doing this, however, the expected form order (i.e. the Z-order) was changed. In short, forms were often appearing behind other forms and these could include lookups, modal forms, print dialog boxes, many types of system messages, and more. The only solution to that was to ensure that new forms that are dynamically created in the runtime environment were "top most" in order to maintain Z-order.
Forms appearing behind forms is a problem that users can experience with many different types of Windows applications. We've even seen it happen with Javascript "alert" message boxes appearing behind a browser window. When this happens, a program may appear to be "stuck" or "frozen" when in fact cascading or tiling one's windows (right click on the blank portion of the taskbar) will reveal the hidden window and enable end user control of the application.
And while this solution worked, it meant we had to track down every different type of message (over six different types with different internal calls) to try to ensure that they came up over any given form that they might be called from. And this was one of the reasons why we had not made this change in 2013. But after a significant effort, that has been accomplished.
With release 12 installed into an Advanced Accounting installation:
 |
| Windows 10 with TAS Premier 7i rel. runtime with Advanced Accounting 8 main menu minimized |
 |
| Windows 10 with TAS Premier 7i rel. 12 runtime with the main menu and three other programs/form minimized called from the main menu via a standard chain command |
 |
| Windows 10 with TAS Premier 7i rel. 12 runtime with the main menu minimized plus a second runtime minimized called from the first via chain command with a "newruntime" option |
It is interesting how different Window operating systems will minimize forms differently belonging to the same application. As indicated with the Win 10 examples above they remain in the same "group" (the same thing will happen if you run say five instances of NOTEPAD and they will all be grouped together via single taskbar button).
Windows 7 is somewhat similar, but different:
 |
| Windows 7 Pro with TAS Premier 7i rel 12 with the main form and three programs called by a standard chain and a fourth via a newruntime from Advanced Accounting |
And in XP Pro, form minimization occurs yet differently. Each option minimizes to the taskbar separately rather than grouped together:
 |
| XP Pro and TAS Premier rel. 12 runtime with Advanced Accounting, main program and three programs/forms minimized via standard chain commands with taskbar docked to right side of screen |
The remaining obstacle
A new obstacle now that will remain is that despite the fact that programs should now minimize to the taskbar on any operating system that is in available and regardless of font settings, if a user launches another program or clicks on something that is running in their taskbar, they will have to minimize a running TAS RWN style program to allow the other application to come up on top. We would have preferred to have these work like RUN forms do, but it isn't something that at least for now can work any other way.
Since TAS applications typically are critical accounting/financial solutions, keeping many of the programs as "top most" isn't completely illogical, but it also isn't something that we had intended to do: it was just the only solution to the problem.
Because of potential conflicts that could arise in calling other executables or simply in certain circumstances within the runtime environment, we also recognized that we had to provide some programmatic control to override the new "top most" behavior that a programmer could utilize when necessary. And so a new function exists in release 12 by the same name as the Windows API function call that it makes: SetWindowPos. And the nice thing about it is that it can change the Z-order of the form and make it instead top, no[t] top most, bottom or top most after the form has been created. While some situations may still represent a challenge, with also now the SetWindowPos() availability, most challenges this behavior causes should be capable of being overcome.
To allow the main menu program to still allow other third party programs to load on top of it, we recommend placing a function call to SetWindowPos() in the "OnDisplayScreen" (aka "OnShow") label of the main menu form since it does not need to be "top most" (but it will be by default be created that way starting with release 12). There are several open file type dialogs that were not practical for us to force to be top most, and so function calls to get_file(), get_run_prg(), and dual_list_exec() will need to be reviewed within any application that uses them to add SetWindowPos() calls before and after their use. Any use of exec and the TShellEXE will also need to be reviewed and tested. See the help documentation for more information. For the most part, relatively few changes should be required.
TAS Premier 7i release 12 published today
So release 12 is being published today with the extended "WinForm" styles as mentioned above, and it will also be the basis for the next major release of Advanced Accounting. In addition to the SetWindowPos() function, it also includes a manifest embedded version targeted for various Microsoft operating systems including Windows 10, support for a "reply to" option in the TAS email function, a new "Page Style" band in the report designer, improvements to maintain database and other utilities including changes to issues relating to the extended form style change.
More information:
TAS Premier 7i updates for existing installations
TAS Premier 7i download for new installations
No comments:
Post a Comment