It doesn’t matter how long the code is running, the Window does not hide. If I call an AppleScript between Hide/Show everything works as expected. When I remove the Show command at the end the Window will hide but only when the Method ends.
Though I admit, the real syntax would have to be something… different. Regardless, giving us some way to do the desired task without teaching the user about threads, addhandler, interface update, etc. would go a long way to helping users develop better apps.
Thanks to all for helping. I realized that the Timer does not speed up things as I thougt. So I think threading will be better. Is it possible to dynamically create multiple threads, so if thread 1 has not finished its work, then create a new one? The Desktop Example shows 4 threads tied to a window. My threads should work without a window being called from a Method App.Action().
Thanks for the hint. It seems not to work when the Thread calls a shell command. That seem to block the whole App until the command has finished. In this example I play a longer sound. In my real code, I call several shell commands depending on the results.
Var sh As New Shell
// Process sh.Result …
Thanks again. Didn’t imagine that it will get so complicated so fast.
How can I store the returned result so that the calling thread which is waiting for it gets the right one? Or do I have to split my code with multiple Shell commands into a lot of Completed() methods? But how do I transfer the values from one to next?
Is it right that async Shells can’t be created with code, but only by an item in the left sidebar? This seems not to work:
Var sh As New Shell
sh.ExecuteMode = Shell.ExecuteModes.Asynchronous
In the DataAvailable event move the data to a property with ReadAll. The design of your classes/subclasses will determine the plan for this, so we’ll keep moving for now.
This would be best, really. We can design a class/subclass architecture that keeps things clean in your sidebar while still doing what we want.
I might recommend a design where you have a class that acts as the “controller”. You could optionally use Thread as a superclass for this, but if it’s mostly just waiting for shells I don’t see it as necessary. The controller class would retain the results and move them from one shell command to the next.
You can create them in code, but you still need to retain the reference while it runs. You can store it in a property of a window, class, module, or whatever. Yes it still shows up in the navigator, but it would be a property. If you really really don’t need to subclass Shell for this it can be done, but that doesn’t always mean that you should.
late thanks for your investments and the example. I haven’t transferred it to my project yet. Before I start learning, one question: Would a Worker be easier to implement, or will non-async shell commands in a Worker also block the whole App?
Thanks for your additional hints. After some investigations, I came to the conclusion that chained shell calls are impractical in my case. I use a lot of shell command likes conditional mkdir with -m parameter, sips and screencapture. It seems it’s better to transfer some parts my App into a shell script so that I only have one shell.execute in my Xojo Project.
I also could transfer all shell command to native Xojo code. Creating folders with permissions shouldn’t be hard, cropping/resizing images seems also to be possible, but what about “screencapture”? Is it possible without using MBS?