I’m still trying to track down why under Linux Mint an HTMLViewer has trouble finding ExecuteInXojo. To this end I made a small app whose sole task is to run and report whether it can use ExecuteInXojo, or whether when it does so it gets a javascript reference error.
Testing under Mint reveals that my tester app reports success if the executable is double-clicked, or, perhaps more interestingly, it is run from a Terminal window IF AND ONLY IF, the PWD is the directory containing the executable.
So, if the app (and supporting folders with libs) is in myappfolder on the desktop, and then in Terminal I type:
cd ~/Desktop/myappfolder
./myapp
then it reports success. But if I then do:
cd ..
myappfolder/myapp
then it reports failure. To me this implies that a module or something in one of the libraries has a wrong path.
But I wondered whether I could do something like:
Var f as FolderItem
f = new FolderItem ("", FolderItem.PathModes.Native)
System.EnvironmentVariable("PWD") = f.NativePath
But, where to put this code? What piece of user code executes the earliest as an app starts up? I’ve tried the Opening event of the HTMLViewer, the WIndow, and the app without success yet. Am I close? Or is this the wrong approach?
Dim err As Integer
#If TargetMachO
Const chdirLib = "System.framework"
#ElseIf TargetLinux
Const chdirLib = "libc"
#EndIf
Soft Declare Function chdir Lib chdirLib (path As CString) As Integer
Dim myPath As String = "/Users/Shared/"
err = chdir(myPath)
If Not err = 0 Then
System.DebugLog("ERROR " + Str(err))
End
does not do? I’ve already verified that my code does, in fact, change the PWD. The question is whether that is what I need to be doing (other than waiting for Xojo to look into it, that is).
The PWD Environment variable can be set to anything. This does not change the current working dir.
Sample:
% cd /Users/Shared
% echo $PWD
/Users/Shared
% PWD="bla"
% pwd
/Users/Shared
% echo $PWD
bla
I cd into “/Users/Shared”
PWD variable is assigned to the current path
Now I set something else to the PWD variable
The current working dir is still the same as shown by the “pwd” command.
Here’s what I’ve tried, running the IDE and the test app under Mint in a VM. In my test app’s Opening event I put:
Var f as FolderItem, result as Integer
f = new FolderItem ("", FolderItem.PathModes.Native)
result = mychdir (f.nativePath)
and the mychdir method looks like this:
Function mychdir (pathtoset as String) as Integer
Soft Declare Function chdir Lib "libc" (path as CString) as Integer
Var result as Integer
result = chdir (pathtoset)
Return result
End Function
Under the Xojo debugger, the app runs and reports success (in finding ExecuteInXojo). This has not happened before. And I can double-click the executable, it runs and reports success. But that’s the extent of it. In all other circs it segfaults, such as if I run the ececutable from a directory other than the one containing it.
Essentially, it looks as if it’s failing to actually change the working directory. Supply the one it already has and it doesn’t segfault.
Here is some sample code (macOS) how to get the error string:
Soft Declare Function strerror Lib "System.framework" (errcode As Integer) As Ptr
dim errorMsg as MemoryBlock = strerror(errorCode)
If errorMsg <> nil then
Return DefineEncoding(errorMsg.CString(0), Encodings.SystemDefault)
Else
//something bad has happened
Return ""
End if
Actually, that wasn’t the difficulty. When I wanted to look more closely (in built apps, as under the IDE debugger all worked as I wanted), the result, uniformly, was NoError. The segfault happened later, on this statement:
f = SpecialFolder.Resource ("mytest.html")
as was easy to pinpoint (once I realised that your declare was not giving an error) using MessageBox. So I conclude that yes, one can change the working directory but that messes up the operation of the Xojo Framework.