Enhance CONTEXT() to allow access to Dashboard AND View properties at the same time

[WillowMobileSys]

Currently, when a view is placed into a Dashboard, we can no longer access those view specific CONTEXT() details…they are obscured by the Dashboard View. In other words, when accessing CONTEXT(“View”) or CONTEXT(“ViewType”) within any of the “proper” views contained in a dashboard, we will instead be returned the dashboard details. This prevents us from doing things such applying Format Rules to one view and not another when both are against the same dataset.

I would like to propose that the CONTEXT() function segregate access to Dashboard details from all other views. This makes sense because a dashboard is really a container of views rather than a view itself.

I suggest that CONTEXT(“View”) or CONTEXT(“ViewType”) always refer to “proper” views whether they are included in a Dashboard or not. For any expressions operating in the context of the dashboard ONLY, these properties would return blank.

Additionally, introduce a new CONTEXT() property named “Dashboard” used as CONTEXT(“Dashboard”). This property would return blank if no dashboard is present. Otherwise, it returns the name of the Dashboard. This allows a single property to provide inclusion, view is in a dashboard, as well as Dashboard name details.

App Developers can then create context based rules concerning combinations of dashboards and views.

[Marc_Dillon]

On second thought, this request probably will never happen as described, because it is not backwards-compatible. You’re suggesting changing how CONTEXT(“View”) works under dashboard cases. This would break apps that are already using the current way it works. Any new features like this really needs to just be adding completely separate functionality. A “better” request I think would be something like CONTEXT("ProperView"), which would return the actual View instead of the dashboard.

[WillowMobileSys]

Marc_Dillon:

On second thought, this request probably will never happen as described, because it is not backwards-compatible.

Yeah your right. I suppose I shouldn’t be advocating HOW its implemented anyway, just that it’s needed.

[MultiTech]

I think when they release the update for the detail views, the one that will allow us to create dashboard like views within a detail view, that will probably solve this problem.

[sorin_mihai]

Hey, any idea if this has been resolved? Or when that update is coming?
What @WillowMobileSystems is pointing out is so true and frustrating and fixing this would really help out. It feels like a real hit not be able to access a view once it is part of a dashboard. I can agree that the solution may be a new syntax, something smarter than CONTEXT(“ViewAccessDashboardChildViewName”) but something along these lines should include the backwards-compatibilty issue pointed out by @Marc_Dillon (so Context(“View”) would still access the name of the dashboard view and so no old app would be harmed).

For example, I have a dashboard made of a bunch of views that are slices. I make an add button and if I could access the name of the view from where the add button is hit, then I could use that name to prefill a certain row from that form with link to form … but since I can’t access the name of the view from where the button is hit, because it reads the name of the dashboard view … then I have a bunch of add buttons on a bunch of views that all do the same thing. It feels clumsy and cluttered and non customizable.
Either make it so that in dashboard you can only have one overlay button that applies for all referenced view, or allow for accessing each referenced view to control each overlaid button separately.