If I’m understanding you correctly, this has been doable since the early days of the Scripting app/block:

const currentView = base.getTable(cursor.activeTableId).getView(cursor.activeViewId);

console.log(currentView);

It’s possible to get all the view ID’s, the current table’s active view ID, as well as view ID’s already known by name - but those don’t help because of the italicized words.

I’m not sure what formatting has to do with anything? You can easily pull cursor data, and the same goes for manipulating most base metadata, view configurations very much included:

output.markdown(`# Your current active view is **${base.getTable(cursor.activeTableId).getView(cursor.activeViewId).name}**`);



base.tables.map(t=>t={table:t.name,views:t.views.map(v=>v.name)})

    .map(obj => {

    output.markdown(`#### All views in table ${obj.table}`);

    obj.views.map(v=>output.markdown(`- ${v}`))

    });

const currentView = base.getTable(cursor.activeTableId).getView(cursor.activeViewId);

console.log(currentView);

output.markdown(`# Your current active view is **${base.getTable(cursor.activeTableId).getView(cursor.activeViewId).name}**`);



base.tables.map(t=>t={table:t.name,views:t.views.map(v=>v.name)})

    .map(obj => {

    output.markdown(`#### All views in table ${obj.table}`);

    obj.views.map(v=>output.markdown(`- ${v}`))

    });

Thanks for taking a look @Dominik_Bosnjak, these are some of the insufficient solutions I was referencing. The goal is to get active views from multiple tables.

The first solution (const currentView) is insufficient because it only pulls the active view from the current table - where as I need them from multiple tables.

The second solution satisfies the opposite. It pulls all of the tables’ views, but includes inactive views as well - whereas I only want the active ones.

The API seems to think of ‘active’ through the lens of a ‘cursor.’ But I would argue, whichever view is set in a table (even if not on-screen) should be considered active if thought of through the lens of a ‘session.’

Hmm, okie, could you define what constitutes an “active” view? Because there’s only ever one of those, and unfortunately, I don’t think it’s possible to send delayed cursor queries. That is to say, you can definitely timeout your requests but the Scripting block caches this information if memory serves correctly, so asking for repeated input from the user is the only way to go if you aren’t willing to build a custom app.

With all of that said, this would be the time to rethink your overall plan. Whatever it is you’re trying to do, I guarantee there’s a better way, likely even within the confines of the Scripting app.

Views are just fitered record arrays (or queryRecordResult instances, if you will). Whatever data they might hold that you’re after is bound to be more acceessible from another angle.

By active, I mean the “views that are currently set.” I agree ‘API.cursor’ is not the correct way (cursor only refers to what’s on-screen).

I also want to emphasize, I’m well aware this isn’t possible as I’d like, which is why this is tagged as a product suggestion.

This is just a simple scripting block. Again, I already have a working solution - prompting users for views. But since users are already familiar with views, they use them frequently, maybe we should be able to use them for queries regardless of cursor context.

I’m not quite getting this. Either a view is active by the current user or its not. Are you asking for an array of all views the current user has opened since the start of this session (base first loads)?

The idea is if you open any of your given bases, which views are currently set in each table? So maybe Session isn’t a good word either, since it would extend beyond a given session.

In any case, here’s an example,

Table Name:            Table1  Table2  Table3

User's Current View:   View21  View24  View74

I’d like to be able to query

base.getTable("Table2").getCurrentView()

=> View24

regardless of user context (which table the user is looking at)

I think what he’s saying is that given a collection of tables in a base, the user is able to select views for each table that are “selected”; ergo - active on that table. Ergo, there is the potential for as many “active” views as there are tables in a base. In fact, there are always at least one view used by every table all the time, right?