Just like we have script variables what if we have local window variables. We would be able to do our own highlights on records being selected (especially in different windows). I think this could also open up some other interesting things.
This is a fantastic idea!
I just spent the weekend wrestling with several ways to store and retrieve window state info. Several techniques can currently work, but honestly, they're all somewhat inelagant substitutes for window variables.
There are several cases where could use want window-specific variables. Sometimes we may want the same record open in multiple windows, with each having its own state. Sometimes we need dashboard windows that don't have a concept of current record, but again we want each instance (window) to have its own state.
As we do more things with skinning, working with interactive web viewers, etc., window variables would become more and more valuable.
I realize that you are brainstorming for great new FM feature potential, and that you aren't looking for any workarounds, but just for fun I'd like to mention what I created when I ran into the need for this functionality a couple of years ago.
I wrote a small family of custom functions for manipulating the text that could be set in the window title.
The basic format was something like:
ActualWindowTile & <RETURN> & <SOME_SPECIALLY_STRUCTURED_DATA> & <RETURN> & ActualWindowTitle
Having the actual window title at the top and bottom meant that the title would still show in the title bar, and the title would still show in the Window menu.
The return characters offset the rest of the data so that it wouldn't show up in either the title bar or the Window menu.
The structure of the <SOME_SPECIALLY_STRUCTURED_DATA> included a unique window ID (tracked by a global var in one of the custom functions)
When using the WindowNames function, I would essentially receive a block of data with all of the current Window names, the corresponding unique window ID that had been assigned to that window, and the rest of the payload contained in the structured data. Beyond the window ID, the structured data contained key value data, which allowed me to have my own dictionary of values for each window.
All of the parsing and manipulation of the structured data was handled by one of a few custom functions.
As a result, I had the following functionality at my disposal:
- ability to open, close, hide etc. any window by window ID instead of window title
- ability to store/retrieve variables associated with a specific window
- access to the above regardless of which file the current script/calculation was based in
I'll be the first to say:
- It is a jumbo hack
- It is such a non-standard thing to do that if anybody ever had to work on a file that utilized this technique, my fear is that, even with comments, it wouldn't make sense
As far as actually getting the job done, it worked fine except for the following:
- On OSX the Window title would shift from being centered in the middle of the title bar, and my efforts to add some whitespace padding to restore the alignment were valiant, but not 100% effective
(Note that this was one of the few times I ever found it easier to make something look better in Windows FM rather than OSX)
- In the Window menu, the Window titles showed up with an ellipsis either after or before (I don't remember which) the name of the window title.
We also do something very similar at this time. But it would be great to have something built right in that we would use.
This is good idea.(Although I came here hoping it was about variables like Cursorx and CursorY.)
Retrieving data ...