Sign in to follow this  
Followers 0
Diana (Cda)

Relative paths work for AU3s but not always for shotcuts ... ?

6 posts in this topic

For various reasons, I converted everything in all my AU3 files to relative paths from absolute ones about a year ago after encountering various headaches related to dealing with moving all my scripts to a new computer and, hence, new drive letter, and in using these scripts on my thumb drive. All in all, relative paths allow me to keep everything synchronized between 2 systems without those full-blown headaches! <g>

However, a recurring problem lies with the sound files using relative paths on the hdd. Fortunately, not an issue on the thumb drive as the launcher there deals with the AU3s directly and no shortcuts used. However, tests done on the hdd show that launching scripts directly from the AU3 _always_ play the sound, whereas the same script launched from a shortcut to it don't play the sound 9 times out of 10, if not more! These shortcut file paths can't be changed, unfortunately. They need to stay as is; it's to fix the relative paths to the WAVs that I hope to address.

Granted, this isn't a terribly bad thing. After all, it's only the sound files that are being affected and not something more serious, but I'd still like to figure out why this is a problem. I believe that it's because the AU3s are all located in the same folder relative to the WAV folder, whereas the shortcuts all lie one to 2 folders away from this "root" AU3 folder.

For example, for an example of an AU3's actual folder located here:

F:\AUTOIT\Scripts\ASCII- ½.au3

the WAV file it references is this:

SoundPlay ("..\Scripts\WAVs\CAMERA.WAV")

where the physical location of that WAV is this:

F:\AUTOIT\Scripts\WAVs\CAMERA.WAV

Fine. I launch the script via the AU3 file and the WAV plays just fine.

However, I launch scripts via shortcuts accessed via a toolbar I added to my taskbar, where the path to the above scripts, for example, is located here:

F:\AUTOIT\Scripts\AI\ASCII characters _and_ Misc\ASCII character - ½.lnk

where the path to the WAV is still here:

F:\AUTOIT\Scripts\WAVs\CAMERA.WAV

Most times, the sound hardly ever plays, with a relative path of:

SoundPlay ("..\Scripts\WAVs\CAMERA.WAV")

No go.

Here is the script in its entirety:

;
; AutoIt v3.0
;
SoundPlay ("..\Scripts\WAVs\CAMERA.WAV")

ClipPut("½")

Sleep(500)

Exit
; finished
I don't know if there is a solution to this, but hoping there is some other way to type in a relative path so that it works in all instances whether I'm dealing with invoking the script either from the AU3 file itself or a shortcut located anywhere _without_ referencing an absolute path!

If I can fix this, then I'm all set. Here's hoping ... <fingers crossed>

Also, hoping the problem is clear enough. It's rather difficult to explain the situation unless one tries to set up something similar using a couple of dummy files and folders. <g>

Thanks! :whistle:

Share this post


Link to post
Share on other sites



Maybe because you are using a shortcut, the path varies slightly.

I tried opening a notepad window and closing it then displaying the script path and that looks ok. Maybe you need to add or take away an ending backslash?

I don't know...I have to get going...have a happy fourth.


Be open minded but not gullible.A hammer sees everything as a nail ... so don't be A tool ... be many tools.

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

I understand what you mean, but I'm not sure I explained the problem properly.

When calling the action from the scripts directly, they all work. When calling the very same scripts from a shortcut rather than clicking on the AU3 files directly, they often don't work. This may have not been a problem up until I posted this message since it was only the WAV files that were being affected, and even then, they didn't always fail.

However, this has now become an issue on my USB flash drive. To get around the lack of true portability in an otherwise fantastic standalone scheduler, I've been using AI with relative paths to launch things. I'm having the same issues with the paths now on the flash drive. This is no good.

Is there a way to code paths, that I haven't been able to figure out, so that things will be launched properly at _any_ time whether or not we use the AU3 file directly or do so from a shortcut??

Thanks! :whistle:

Edited by Diana (Cda)

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

