Where do you store operating variables for multiple Python scripts to access?

i have two input fields (in1, in2) and a button (btn1). as i lose focus on in1, i have it run a script that stores a slice() of the inputted information and store it in a variable...? and this is where i blank because:

  • where is that var supposed to be declared for other scripts to access it (eg. in2 scripts)
  • how do i then access said variable from in2 and/or btn1?

the normal course of action would just be to make sure the declaration was done outside local scope and usually a master variable doc... but that's not how this all works, right? so i am blanking because variable location management is not something i had to concern myself with previously.

and for the 'RTFM' floggers out there, where the heck would i look this kind of thing up?? scope is convered, but not in this broader sense that i've found so far. so i am looking.

If this is in Vision, you should make use of client tags. You can bind the values of in1 and in2 to two different client tags, and when you run the script on focus loss of in1 you can write the resulting slice to a third client tag.

For reading the tag values you make a call to system.tag.readBlocking()

If this is Perspective, then you can use session custom properties to do the same thing as client tags (session properties are to Perspective what client tags are to Vision)

2 Likes

Depends on the use case.

Things that are session scoped go in client tags or session props.
Things that are more global can go in gateway tags or in top level scripts.

1 Like

sorry, i forgot: Perspective only in this shop.

session props sounds like what i'm looking for. which, if i understand correctly, means i am doing this all wrong. if i want a var to transcend it's current script/scope, i have to make it a prop and THEN use THAT instead of a simple tempvar = thingy statement?? do i have that right?

Yes.
Also, keep in mind that A LOT of things in ignition don't require scripting. The custom properties you'll create can be used in a whole lot of different ways, and scripts should be the last resort.

It's a shift from usual programming, but bindings allow you to 'pull' values to your property, instead of 'pushing' them.
example: You need to get data from a database, to display in a perspective table.
You COULD run a script that queries the db and assign the results to the perspective table.
But the proper way is to bind the perspective table to a query. If the query is not enough and the data needs to be processed further, you can add transforms to the binding to put some more logic there.

yeah. i am starting to get my head around that. coming from a pure-code-everything background, this is a bit of a weird concept. i am having to decouple a LOT of old habits. and i am trying to get up to speed as fast as possible, which means i make mistakes. which i generally don't mind, you learn a lot from those, but some of them are stupid ones: like i mixed up JS and Python today for about a full hour. i think it is a result of the massive rewiring going on in my head.

i appreciate your kind advice and help. it is very much appreciated. especially since, no matter how long i have been engineering bespoke software, when i come to something new and ask a basic question, most people treat me like i'm braindead. so thank you. :slight_smile:

and double thanks because i was literally about to start probing my db exactly as you described. so now i'm doing it the way you suggested to further help me switch over. :+1:

I was coding mostly in C up until about a week before I started using ignition. Had no idea how python worked either. So I know !

my problem is i KNOW how Python works... but this is some mutant hybrid of Python and Java. i know virtually nothing about Java. but, yeah. you know the pain. :smiley: like right now all i want to do is concatenate two values... and i'm trying to wrap my head around this 'binding' concept. weird...

You should invest some time in the Inductive University if you haven't.
Maybe not watch everything, but some basics abouts how things are handled in ignition and especially perspective. It takes a while, but it's a good investment, it'll make things faster in the long run.

i mowed through a good chunk of it last week, but i am now going back because a lot of what i'd learned didn't have any contextual meaning. the IU teaches you a bunch of pieces, but not how they hang together nor how they interact in any meaningful context. for example, right now i just want to assemble a username from a first initial derived from the first name and concatenated lastname then dump the result to a session variable with some checks to make sure i'm not overwriting what might be already be there. i know about bi-directional binding, for example, but it doesn't help when i need to manipulate the text BEFORE i send it off. and that's a spec requirement for this project. so right out of the gate, at the simplest part of the project, i am dead in the friggin' water. the examples they give are too short to be meaningful in any production context and assume a knowledge of how other parts should be working. and there's not much by way of fast, low-level feedback or tracing, which i am used to using for following the data as it flows through the system; at least as far as i can find at this point. i literally have no idea how the data types work, if i am accessing a string, integer, or a piece the omni-present 'dataset' whose addressing/methods still makes me blink. and i'm a smart guy! this makes me feel like an idiot. i am hoping, now that i've been thrashing in the kiddie pool for a few days, that my return to IU will be a little more useful.

