Digital Workshop

Hi

OpusScript has a DeleteFile action, but it appears to have no way to delete an entire folder.

With a folder containing 100+ .txt files, is there any way, short of scripting a DeleteFile action for each separate file, to delete the entire folder, including all of its component files, in one script action? (I've tried "DeleteFolder," which is not a standard OpusScript function, hoping it would work as part of the JS 1.1/ECMA-262 script family: it won't work.)

Any suggestions would be appreciated.

Kind Regards,
Stephen

Hi Stephen,

A script to delete a directory could be a potentially volatile command for Opus. A variable could be used as the path name and perhaps inadvertently wipe out the wrong directory.

It would be interesting to see what DW think about this -- as I remember the concern with them providing the DeleteFile() script. You would definitely need a confirmation dialog showing the Directory name and path, if it was ever considered I think. IMHO

Couldn't the uninstall of a pub do this job, or are you after something specific? What about launching Explorer from within Opus? You could also call a DOS batch file to do the job.

Hi Steve

Thanks for your reply.

I may have been unclear, as my interest is to delete a folder that the pub creates with many (many) .txt files in it, holding data/info, and not a directory. (Not knowledgeable about names, I don't know if a folder and directory are the same or could be?)

I understand the concern about providing the viewer with the ability to wipe out an entire program. I was only hoping to avoid scripting a DeleteFile for each of a hundred or more pub-created .txt files in a specific pub-created folder (though all of these delete actions would be in one button). It would be less time-consuming to set up a delete for the entire folder, were it possible, with appropriate viewer warnings about permanent loss of that data.

I suspect the DeleteFolder action isn't available.

If anyone has a work-a-round, I would appreciate hearing. Otherwise, I'll copy/duplicate a standard DeleteFile script, changing the file name for each.

Kind Regards,
Stephen

Hi Stephen,

You probably will have to do a series of DeleteFile() actions as you say. If the files were incrementally named like "file1.txt", "file2.txt", "file3.txt", etc, then a script could be written. (but it would not delete the directory name)

In regards to an MS-DOS batch file, (used with extreme caution) you could have:

-----
@echo off
deltree \directory
for %%v in ("prompt $e[m" "echo on" cls) do %%v
-----

The self-closing *.BAT file would be in a different directory than the directory (folder) you wish to delete. I don't have Windows XP, so am not sure if this would work? I would probably be very hesitant to use it myself though. (prefering the manual way via Windows Explorer)

Be interesting to see what DW say when they get back from the weekend.

Directories and folders are the same thing - directory is the older name, folders are what apple and newer versions of Windows refer to them as.

A DeleteFolder() function has so much scope for disaster that we would be reluctant to put something like that in - people would delete their life's work and then blame us (you may laugh but people do sometimes blame their use of the software and us for their own failings)

The DeleteFile action (NOT the script function) does allow you to specify a wildcard so you could have something like:



Again, this has the scope to do damage so please make sure you've got backups before messing with Delete actions!

Hi

Thanks Steve and Duncan for your help.

Given the warnings, I probably will take the "long road" and script 150 lines or so of repeating DeleteFile actions, each specifying a different .txt file in a single folder.

(By the way, I've noticed that with the DeleteFile action, if the data in the files has already been used by the viewer in an open pub, the data will actually not be effectively deleted until the pub is closed and re-opened. Must have something to do with the data being stored in temporary memory, etc. I do wish there were a way, once the DeleteFile action is used to have the data cleared immediately. I've added an "exit" action to the delete button leading to a closing of the pub. Again, too bad there isn't a scriptable "re-start" action, so the viewer doesn't have to then manually re-boot the pub after this delete/exit action. Wish list?)

Again, thanks for your help.

Kind Regards,
Stephen

You need to close the files before you attempt to delete them.

Hi Duncan

Would I be able to then script or use a standard Opus action to CloseFile for each of the files to be deleted, so that the viewer would not need to exit the pub and then re-open it to achieve the full file deletion?

If yes, while I'm scripting the DeleteFile actions, I could also add these CloseFile actions (before the DeleteFile actions, I suspect).

I would like to avoid, if possible, the viewer's needing to exit the pub, if I can absorb this work up front by using the CloseFile action (s).

Thanks for your help.

Kind Regards,
Stephen

At some point in your scripts you must be doing something like:

so when you have done all the writing to the file, just close it.

Thanks

I'll give this a try.

Stephen

Hi

An update: what I've noticed when I preview the pub, save data relative to an object's position/state, close the open .txt data storage file and delete it, is that the next time the object is summoned/reset within the same viewing, a script error message pops up: object not found. Following this event, new attempts within the same viewing, result in failure to save or summon back this object. Only, exiting the pub and re-starting it effectively deletes the file and creates no havoc with the save/reset script.

Since I need to create a viewer option to delete data files yet not cause the script issues above, I wonder if a work-a-round would be a button to delete, launch a (second) executable of the pub, and exit the original pub: all to simulate a restart. Hopefully, the second (re-) launched pub would be free of these issues ("object not found") and also prevent the viewer's need to manually re-start.

Any suggestions would be appreciated.

Kind Regards,
Stephen

Hi Stephen,

Can you give a sample of your IMP file or your script? (You should not need any workaround.)

BTW: Is there any specific reason of why you are deleting all these files?

Thanks for your reply.

The "save" action script:


save = ref + ",";

for (loop=0;loop<ref;loop++)
{
var pos = myClone[loop].GetPosition();

var objdata = pos.x + "," + pos.y;

var child = myClone[loop].GetFirstChild();
while (child)
{
objdata += "," + child.m_state;

child = myClone[loop].GetNextChild(child);
}

save += objdata;

if (loop < (ref - 1))
{
save += ",";
}

plus a write to disk (.txt) file action for the variable <save>.

The "reset" script:

textobj = OpenFile(SYSTEM_DOCUMENTS_DIR + "\\efolderaaa\\pos.txt");

ref = textobj.ReadField(false);
Debug.trace("ref = "+ref+"\n")

for (loop = 0; loop < ref; loop++)
{
x = textobj.ReadField(false);
y = textobj.ReadField(false);
Debug.trace("x = "+x+"\n")
Debug.trace("y = "+y+"\n")

myClone[loop] = frame.CloneObject(x,y,true);

var child = myClone[loop].GetFirstChild();
while (child)
{
var state = textobj.ReadField(false);
child.m_state = String.integer(state);

if (child.m_state == 0)
child.SetTransparency(100);
else
child.SetTransparency(0);

child = myClone[loop].GetNextChild(child);
}
}

When the viewer saves the data, it is written to a number of .txt files in a single SYSTEM_PUBLICATIONS_DIR folder. In order to delete all of this data and "clear" it, so far I've set up a DeleteFile action for each file in the folder. This requires exiting and re-starting the pub to truly clear the data and prevent the script from creating errors (like ref= ) and failing.

Any help would be appreciated.

Kind Regards,
Stephen
Let me know if you need any additional info.

Hi Steve

While I've placed the script in the last reply above, I forget to respond to your other question: why the need to delete the data. These .txt files hold a variety of information, including the positions and transparency state of dragged and dropped objects, names and health conditions, all for a family tree. If the viewer wishes to start over or create a new family tree for a different family, they would need to delete previously saved data pertaining to the other family tree.

I hope this explains the need to delete the .txt files written to a folder in SYSTEM_DOCUMENTS_DIR (not SYSTEM_PUBLICATION_DIR as noted above).

I also just tried a textobj.Close() script at the end of the reset script above (which had opened a .txt file), with no success. I had hoped that if I closed an open file and then deleted it, it would clear up the issue of error messages re: ref= (blank) and subsequent script failure. (I wonder if adding a script something like if ref="" then reset var ref=0 would solve the problem).

Thanks again for any help.

Kind Regards,
Stephen

Hi Stephen,

Hey I not an experienced script user...I was hoping to see something easy to solve!

Is there any reason why you are deleting the actual files? Can they just have their contents emptied or overwritten. If in your Family Tree pub the ".txt" files are pertaining to a username, (which determines the actual filename), then I see no reason to delete them.

I know you've probably just pasted some script in your message, but just to make sure, the curly brackets are missing in this if/else part, and should be like this....

//--------

if (child.m_state == 0)
{
child.SetTransparency(100);
}
else
{
child.SetTransparency(0);
child = myClone[loop].GetNextChild(child);
}

//--------

The default 'encrypt' value of the ReadField() is false, so ReadField(false) is not really needed. There was also a problem in 04.5 with ReadField() reading empty fields. i.e. it would throw the sequence out with the wrong field being read into the wrong variable. (This may be fixed in 05.14, but I'm not sure if this applies to your set-up)

As far as your problems with the closing of files and deleting them, you may need DW to look at your pub, or someone much more experienced at scripting to help.