I have a user with an “é” in it’s Windows account name. The application runs fine but the Xojo Worker does not launch. The app is installed in the default Program Files (x86) folder.
There’s no problem with the app except for this user with a special char in his name and that’s the only difference I can see.
Can some at Xojo confirm that the problem could be a path name with a special char that prevents the worker from launching?
Xojo uses utf-8 for its internal handling of unicode chars (accented letters in this case) and Windows have 2 different sets of APIs, both byte code incompatible with utf-8. One is utf-16, that preserves most of the international unicode chars (but loses many not latin based too), and Windows ANSI, that destroys the majority and depends on a very old concept of “code pages” not used anymore. So depending on the Xojo internals, yes, maybe you have found a “lost in translation” problem.
In the past I had a problem with an app with accented chars on its name because the lib path of the app automatically included such chars BUT at runtime Xojo couldn’t find the libs maybe due to mixed APIs that time? I’ve worked around it renaming the app and removing the accents and also renaming the full name libs and resources sub-folders to just Libs and Resources.
Déjà-vu? It must be investigated and if possible fixed. Maybe a reminiscent bug?
Thanks, Rick! The issue is, the worker performs so fast, I could not see it running in the Task Manager 
Indeed the worker runs fine and does his work; it creates a file in the users temp folder and returns the path to the app. And here is the result:
The problem is the path, but not the worker itself. I have to workaround this by myself.
Create an user called déjà-vu-test in your system and try a sample test you can report in case of fail.
Yes. I can see an utf-8 string being interpreted as ANSI there.
I’ve created a user named “stéphane”. This works in the event “JobCompleted”:
var result as string = jobResult
if result.Encoding = nil then
result = result.DefineEncoding (Encodings.UTF8)
elseif result.Encoding <> Encodings.UTF8 then
result = result.ConvertEncoding (Encodings.UTF8)
endYou restored the string interpretation, but the bug wasn’t “The worker does not launch”?
Edit: Oh, I see. You found the culprit.
That may be unnecessary. If you always return a file path in utf-8 (xojo style) just apply the encoding. I believe that ALL Xojo IPC contents does not carry an encoding, so probably they all are Nil.
So a
Var result As String = jobResult.DefineEncoding (Encodings.UTF8)
Should suffice.
Sorry, “believe” and “should” are evil; I have to ensure that the enconding is correct, not probably correct.
For your present case I can affirm it. As the creator of such content “on the other side” just apply the proper expected encoding.
"The encoding of the jobResult that is not preserved from the value returned by JobRun. Apply the encoding as necessary. "
RTFM!
(Body seems unclear, but is it a complete sentence.)
A logical approach. All probabilities need to be tested, not asserted on the basis of assumptions.
Or read the manual.
