Re: [Sikuli-driver] [Question #287160]: no error and no run
Question #287160 on Sikuli changed: https://answers.launchpad.net/sikuli/+question/287160 Status: Answered => Open ya6101461014 is still having a problem: it work . thanks but it didn't click 002 and i'm sure 001 002 all exist on my desktop. why? -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
Re: [Sikuli-driver] [Question #286841]: Jython and ensurepip
Question #286841 on Sikuli changed: https://answers.launchpad.net/sikuli/+question/286841 Status: Open => Answered RaiMan proposed the following answer: --- ensurepip can also be bootstrapped with a script ... this might be, but the overall design of this feature requires, to run the script from commandline with the P(J)ython interpreter and a valid P(J)ython installation, that is known in the current environment (it tries to install something in this environment and changes the environment accordingly). All this is not given when you run a script with the means of SikuliX, since there is no such environment at runtime (internal use of a dynamically allocated interpreter instance). this might be helpful: http://sikulix-2014.readthedocs.org/en/latest/scenarios.html#using-python -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
Re: [Sikuli-driver] [Question #287160]: no error and no run
Question #287160 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/287160
Status: Open => Answered
RaiMan proposed the following answer:
nothing to do - only function definitions, that are not used/called.
might be your intention was (mind indentation):
def ex(exname):
exists(exname)
def cl(clname):
click(clname)
if ex("001.png"):
cl("002.png")
else :
popup("no find")
--
You received this question notification because your team Sikuli Drivers
is an answer contact for Sikuli.
___
Mailing list: https://launchpad.net/~sikuli-driver
Post to : sikuli-driver@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sikuli-driver
More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Question #287160]: no error and no run
New question #287160 on Sikuli:
https://answers.launchpad.net/sikuli/+question/287160
hello all
i write a script like this
def ex(exname):
exists(exname)
def cl(clname):
click(clname)
if ex("001.png"):
cl("002.png")
else :
popup("no find")
and i click run
but it didn't run and no error
nothing happen
(i have 001.png 002png in my .sikuli folder)
why?
--
You received this question notification because your team Sikuli Drivers
is an answer contact for Sikuli.
___
Mailing list: https://launchpad.net/~sikuli-driver
Post to : sikuli-driver@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sikuli-driver
More help : https://help.launchpad.net/ListHelp
Re: [Sikuli-driver] [Question #287091]: Problem with threading/multiprocessing --- use observe in background
Question #287091 on Sikuli changed: https://answers.launchpad.net/sikuli/+question/287091 Status: Answered => Solved Gabriel confirmed that the question is solved: I thought about using while + exists with a break before, but wanted to check if there was a cleaner way. But this definitively works for me, going to mark this as solved, thank you sir. I was creating the thread like this btw: threading.Thread(target=__logoutIfSomethingOnBattle) -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
@ angelo --- But I cannot distribute a JRE in a jar file uuups, thanks for THAT pointer - did not remember this fact. Of course a big advantage. --- will there be maven coordinates for the nightly build of 2.0.0 yes. Planned to be started towards end of April. ... and finally thanks for the kind feedback. -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: In Progress Bug description: based on the related question: https://answers.launchpad.net/sikuli/+question/260735 from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
@ Raimund But I cannot distribute a JRE in a jar file. With launch4j I can wrap everything together and distribute a suitable and tested JRE version on the users computer without interfering any previous Java installations. Anyway Java has a bad reputation (which I totally agree when it comes to Java Browser plugins). So I do not want to bother my users with downloading and installing a JRE which needs admin rights and annoys with update notices every few weeks. This is far away from a neat standalone solution. Thank you very much for your effort on this. I am sure this will help some more people. By the way, will there be maven coordinates for the nightly build of 2.0.0? I remember you had something similar for the 1.1.0-SNAPSHOT. Cheers, Angelo P.S.: Thank you very much for maintaining this great framework. The world needs more passionate people like you... -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: In Progress Bug description: based on the related question: https://answers.launchpad.net/sikuli/+question/260735 from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
@ angelo Thanks for the feedback - now I understand your actions on the bug description ;-) --- The advantage of the wrapped .exe is to distribute just one standalone application. I never really understood that argument, because you could get the same, if you pack everything together in a standalone jar. ... but nevertheless, I will try to solve this latest with version 2 -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: In Progress Bug description: based on the related question: https://answers.launchpad.net/sikuli/+question/260735 from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
@ Raimund Just adding valid content does not work. But I found the initial question to this bug and realized that it works if the jar is besides the .exe. This is fine for my case. The advantage of the wrapped .exe is to distribute just one standalone application. -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: In Progress Bug description: based on the related question: https://answers.launchpad.net/sikuli/+question/260735 from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1547906] Re: [1.1.0] Failed using Sikuli Mat --- not supported
Ok, I will manage to use the OpenCV on my own. Tanks for your answer and thanks for the great job ! -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1547906 Title: [1.1.0] Failed using Sikuli Mat --- not supported Status in Sikuli: Won't Fix Bug description: Hello, I'm using your API and i want to do some Image processing using the Mat object provided in SikuliX. But when I create it, it always throws an exception. Here is the error thrown : Exception in thread "main" java.lang.UnsatisfiedLinkError: org.sikuli.natives.VisionProxyJNI.Vision_createMat(II[B)J at org.sikuli.natives.VisionProxyJNI.Vision_createMat(Native Method) at org.sikuli.natives.Vision.createMat(Vision.java:67) I have no problem using other proxy objects like 'find' or 'OCR' and I am currently using the maven dependency 1.1.1-SNAPSHOT version of SikuliX. I can provide you a full example if you want but i assume reproducing it is no big deal. Best regards, Julien To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1547906/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
@ angelo Thanks for your information and evaluation. I will check that during the next time (weeks) and decide, wether I will do something with version 1.1.x in that direction. For your current situation: If you add a valid content into the folder SikulixLibs_201510051707, then you might have a chance. After having run setup, you should have this content on that machine to make a copy. BTW: what is the advantage of having an .exe? -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: In Progress Bug description: based on the related question: https://answers.launchpad.net/sikuli/+question/260735 from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
** Changed in: sikuli Status: Fix Committed => In Progress ** Changed in: sikuli Importance: High => Medium -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: In Progress Bug description: based on the related question: https://answers.launchpad.net/sikuli/+question/260735 from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Question #260735]: Status of bug #1411165 changed to 'In Progress' in Sikuli
Bug #1411165 status changed in Sikuli: Fix Committed => In Progress https://bugs.launchpad.net/sikuli/+bug/1411165 "[request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe" This bug is linked to #260735. Launch4J: an exe containing sikulixapi.jar does not work https://answers.launchpad.net/sikuli/+question/260735 -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
** Description changed: - based on the related question. + based on the related question: + https://answers.launchpad.net/sikuli/+question/260735 from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box - true + true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: Fix Committed Bug description: based on the related question: https://answers.launchpad.net/sikuli/+question/260735 from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
@Raimund Building an .exe with launch4j is possible. I use "com.akathist.maven.plugins.launch4j" for that purpose (Hope I understood that correct). I tried your suggestion the following way: Done on a fresh Windows installation: - Downloaded SikuliX from https://launchpad.net/sikuli/sikulix/1.1.0 - Ran sikulixsetup-1.1.0.jar - Chose option 2 - Copied sikulixapi.jar to my development machine - Reset the Windows VM to the initial Snapshot Done in my Windows development machine: - Imported the generated sikulxapi.jar to the local maven repository with mvn install:install-file -Dfile=sikulixapi.jar -DgroupId=com.sikulix -DartifactId=sikulixapi -Dversion=1.1.0 -Dpackaging=jar -DgeneratePom=true - Build the myprogram .exe Done on a fresh windows installation: - Run the build myprogram.exe So using the specially built sikulixapi.jar in a launch4j build does not seem to work either. Result: - A folder %APPDATA%\Roaming\Sikulix was created with empty subfolders: Extension, SikulixDownloads, SikulixLibs_201510051707, SikulixStore - myprogram.exe shutdown immediatly -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: Fix Committed Bug description: based on the related question. from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
Re: [Sikuli-driver] [Question #283766]: unable to run sikulixapi with IBM RFT
Question #283766 on Sikuli changed: https://answers.launchpad.net/sikuli/+question/283766 Status: Open => Expired Launchpad Janitor expired the question: This question was expired because it remained in the 'Open' state without activity for the last 15 days. -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
Re: [Sikuli-driver] [Question #287091]: Problem with threading/multiprocessing --- use observe in background
Question #287091 on Sikuli changed: https://answers.launchpad.net/sikuli/+question/287091 Status: Needs information => Answered RaiMan proposed the following answer: This would be a suitable way, to assure the thread terminates, if the main terminates: # --- main shouldStop = False # do some preparations # start the thread # do your work # do your normal end procedure shouldStop = True wait(3) exit() # --- thread module while not shouldStop: wait(1) if exists(scenario, 0): # do your logout/cleanup break -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
Re: [Sikuli-driver] [Question #287091]: Problem with threading/multiprocessing --- use observe in background
Question #287091 on Sikuli changed: https://answers.launchpad.net/sikuli/+question/287091 Status: Open => Needs information RaiMan requested more information: what P(J)ython features exactly are you using, to create and run the thread (only the skeleton code)? -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
[Sikuli-driver] [Bug 1411165] Re: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe
@angelo As far as I understand: Maven is not suitable for launch4J, because the latter has its own mechanism, to build an exe. Have you already tried to use a ready-built-for-Windows sikulixapi.jar (setup option 2)? -- You received this bug notification because you are a member of Sikuli Drivers, which is subscribed to Sikuli. https://bugs.launchpad.net/bugs/1411165 Title: [request] Launch4J support: sikulixapi.jar should work, when wrapped into an exe Status in Sikuli: Fix Committed Bug description: based on the related question. from comment #1: the current implementations of SikuliX will not work, if you pack everything into the exe, only the version launch-only work out of the box true ... but I guess, this is not what you want ;-) If you wait a few days: there will be sikulixapi.jar, that can be wrapped in the exe. The problem with Launch4J: If anything goes wrong inside, as in this case, the exe simply dies without any comment. The problem with SikuliX: SikuliX exports the native libraries at runtime to the libs folder. this currently is based on the existence of a real jar, which is not available in this case of wrapped exe. The solution: I have already added a feature, to just access the resources from class path. This is not yet available in sikulixapi.jar, but will be in a few days. The libs will then be exported to temp. In any case (as now): existing libs are checked and an export is only done, if needed based on timestamp and the libs folder is added to system path at runtime dynamically. To manage notifications about this bug go to: https://bugs.launchpad.net/sikuli/+bug/1411165/+subscriptions ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
Re: [Sikuli-driver] [Question #287091]: Problem with threading/multiprocessing --- use observe in background
Question #287091 on Sikuli changed: https://answers.launchpad.net/sikuli/+question/287091 Summary changed to: Problem with threading/multiprocessing --- use observe in background -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. ___ Mailing list: https://launchpad.net/~sikuli-driver Post to : sikuli-driver@lists.launchpad.net Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
