Question: controlling Subdirectory paths in ZScript

[Svengali]

OK. Here's something I have been trying to figure out, but am about ready to give up on.

The FileNameAsk command permits the script to ask the user for a filename, either something to be saved or loaded, and it does it in the typical dialog window which shows the files that already exist. You either select one of the existing files or enter a new filename.

Swell, very useful. It works great...

Problem is, I can't see anyway the FileNameAsk command can be pointed along a specific subdirectory path. Depending on the context, it selects the subdirectory that the ZScript is in, or the ZScript2 directory.

I would really like to create an exclusive subdirectory where the script will save and load data... and point FileNameAsk command to it.

Has anybody uncovered the technique to be used here?

Sven

[marcus_civis]

Hi Sven,

I think if you insert the line:
[IUnPress,Preferences:Misc:Use ZFolders]
before your FileNameAsk command then the Save As and Open file dialogues will open in the same directory as your ZScript resides, wherever that happens to be...

HTH

Mark

[TVeyes]

Heya Sven,

As with most things it is pretty easy once you know it.

The commands you need are FileNameAsk, FileNameResolvePath , FileNameExtract and StrMerge.

FileNameAsk is of course used to open the Dialog.

FileNameResolvePath is used to calculate the pathname of the executing zscript.

FileNameExtract is used to remove the filename from the FileNameResolvePath supplied pathname

StrMerge is used to add or subtract subdirectories.

So your code could look like the following:


[FileNameAsk, .psd, // set .psd as the default filename extension for the open/save dialog
[StrMerge
,[FileNameExtract, [FileNameResolvePath, ] , 1 ] // Extract the path only from the executing zscripts pathname
, "..\" // Go back to the parent directory
] //End of StrMerge, returned string is used as save dialog starting directory.
, "Save .PSD" ] // FileNameAsk dialog title, could be anything. End of FileNameAsk command.
The above code would open the Dialog window in the executing zscripts parent directory. StrMerge'ing "..\..\" would start two directories up from the executing zscript. "Svengali\" would open in the ..... Svengali directory;) . As you can see the important thing to remember is to add a final \ to the pathname, if you do not the last part is treated as a filename.

Assuming your script is placed in the Zplugs folder you would merge "..\..\Ztools\" to start in the Ztools directory.

A final note, [FileNameResolvePath, local filename] without any parameters returns the executing zscripts pathname and filename, [FileNameExtract, full path of filename, returned component] seperates them according to the supplied parameter.

Hope that does it for you.

[marcus_civis]

Hello TVeyes,

That's interesting and useful but won't it only work for 'Save As' though? - that bit of the code needs to be blank for the 'Open' dialogue.

Mark

[TVeyes]

No it also works for FileNameAsk. If the filename passed to FileNameAsk only consists of the pathname (ends with a \ ) it will leave the Dialog filename field blank but locate the pathname directory.

[marcus_civis]

Yes, certainly the field is blank and the directory is located but the dialog is a SaveDialog not an OpenDialog. Using your code I can't get an OpenDialog. The only way I can get an OpenDialog is to have nothing between those two commas. As it says in the Commands List 'Name should be omitted for OpenDialog' and this appears to apply to paths too - or am I missing something?

[TVeyes]

Sorry, I misunderstood you.
You are correct, it shows up as a save dialog. I had not thought about it since I only wanted to save when using FileNameAsk. Not sure how to get around it. Did some quick tests and I cannot make it a Open Dialog.

Maybe time to use the FileExecute command to run GetOpenFileNameA from the Windows Common Dialogs DLL (comdlg32.dll) ?

[Svengali]

Hi Marks,

Mark1: A few things about your recommendation to have my script turn off Use Zfolders.

