Save dialog entered data

paulemasters · Post by **paulemasters** » Tue May 17, 2011 3:19 pm

Hello:

Is there a way to save the data entered in a dialog so it can be redisplayed the next time the dialog is run? This doesn't have to be saved across executions of PhotoShop.

What happens is that I check for some requirements after OK is clicked on the entry dialog. If there is an error, an alert or another dialog is displayed indicating what the problem is. However, when the user reruns the script, all the fields have their initial value.

I think I can do this for some problems by 'looping' in the entry script (haven't tried it yet). But, in one case the user has to do something in PhotoShop and I know that that can't be done while the script is running.

Thanks for any ideas.

Paul Masters

pfaffenbichler · Post by **pfaffenbichler** » Fri May 20, 2011 8:15 am

What happens is that I check for some requirements after OK is clicked on the entry dialog.

Maybe the Script should do that prior to displaying the dialog.

Anyway it is at the very least possible to have the Script check for a txt-file in a pre-defined position and have it overwrite that file after the dialog entries have been OK’d. (And just to make sure provide default values for use in the absence of said file.)
There may be better options, though.

xbytor · Post by **xbytor** » Fri May 20, 2011 9:46 am

app.getCustomOptions and app.putCustomOptions may do what you need. I tend to use text files.
I'm currently migrating from using .ini preference files to .xml files.

paulemasters · Post by **paulemasters** » Fri May 20, 2011 3:48 pm

Thanks for the replays.

pfaffenbichler:
The data that is checked is entered in the dialog so it can't be checked before the window is shown and the data is entered.

pfaffenbichler and xbytor:
Do you have a brief example of using a text file?
I have discovered a way to get the location of the script and use that to display a help window. Perhaps you are referring to something like that. How would I write he file?

xbytor:
The custom options sounds interesting. Can you put in your own or are the values 'set'?

Thanks to all for any help.

Paul Masters

larsen67 · Post by **larsen67** » Fri May 20, 2011 5:41 pm

Paul, what I think Pfaffenbichler means is that your dialog could test for the existence of a saved text file… If it exists its your preference so read it and use it. If not the script has not been run before and use a set of default options… Include in a call back function a new write to file replacing the existing contents. The simplest way to do this is to store your data in an object and write it toString() that way you can just eval() it back…

X's suggestion of using XML sounds interesting all mac preference .plist files are XML… But that would add extra work (Plus in my case I would need to go learn XML)… I don't know if this is also the case for PC prefs?

xbytor · Post by **xbytor** » Fri May 20, 2011 8:52 pm

larsen67 wrote:Paul, what I think Pfaffenbichler means is that your dialog could test for the existence of a saved text file… If it exists its your preference so read it and use it. If not the script has not been run before and use a set of default options… Include in a call back function a new write to file replacing the existing contents. The simplest way to do this is to store your data in an object and write it toString() that way you can just eval() it back…

Actually, you would want to use toSource() to serialize the object before storing it to a text file.

X's suggestion of using XML sounds interesting all mac preference .plist files are XML… But that would add extra work (Plus in my case I would need to go learn XML)… I don't know if this is also the case for PC prefs?

The Mac .plist format is a horrible example of how an XML file should be formatted. Please don't use that as a reference. There are all kinds of tutorials on the web. Besides, most of your interaction with XML is going to be in JS. There's a little more syntax to learn, but it's worth the effort in the long run.

The reason I suggest using .ini files (Windows legacy) or XML is that they are easy for an end user to read and edit if necessary. toSource() output is quite a bit more complex.

xbytor · Post by **xbytor** » Fri May 20, 2011 8:56 pm

paulemasters wrote:Do you have a brief example of using a text file?

My xtools library has a bunch of code for reading and writing ini files.

[qoute]
The custom options sounds interesting. Can you put in your own or are the values 'set'?
[/quote]

Yep. You populate an ActionDescriptor object with whatever your options are and get/put it as needed.

larsen67 · Post by **larsen67** » Sat May 21, 2011 11:22 am

Actually, you would want to use toSource() to serialize the object before storing it to a text file.

Opps… Actually so do I… Sorry my mistake when typing the reply… XML is on the 'to do' list with all the rest…