New Window [ Style: Virtual ]

Idea created by Chris Irvine on Nov 2, 2015
    Active
    Score89

    This new style of window is for scripting with one or more independent contexts. Context is such a critical concept for developers, that we jump through all kinds of bizarre operations such as positioning windows off screen, or utilizing additional solution files as a Wingman or Helper context.

     

    Virtual window behavior:

    • It is invisible to the end user, forever.
    • It behaves programmatically like any normal window, or virtual server window, allowing the manipulation of an independent context.
    • A new virtual window can be opened or selected, at least for purpose of a script context, even if a Modal Dialog Window is already opened. (This wouldn't make sense for UX, but it does for functional and transaction scripting. Currently, attempts to open a document window while a modal is open returns error 3.)
    • Switching between non-empty layouts in a virtual window should perform at least as well as switching between empty layouts in any of the current window styles.

     

    Virtual window benefits:

    • Because it will never be displayed, performance impacts can be mitigated. For example, reduced OS overhead related to display rendering, avoids triggering evaluation of unused calculations or summaries, etc.
    • It furthers support for existing best practices for modularity and transactions.
    • It removes coding ambiguity that is currently prevalent in many solutions. (negative window coordinates, etc.)
    • It removes cruft as many of us maintain a large list of empty scripting layouts.

     

    Concessions:

    • If preview/printing/PDF support would add to the memory footprint and cost of a virtual window, then it would be acceptable to for these steps to be unsupported. We could work with the existing document window style for print rendering, server PDF requests aside.

     

    For those of you academics, this virtual window technique strives to step towards objects or a cursor concept, moving farther away from UI automation. Does anyone want to write up a request for clarification or formal "window context variables" that could be used to keep persistent data in a window's context? It would work nicely with virtual windows.