Can you tell me more about that username thing you're trying to do ?
Where are the different parts coming from ? Why does it need to be bidirectional ? What constraints does it need to satisfy ?

You seem disconcerted about your abilities as a novice in this software. You need not be! You are welcome and encouraged to ask for help or reassurance here. It's a very helpful community that props up it's members. It can be tough to tough to see yourself less productive than normal as you learn new things, but that is normal.

As long as you appear to be trying things and using the documentation, people will usually be helpful when you ask questions. General tip: mix in asking how to achieve the outcome you need rather than focusing on the technique you have in mind. This is a great way to uncover clever/efficient solutions.

Your first projects probably won't be home runs, but take note in each what you think can improve and you'll do better each time.

@humphrey.daniel thank you. yeah. anxiety pretty high here. i appreciate it. and good advice here. it is a very different beast to what i am used to. code languages are flavours of the same thing. this... not so much. so i will definitely ask more for approaches to a problem than resolving techniques. i just keep seeing a very elaborate frontend for basically web app development and i need to see it differently.

@pascal.fragnoud following the advice given, here's what i need: an auto-generated username with the following contraints:

  • consists of first initial and last name (eg. pfragnoud)
  • user input fields should not overwrite eachother. users usually enter first name then last name, but there's always that one dude who has to be different. so checking that we aren't making something like fragnoudp is necessary and requires modifying onBlur behaviour... if that's how you recommend i build the scripts
  • username total length cannot exceed 12 characters. have no idea, it's just part of the client spec.
  • the generated username has to be accessible from other views and pages for their functionality, so it will need to be stored in the session props (or gateway?)

now the reason for doing this is two-fold: one) it should be simple and is a quick way to get head around how a language/process works. should... and, two) it is literally something i need to do for this project. so. instead of asking for scripting, what is the best Ignition way to approach this? as a long-time webdev, this is a no-brainer, but we've seen that that talent tree doesn't translate well here.

So you have something like a landing page with 2 text input fields, one for first name, one for last name, and users need to fill both before proceeding ?
I'm not sure what you mean by "fields overwriting each other".
While I can't see how to make sure people are putting their first name in the proper field, does it really matter ? I mean, my auto generated username could be pfragnoud or fpascal, who cares ?

In this particular case (If I got it right), I'd actually use a script, an onActionPerformed event on a button, that would write to a session custom property, assuming the username is only valid for this session.

Otherwise, why not use the built-in authentication system ?

What's the actual purpose of the username? Are users being authenticated by it? Or they literally just punch in their name and the username is used for the session and that's it?

Forgetting the why, as for the how at face value what you're asking:

I would create 3 custom session props. security.firstName, security.lastName, and security.userName. Bind the userName to an expression:

lower(left(left({session.custom.security.firstName}, 1) + {session.custom.security.lastName}, 12))

(you can use the property selector in the binding editor to select the session props.)
You can also put other checks around this as well if you want to blank it if the len() of first/last are 0 etc

To the View (preferably a flex View), add two text input components for first and last. You might want to add each into their own flex containers and add a label to each as well. Create a property binding on the two input components' props.text properties and bind them to the two session props firstName and lastName. These can either be bi-directional if you want them to be set immediately, or non-bi-directionally so you can vet the values first, before writing to them with a "submit" button or similar, via a script on the button to set the session props to the values of the input fields.

Again, I don't know if that's actually what you should do, since it does sound more like you'll be using it for user authentication, in which case you should be using an identity provider instead. You can script the creation of users if you need, and use something similar to above to generate the username for the script, but you wouldn't need to use session props in that case.

We really need more info on the intentions of this username

  1. never thought of using an Expression. very cool.
  2. valid point. given what you've just illustrated, i guess i DO need more information on username. i will go get it and report back
  3. thank you very much for such a useful response. glad i took a peek before i left today. :smiley: