Is there any way to detect whether there are any unsaved changes in my designer? Is that stored anywhere in the gateway or designer files?
From what context do you want to know/why do you want to know?
I want to know so I can determine whether I need to save the designer before closing it or if It’s safe to exit without closing
There seems to be some sort of cache at C:\Users\{USER_NAME}\.ignitionbut I am unsure when the various files change and how they correlate to changes in the actual state of the project in the designer. Any advice?
The cache files are irrelevant.
In theory, you could run a script in the script console that went to the designer's in-memory model of the project, walked through it, and returned whether there were any "dirty" resource nodes - indicating a pending unsaved change.
But...why?
What's the downside of the existing prompt you get when you try to close the designer?
If you haven't changed anything, then an "extra" save will not have any negative consequences. Just hit save and exit each time, if you're concerned?
What would such a script look like? What are the relevant functions to read designer memory?
I'm not going to write the script for you, because I think this is a pointless endeavor.
From an instance of DesignerContext[1], you can ask for the project, which will be an instance of DesignerProjectTreeImpl.
That's the designer's in memory representation of the project state. After that you're on your own.
search the forum for
IgnitionDesigner↩︎
Typically, the pages or views that are different than the existing Gateway saved version will be italicized in the project browser. If you want to revert one page, and not another, right click on the italicized view you want to revert and select ‘revert changes’. That page will be reset to the last saved version, and un-italicized. The other pages / views will not be affected or pushed to the Gateway until you save.
I presume that the term “dirty” is only loosely related here to whether there are actual changes to the project resources waiting to be saved? Mainly because just opening a resource and not making any changes to it flags it as needing to be saved. This is a small gripe I have, since these will all be recorded as changes in the audit log and in the resource json, when they were just simply opened and not modified
Whether something gets marked as having changes is ultimately up to the individual 'workspace' - e.g. Vision vs Perspective vs scripting vs named queries. They're all in charge of doing change detection between the last serialized/saved state and whatever is currently in memory, and Vision/Perspective in particular are pretty bad at it. We have some open tickets to improve that.
The downside of the existing prompt (whether or not any changes have actually been made) is the risk of discarding real changes made, versus accepting spurious changes that may have been inadvertently made.
In an ideal world, we would work on one thing at a time, without interruptions, and be able to follow a train of thought through to completion.
In (some) environments the reality is significantly different. When I have 3 designers and 5 PLC projects open, simultaneously commissioning 2 new systems, with 3 people lined up at my door waiting to ask questions, carrying on 4 simultaneous conversations (one on radio, one on my desk phone, one on my cellphone, and somebody in my office), chaos rules. It’s not hard to inadvertently make a change when I didn’t intend to.
I have in fact at least once discarded intended changes, and at least once accepted inadvertent changes. I understand this is my responsibility, but this prompt doesn’t help. When I test PLC program changes (Rockwell), it tells me which routines have changes, I can think through what I have done to confirm that is what I intended. That helps.
Train yourself to use the modified save changes button?
That said, this is an item we've had some previous discussion on:
The problem is whatever we decide, someone is going to complain, and it's generally safer to default to saving everything.
If it becomes a problem, you might want to make your project inheritable (as long as it's not Edge) and work on the inherited version and do any testing there before exporting/sending the changes to the parent project. This would protect your production project from accidental changes and make everything more deliberate.
This bugs me too about the designer.
The way I found to solve this, is to use git.
In the dev environment just save every time when you exit. Go to git, discard everything you don’t want. Then go to the gateway and reload the project to make ignition load the changes.
If you have the designer opened while doing changes with git you have to ask it to merge changes after reloading in the gateway.
To transfer to prd environment just commit and push in dev and pull in prd. Then ask the prd gateway to reload the projects.
There are great tutorials to work with git in ignition 8.3
Disclaimer:
– Vision changes are almost imposible to review in git.
– If more than one person is working on the same gateway it can easily become a mess
– Ignition does its own internal changes for everything you change, some of those can be discarded, others cannot. I made errors until I learned
– Files can be changed with the designer opened, but it’s easy to generate conflicts. Close the designer beforehand unless you know what you are doing
Ah, I was not aware of this Save…. functionality, that helps a lot.
Thanks!