1. I had already turned that off some time ago and forgot about it and assumed that the Zscript folder was always the default folder... so, I guess I need to remember to explicitly turn Use Zfolders off in any ZScript where I want define alternate file paths. (it also makes me leary about what other changes I've made-and-forgot-about in my Zbrush configuration that could turn up as mysterious problems when my scripts are run under other configurations... :o )

2. It turns out that if I DO turn off Use Zfolders the default path points to the folder containing the ZScript... UNLESS I try to run the FileNameAsk command from inside a Note window! Then it seems to default to the Zbrush2 folder *cough*.


Mark2:
Hi TV. I appreciate your explicit answer on this and I still have to compare it to the code I already have. After two days of coding on this one problem, I have lots of versions that look like similar to what you have explained. (a veritable "salad" of Filename commands, tossed and retossed...)

But the other Mark has put his finger on the problem (one of the problems) when he points to the OpenDialog problem - the fact that it has to be blank?!? leaves me no way to indicate a path to the subdirectory I want to load something from...

I also ran into a problem with how ZScript parses the path (or should I say how it doesn't parse the path?) Especially since the back slash inside a ZScript string is used as a special switch. When I would StrMerge a path, filename and extension together where the path led to a file in a subdirectory the absence of parsing led ZScript to conclude the subdirectory was part of the filename. *sigh*. So, I'm going to try the backslash again in concatenation and see if I can get it to work.

Anyway, since I started writing this I see that you (TV) have a new idea about using FileExicute with GetOpenFileNameA as a way to manage the OpenDialog problem. Will that work???

Sven

[marcus_civis]

Ahh, This is really all out of my league - I just like trying to solve problems - but I think I'll leave the Windows dlls to you guys :confused:.

I wondered whether you could use the FileNameSetNext command to give the path but it seems that has to have a file name...:(

Good luck Sven!

[TVeyes]

Sven:

In theory calling functions from Comdlg32.dll should work fine. But I am not 100% it will work. It will also take a fair amount of extra work as you will need to define a zscript memory block that can be passed to GetOpenFileNameA.

The memory block should be large enough to accommodate the data structure GetOpenFileNameA expects: http://www.mangovision.com/vbapi/ref/o/openfilename.html

The actual length of the memory block will vary according to the data structures various string definitions. So a check to see if the memory block exists will be needed. If it exists, MemDelete it and MemCreate a new one each time you FileExecute GetOpenFileNameA. Or you could create the memory block with room to spare.

It could be interesting to see if it works (nudge, nudge). But I think I will wait a day or two before trying, there might be a super simple solution to the aforementioned problem. But please, be my guest and give it a shot :D.

Edit: Remember to match the Case of the .DLL function you wish to execute. It will not work otherwise.

Marcus:

I have very little knowledge of windows programming. I only started reading more about it after the Zbrush<>.DLL connectivity was announced. If I can get a rough handle on things I am sure you can too. So don't hang up the phone just yet, join or follow the threads in this forum, we need a little more activity around here.

Cheers

Mark

[Svengali]

Hi Marcus,

Yes, I know where you are coming from since I love solving problems too :D . In this case, I am probably a little out of my league, as well.

I'm just trying to write a utility in ZScript that might ultimately be very useful to everyone and I became frustrated and sidelined by the odd (and I feel incomplete) implimentation of ZScript tools for managing datafiles.

I'm still trying to learn ZScripting and often run into difficulty because I just don't understand the command options or their particular syntaxes. That's when I post a call for help - Almost always I get a quick and useful response from TVEyes, Digits, Cameyo, EZ, GM or some of the other ZScript wisemen.

But I feel like we all are handicapped by the lack of in-depth information on the ZScripting language. Right now all we have is the command glossary, the internal command listing which supplies a little more detail on usage for some of the commands, and the autoscripting, which can be examined after the fact to see how a Zbrush process is broken down into individual commands. Add to that, old ZScript source .TXT files, a lot of TRIAL and ERROR, and the generous help from other ZScriptors and that's about it.

We (mostly the ZScriptors with no real background in programming) need documentation that is more comprehensive - with plenty of code examples.

Anyway, this was one of those cases and I really appreciate the input from you and TVEyes. Thank you both.

Sven

[marcus_civis]

Thanks Sven & Mark, with your encouragement and generosity I shall hang on in here and watch when I can't contribute. I've never been much interested in programming before but ZB2, ZScripts and the great community here has sparked an interest. I'd certainly like to create something useful for everybody like you guys. I've a lot to learn... meanwhile, if I discover anything on this I'll let you know.

Cheers,
Marcus

[Svengali]

Hi TV,

wow. do I really want to bite this off now? Depends on how desperate I get :o :) . Maybe there are some Windoz/Zscript programmers who might throw in a suggestion or two (he said, hopefully.)

I promise that if I try it and get it working I'll post whatever I discover. Or, maybe Pix or Matt will come to the rescue with some special insight on the problem (after they get back from Siggraph and detox, that is :lol: ).

I need to send you an email on some other subject, so keep an eye out.

Sven

[davey]

This might be a bit helpful ...

To specify an alternate path, I've often used the method posted by TVEyes, which involves the [FileNameResolvePath... command.

Here's another tip: you can specify any path starting at the 'top' of the ZBrush folder tree: i.e. 'ZBRUSH_ZData\ZPlugs\WebZPlug.dll' specifies the ZData\ZPlugs\WebZPlug.dll path within the ZBrush folder.

dave

[TVeyes]

Thanks for that pointer Davey, very useful. I guess there is no workaround for redirecting the [FileNameAsk,....] open dialog?

[CHRIS REID]

I am quite familiar with windows and zscripting . Much more with windows since I have only been Z'ing for a week now. But it seems very straight forward.

Ok I tried to follow this thread, but I don't quite understand the problem. If you could just clear it up for me a bit, Where are you at? and what you are doing? I may be able to help.

Let me know and you can go from :mad: to :D

Chris Reid :D

[CHRIS REID]

Oh yeah,
Has anyone got the memoryBlock passing to work with FileExecute.
Or the Return/Output value? Doesn't work here ....

[aminuts]

hey Chris,

I reckon those commands are waiting for the sdk to be published. there are a few commands for z2 that I think are designed for integration but the sdk promised after the arrrival of z2 hasn't quite materialized.

You could try emailing support for answers to those questions and if you are that good at programming that you can absorb and do zscripting after a week......I for sure would email em.....I think they will love you!

Am hoping the sdk is soon or soon after the next release.

[marcus_civis]

Chris,
The specific problem is how to specify a particular directory when using the FileNameAsk command to select a file to Open. It's easy enough to do for file Saves but so far no one (as far as I know) has found a solution for Opens. I, at least, would find such a thing useful. If you've got one, please post it!

[CHRIS REID]

I will look into it.
Do you mind if it is native to zbrush or can it be windows. Unfortunately I have never looked into what it takes to make something cross platform. I use VC++ 6 to do all of my coding thus far, and I believe I would need to get a copy of CodeWarrior.
I will look into this too.

hmmmmmmm....Sounds like the zscripters are in need of a utility dll.
I can make a ZBrush2Windows Utility .dll that everyone can use with their scripts. As I do this stuff, I will build and Doc something for the community.

[marcus_civis]

Thanks. :) A pure zscript solution is preferable, of course because they work on either platform. I'm only just starting to learn VC++ .NET but I'd be very interested in any info you care to share. But you'd certainly need to compile a separate Mac dll using Code Warrior as Macs are bigendian.

[CHRIS REID]

I have a feeling that in order for this stuff to all work out, Pixelogic is going to have to make an OS test in their scripting so scripts know whick dll/File's to use. ...I mean, nothing *HAS* to be done by them but it would make it easier on everyone in the long run. There are always workarounds. May have to make script installers or something.

Oh well, just some silly ramblings....:rolleyes:

Chris Reid

[TVeyes]

We do the OS test ourselves through Zscripting. Using the [ZbrushInfo,....] command you can test which OS zbrush is running on. Then it is a simple matter of including 2 [FileExecute,....] commands in an [If,...] command.

Regarding passing variables to a dll, I will post some info a bit later on how to implement the numerical value and memory blocks in a [FileExecute,...] command.

Edit: Wrong thread. I posted the DLL info in this thread (http://www.zbrushcentral.com/zbc/showthread.php?t=24066).

[CHRIS REID]

TVeyes,
Great to hear :D

I should of done a bit more research before I typed. :cry: sorry

I have only been Z'ing for a week or so. I am sure there are plenty of functions that I havn't stored in my little brain yet. So much fun so far.

I can't wait to see how the numeric and memblocks work with FileExecute. I will play some more tonight, now that I got it workin with text.

Thanks again

Edited comment:
Here is TVeyes expanation of passing variables to [FileExecute]
(http://www.zbrushcentral.com/zbc/showpost.php?p=193516&postcount=8)

[Svengali]

Concerning Davey's tip on an alternative way to define a filepath:


Here's another tip: you can specify any path starting at the 'top' of the ZBrush folder tree: i.e. 'ZBRUSH_ZData\ZPlugs\WebZPlug.dll' specifies the ZData\ZPlugs\WebZPlug.dll path within the ZBrush folder.
Has anyone else been able to get this to work? I can't, but don't know what I'm doing wrong.

example:
[FileNameSetNext,"ZBRUSH_ZStartup\ZPlugs\myscript\myscript.zsc"]
[IPress,ZScript:Load]

This doesn't do it. What am I missing?

Sven

[marcus_civis]

Hi Sven,
Yes, I've used this but with forward slashes rather than backward:

[FileNameSetNext,"ZBRUSH_ZStartup/ZPlugs/myscript/myscript.zsc"]
[IPress,ZScript:Load]

(This is how it is given in Davey's online code reference).

Cheers,

[Svengali]

Thanks Mark,

I tried substituting forward slashes and still can't get a clean result... However, as with many of the obstacles I run into with ZScripting, I figured out a work-around that took me about five minutes to get working.

I'm still upset I can't get Davey's tip to work as I'm thinking forward to other scripts where it might really be handy (and the only way to resolve path differences in user installations). :rolleyes:

Anyway, thanks for the pointer on the forward slashes. I'll have to try out path designations in other scripts where I couldn't figure out syntax that worked, (For example, the lame Load Dialog work-around I sent you...:p )

Later, Sven

[marcus_civis]

Sven,

AH, now I am worried - I use this in a script I'm working on and it's pretty much essential. :( Perhaps you would post a small sample zscript with the code that won't work for you? Then we could test it and see what result we get.

[Svengali]

OK, here's a simplest version of what I've been trying to do:

PathTest1 runs PathTest2. PathTest2 runs PathTest1.
According to Davey's tip, the paths should resolve using Zbrush_ZScripts/, but for me it does not.

Since both scripts are in the same ZScripts directory, I can change that one line of code in each script like this: PathTest1.txt to [FileNameSetNext,"PathTest2.txt"] and [FileNameSetNext,"PathTest1.txt"] and it runs, toggling between the two scripts.



// PathTest1.txt
// test of Davey's tip

// - - - - - run other script

[IButton,"runPathTest2","press to launch other script",
[FileNameSetNext,"Zbrush_ZScripts/PathTest2.txt"]
[IPress,ZSCRIPT:Load]
]




// PathTest2.txt
// test of Davey's tip

// - - - - - run other script

[IButton,"runPathTest1","press to launch other script",
[FileNameSetNext,"Zbrush_ZScripts/PathTest1.txt"]
[IPress,ZSCRIPT:Load]
]


Again, is there something I'm not seeing?

Sven

[TVeyes]

Hi Sven,

You are simply not writing in upper case when using the zbrush root directory reference. Normaly zbrush does not care about lower/upper case in directory names but in order for the zscript interpretor to recognise the zbrush root directory reference it must be in upper case. i.e ' ZBRUSH_Zstartup/Zplugs/MyScript.zsc '

Don't kick yourself too hard ;)

[marcus_civis]

And interestingly the direction of the slash makes no difference.

[Svengali]

Argh! UpperCase grem strikes again.

Thanks TV, I guess that makes sense in a ZScript sort of way. I've long since stopped kicking myself over ZScript, though. :D

[edit: ignore me for a while, I need a break!]

Sven

[Svengali]

Here's another apparent gotcha that might be good to know.

Using the previous code examples of Script A calling Script B... and Script B calling Script A, (with ZBRUSH_ appropriately capitalized of course... )

Each time one script calls the other, there is a tiny bit of MEM creep - - when you run the two, toggling back and forth, you can watch the MEM numbers click up in the title bar. (ZSCRIPT:Record is turned off)

However, if the code in each is changed so each calls the .zsc version of the other, the MEM creep stops. My guess is there's some slight, unrecoverable overhead when ZScript's interpreter converts .txt to .zsc to run it?

Agreed this is a special case situation... I was having the scripts call each other in .txt form so edits during script development would be immediately effective. However the creeping choke-off was creating stability problems - at least that's what I'd like to think was causing it. :)

Anyway, this is just another of those "BTW" observations. Any comments or feedback appreciated, especially if your milage varies.

Thanks, Sven :D

[marcus_civis]

Sven,

That's interesting. I recently suffered serious stability problems after repeatedly reloading a script I was testing. I thought I was going to have to reinstal ZB but then the problem went away by itself. I don't know why. With slight trepidation I'll test your scripts to see what happens...

The defaultzscript is not rewritten as a zsc, is it? Although that doesn't mean it's not converted in memory.