Support Board

We are doing some work, related to Minimized windows, and we realize that this whole concept of minimizing a window within the larger MDI container window does not make sense.

When minimizing a window, it goes all the way down to the bottom and usually ends up getting hidden by other windows and you effectively lose it. In some cases it may not even be visible because in the case of the virtual space when enabled, the minimized window is placed all the way at the bottom of the virtual space and you have to scroll down to see it.

If other windows are overlapping the minimized window, you have to then move those out of the way. Also you have no idea what window is what among all of the minimize windows at the bottom. They are just a bunch of block rectangles.

You can only logically restore it through the CW menu by knowing which one it is and that is not entirely clear.

The whole minimize concept within the context of a multiple document interface, does not make sense.

Instead what we are going to do is as follows:

For minimize, we will support the following:

No Action (In which case, there is no minimize button)

Hide Window (you can then unhide it, from the CW menu and the hidden windows will be clearly identified)

Resize the window to a predefined width and height, that you will set, and keep the top left coordinate in place. So the size of it will be greatly reduced or reduced whatever size you preset. Keeping it in place makes sense. Rather than pushing it all away down to the bottom and having no way to even know what window is what at the bottom. They just look like a bunch of rectangular blocks. It is simply stupid.

When a window is is in a reduced resized state, the minimize button, will then act to restore it.

In the case of the the main desktop on the operating system, when you minimize a window it minimizes to the taskbar and the taskbar provides a very clear understandable view, of what window is what and you can easily restore them.

Minimizing an MDI window, is just simply makes no sense at all and we are going to remove this concept especially being there are various outstanding implementation issues with it.

Furthermore, the time and sales window which overlaps the main window and also the market depth window, need to be integrated, into chart windows. We will be adding support to integrate a time and sales into a chart. Market depth is already Integrated in various ways.

And we will add support for detachable Chartbooks, but that will take some time.

And we are going to complete the project, to support full trade window capabilities through a Control Bar. This will be a highly efficient, and customizable, trading window interface.

All of the above, will cause incompatibility with ACSIL studies and they will need to be recompiled. This will just be a recompile but inevitably there will be warnings that the compiler will generate. Like for example if you are assigning a value from a Subgraph Data array into a four byte float, then there will be a warning about loss of precision. This can be ignored.

Generated DLLs will probably have this new suffix appended after these changes _64D rather than _64. D means double.

Google firebase integration (a replacement for the ntfy app to receive mobile device notifications for alerts or other chat messages)

Integrated Time and Sales into chart window.