Memory Tags and Custom Session Props

Ignition
1

I haven't made much use of Memory Tags, but I am curious about when they may be better or worse than Custom Session props. I recently have had to use them, or probably didn't have to, but chose to, and it has me wondering about best practices and such.

Is there a gain from performance to using one vs. the other? Other than if the situation can only be accomplished by one verse the other, if they could both be used, what's the deciding factor?

For example, I have a display where data is shown on dynamic tables. I kind of hard set up each table to be visible based on a drop-down selection, then if drop down is X, display Y table. Originally, they were bound directly to named queries, but I don't think 10 tables stacked on top of each other on a singular display running 10 queries seemed smart, especially when only one is being looked at in any given moment. So, I made some scripting to just query the information for the displayed table. The other tables still exist, hidden, on the display. This too doesn't seem ideal.

Now I am thinking, why not go down to a singular table, and add the props that get altered to send to the table just ahead of the query populating the data.

Of course, that means I need to save the table props in question, i.e. the column data and such. Could I make a single object in a memory tag of document style, in which I have nested lists perhaps, each list for a specific table containing the column list and other relevant things like x,y,height,width in a second list.

Is this ALL just bad practice and I am skinning the cat wrong entirely? This specific example I just stated could easily go in Custom Session Props, I am sure. Or is storing it once in a memory tag smarter than 10 instances of the session props having to populate all of that information?

It may be clear from these questions and verbiage I am using, but I have no clue what I am doing.

2

Without getting into the pros and cons or usefulness of Custom Session props, memory tags are of the most use when you have a value which is needed to persist across sessions starts (a.k.a still valid if no session is running). They are also useful when a value is needed in multiple sessiosn.

Definetly non-performant. What is chaning about the namaed queries? Is the named query the same and only parameters change?

I think we need to understand more about what you're doing to really answer that, but I can say having tables (particuarly if they are polling data) on a view which are not visible is a poor practice, and not the way you want to approach displaying data.

3

(post deleted by author)

4

I certainly understand the persistent across sessions and live when no sessions active. That was what prompted my first and only use of Memory Tags so far.

The queries are entirely different, parameters are essentially the same across the board, but not on every single table. Three different parameter sets across 10ish tables. Only one table would ever need viewed at a time. Essentially data relevant to different product runs at different times.

There is also no polling, these tables aren't useful for Realtime monitoring. So, I changed the script to run the named Query and populate the data prop of the specific tables on the action of selecting the drop down, as well as an expression binding for the table to be viewed.

But as that dropdown runs the Query that populates the data prop, right beforehand it could also send the Column props and height/width/positions and such? Then it would be a singular table.

Now, unless storing Column props in a custom session prop is a bad practice, seeing as this would not need to be unique across sessions, it would ideally be going in a custom session prop?

5

I would handle this by making custom props on the view which run the Queries.

Then I would use an expression binding on the data prop of the table to select the data to display.

something like:

case(
    {selectedLineDropDown.props.value},
    1, line1TblData,
    2, line2TblData,
    3, line3TbleDAta,
    null
)

Personally, I avoid session props, unless the data changes infrequently and is truley needed across multiple views.

Some good reading on these here, really the wole post is a good read if you're just staring with Ignition Perspective, this just links to where the conversation turns to custom session props.

6

That does make sense.

So rather than even using session.props, I could bind all the different options right onto the table itself then use the case statement to swap through them.

I will read through that link, thank you very much!