In shortcuts, be sure to specify the working directory! (In English it's probably something like Start From in the shurtcut properties.) That's the only difference I can think of between running au3 scripts directly or through a shortcut that would lead to this problem

From within your script, you might want to use the @ScriptDir, as in Run(@ScriptDir & "\..\Scripts\WAVs\CAMERA.WAV".

Though the "..\Scripts\" shouldn't be necessary if your Script is in the Scripts directory... Using @ScriptDir & "\WAVs\CAMERA.WAV" should work too. Same as the difference between 3-3+1+2+3=6 and 1+2+3=6 :whistle:

@ScriptDir

Directory containing the running script. (Result does not contain a trailing backslash)

Edited by SadBunny

Roses are FF0000, violets are 0000FF... All my base are belong to you.

Share this post


Link to post
Share on other sites

I don't know if there is a solution to this, but hoping there is some other way to type in a relative path so that it works in all instances whether I'm dealing with invoking the script either from the AU3 file itself or a shortcut located anywhere _without_ referencing an absolute path!

Before using a relative path, the script should check it's working directory. If your script requires a working directory being the same as the script, then you can add the below before using the relative addressing.

If @WorkingDir <> @ScriptDir Then
    FileChangeDir(@ScriptDir)
EndIfoÝ÷ Ù.®Ç+b²z0±ëm¢ë­éZ¶+Þi×kzË"§z0ç`zíç(®·¶*'¡ü(®H§Ø«yËh¯(ܲwuçX¢çÈ^rKa{
+)àv*ÞrÚ+ɧíz¼­ÛÊ"*.rì׫¶­)^
§àâ®f²}¨¥êÞƧ¢Ø^­ìZ^méhÁú+®éçxì^rëZnWɪޫb½êZ¶-Â)erØ^Âäx·¶òùèµú.Ûazw!yÉ-ë®*mv*ÞrÚ+Éélyìb¶'ç¢×èºwZºÚ"µÍYÝ[Q^ÝÊ    ÌÎNÜÛÛYY[K^IÌÎNÊH[[Q^ÝÊØÜ   [È ÌÎNÉÌLÜÛÛYY[K^IÌÎNÊH[Q[PÚ[ÙQØÜB[ÙRYÝ[Q^ÝÊ ÌÎNÜÛÛYY[K^IÌÎNÊH[SÙÐÞ

ØÜ[YK ÌÎNÜÛÛYY[K^HØÈÝÝ[[ ÌÎNÈ [ÈÔ   [ÈÂBBPÛÜÚ[Ñ   [ÈÔ   [ÈÂBBIÌÎNÛÜÌÎNÈ    [ÈÔ   [ÈÂBBPØÜBQ^]B[Y

The above give you an option to use a custom working directory if you were running your script from a command line like a command prompt. It gives a 2nd chance if your custom working directory fails and you may expect the setup to be within the script directory.

Relative addressing is a very handy option but your script should always know the working directory before using relative addressing. :whistle:

Share this post


Link to post
Share on other sites

In shortcuts, be sure to specify the working directory! (In English it's probably something like Start From in the shurtcut properties.) That's the only difference I can think of between running au3 scripts directly or through a shortcut that would lead to this problem

From within your script, you might want to use the @ScriptDir, as in Run(@ScriptDir & "\..\Scripts\WAVs\CAMERA.WAV".

Though the "..\Scripts\" shouldn't be necessary if your Script is in the Scripts directory... Using @ScriptDir & "\WAVs\CAMERA.WAV" should work too. Same as the difference between 3-3+1+2+3=6 and 1+2+3=6 :whistle:

This is extremely interesting, thank you! I see the potential areas of problem. One of the big things is that, yes, I _don't_ have the box in the shortcuts filled anymore for the working directory. When I moved all my data to this new computer and had so much work renaming all my AI shortcuts that I now no longer keep that box filled. Further proof that it isn't always necessary to have info there is by using the FILE>NEW>SHORTCUT option in Windows Explorer. Unlike creating a shortcut with the context menu, this method leaves the working directory blank. Shortcuts work just fine without it, _except_, I'm beginning to suspect, with regards to AU3s and the odd app or two here and there, like a 16bit app that I still use.

However, I'm going to keep leaving that box empty. I believe that changing the code itself to something that will work will be better anyway in many respects. From an intuitive perspective, finding fool-proof code seems like a much better solution and @ScriptDir sounds like it might do the job. I'll check it out and see what happens.

p.s., as an aside, yesterday gave me further proof that developers are absolutely NOT yet understanding what portability truly means. I'd say that up until now, 90% of all the so-called portable-labelled apps I've tried are nothing of the sort. They're STANDALONE apps to which people have slapped on a "portable" label! <g> Portability comes from relative paths and absolutely NO drive letters <g>. I've used my USB flash drive on 3 computers so far and each one assigns a different letter to the stick. My USB flash drive launcher, the truly formidable and truly portable PStart, does just fine as it never references a drive letter for anything. But there are a lot of issues with the apps that have to have drive letters in their INIs, etc. I foresee using AI as a workaround for great apps built before this age of portability.

Thanks!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0