sikuli-driver team mailing list archive

[RaiMan <question246389@xxxxxxxxxxxxxxxxxxxxx>]

Question #246389 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/246389

    Status: Open => Answered

RaiMan proposed the following answer:
With a .skl script all the bundle path related information is no longer true with respect to the place, where the .skl is located, since at runtime it is unzipped to a temp folder as a runnable --temp--.sikuli and run from there.
So in a .skl you have no chance, to get the folder, where the .skl is stored.
If you run it being in the same folder as the .skl, you can use:
workDir = java.lang.System.getProperty("user.dir")

If this is not the case, you might try to hand over the path as a
parameter or even hard code it.

The reason: a .skl was intended to be self contained with no need for anything outside the .skl package.
.skl is deprecated and will be replaced by another concept in the next version (... .skl witll be runnable, but no longer creditable and can be converted to the new packaging concept).

What is your expected advantage over using .sikuli when using .skl?

If your intention is to have a self contained package containing
everything needed, you have to place the imported .sikuli into the main
.sikuli folder before making a .skl, since then everything will be
available in the temp folder at runtime.

But if your imported stuff is intended to be reusable from other scripts
also, this is of course a contradictory solution ;-)

-- 
You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.