Show live Data

[Daniel_Basham]

I'm trying to create an app that requires and input and displays that input on another screen

however I want to use another instance of the app on the secondary screen.

Is this possible?

Basically I want to input 2402123 and on a monitor in another building i want them to see that number without having to do a thing.

Is this possible? can an instance of the app be updated from another instance?

[RandyHayes]

@Pstork1 

Sort of!  But this is much different.  The timer actually only has one purpose - to cause the Lookup to lookup a different record, then lookup the normal one.

To be clear though - there is NO refresh needed.

Your point about the app to app communication is valid.  There is no push to the app.  But the method laid out here is more about utilizing the session table feature (that is not published and little known) whereby it will get the most recent record if the record is no longer referenced in the app.

Meaning - if you have nothing in your app that is bound to record x, then when you do reference it, it will be the current datasource value.  If you lose that reference and then reference it again, it will be the most current value.  So, if updated by another means (another app, flow/PowerAutomate, direct change, etc.) it will reflect that changed value and no refresh was issued to get it.

For so long the rule has always been - if something changes the datasource record, then you HAVE to refresh the datasource in the app to get the new value, but that is not a true statement any longer.

So, again, yes, it is not a push to an app, but it is a simulated way to do that and it carries NO overhead like a refresh would.  The update of the data (what is seen in the app) is all done at the session table level and not the app level.  So, the performance does not suffer like a refresh causes.

[Pstork1]

@RandyHayes  I get that you aren't doing a refresh() on the data source or a Reset() on a specific control.  And I understand that its probably the least invasive way to do this.  But having the label automatically refresh because the context variable changed is still doing a pull of a record from the data source based on a timer firing. So yes its more elegant, but its still essentially the same process I described. 

[RandyHayes]

@Pstork1 

Sort of! 😉  

Yes, you are always pulling. That is not something that changes, but you had mentioned that the timer would refresh the app and that doing so would impact performance and should only be done 3-5 minutes.

What I am mentioning does not impact performance and can be done every second.  All of the update/refresh happens at the session table level.  A refresh in the app would cause the session table to clear and stub itself.  Then the process of filling would start all over - yes, I would not want to have an app do that except as needed!

But without the refresh, it's something that will refresh automatically with the method I described.

Note: the method I have described is relatively new in the session table.  It did NOT do this type of change on its own many months ago...now it does.

[Pstork1]

@RandyHayes I understand that its a lot less of a performance drain than doing a full refresh of the data source.  I'm still not a big fan of setting a timer to do something in an app once a second, no matter how light weight it is. It should work as described, and then the scope creep will kick in and the timer will get used for some other housekeeping feature which will drain performance.  I just don't think its a good design to perpetuate.

[RandyHayes]

@Pstork1 

Agreed 100%!  I am not a fan of a timer for anything other than keeping real time!  

But, the primary purpose of the timer in this case is to simulate selecting something else.

For example, If I had a dropdown with a 0 and a 1 in it.  Then I had a label with a LookUp(source, ID=dropdown.Selected.Value, somecolumn).  If I choose 0, the label is empty.  If I then choose 1, the label has the value of the column in record 1.  If I then change the record in 1 and then select 0 again and then 1 again in the dropdown, then the label will have the new value in it.

So, the timer just serves to essentially "change the dropdown" automatically for me.

Of course, I am just using a dropdown as an example, but the concept is the same.

So, if you want something to happen automatically - in this case changing the record number, then it has to live in a timer.