Shell problem

hi,
I run a long time processing using the shell but after a few mins the command quits and then continue the program execution
If i run the command via terminal, it’s ok and finish after 15mins.
I have to work with large image files, from 3gb to 8/10gb.
is there a timeout problem within the shell command?
do you have any suggestions?
thanks

I would suggest running the shell from a thread thus leaving your application responsive.
Maybe that would sort the timeout issue as well? :slight_smile:

[quote=123518:@mario rossi]I run a long time processing using the shell but after a few mins the command quits and then continue the program execution
If i run the command via terminal, it’s ok and finish after 15mins.
I have to work with large image files, from 3gb to 8/10gb.
is there a timeout problem within the shell command?[/quote]

There should not be a timeout under Mac OS X, only on Windows. If you are using Mode 0, try Mode 2 (asynchronous).

Hi Mario,

With your current code, are you checking the Shell.Errorcode value when it appears to timeout? That could give an indication as to what is going on.

Having said that. Albin’s recommendation is definitely the way to go - run the shelled process in a thread and use a mode 1 timer to update the UI. But, there is a test that you can run if your code starts the backend process, waits for it to complete and then exits. Use this where you call the shell.execute:

theShell.Mode = 2
theShell.Execute theCommand
Do
    App.Doevents(10)
Loop Until Not theShell.IsRunning
If theShell.Errorcode <> 0 Then
    // Handle Error
Else
    // it worked, so continue
End If

That should allow your app’s UI to stay responsive.

One note - if the shelled process never exits, your app will appear to hang on the Do … Until loop.

thank you very much to all for your advice.
i will check then I will update you.

Hi to all…
Tim’s advice seems to work even if I disable theShell.Mode = 2 because, i don’t know why, after the first sh.execute it didn’t execute the next sh.execute.
bye the way, what exactly to “App.Doevents(10)”? what’s the meaning of 10?
thanks to all

p.s anyway i don’t mind if UI is not responsible cause my sw is running on a server, so it’s all automatic.

If you do not want to send commands to the shell while it is running, you should set mode=1

The LR is your friend : http://documentation.xojo.com/index.php/Application.DoEvents

By the way, DoEvents is not recommended : "Using DoEvents in a GUI application will likely cause instability. "

In other words, using DoEvents can cause strange, erratic and difficult to find bugs.

thanks Micheal for you advice.
btw what to do you suggest me to avoid DoEvents? as I said, i have to run a shell command (imagemagick) with very large images.
the procedure may take from 5m to 10m. UI window can be frozen because it is running on a server.
thanks

Yes, don’t use DoEvents. Use App.SleepCurrentThread instead. Can you post some code or example? I’m doing something similar to what do you and my code can run for hours w/o problems.

[quote=123970:@mario rossi]thanks Micheal for you advice.
btw what to do you suggest me to avoid DoEvents? as I said, i have to run a shell command (imagemagick) with very large images.
the procedure may take from 5m to 10m. UI window can be frozen because it is running on a server.[/quote]

The UI gets frozen because you are using Mode 0, which effectively ties the process to your app. I, like Christoph de Vocht, suggested to use asynchronous Mode 1. Albin KIland suggestion to run the shell in a thread is of the same nature.

App.DoEvents used in a GUI app is inherently unstable and can provoke random bugs. That is all I said, based on Xojo official documentation. It may seem to help, but you run the risk that it crashes the app or do even more. It is like crossing a street without watching out : one of these days, a car will hit you :wink:

See https://forum.xojo.com/10498-making-the-case-to-remove-app-doevents

1 Like

In the sample I provided, the DoEvents call will have no ill affect since the code is running in a top down loop - basically, there’s no chance for that situation to create a recursive looping issue (where DoEvents issues occur).

DoEvents can be used safely in a UI app, just not by mere mortals.

Also, Trixie’s comment about using App.SleepCurrentThread() is valid for threaded processes, but be careful not to use it on the main run loop since it will cause the entire app to sleep. I always wrap that in an If … Then block:

If App.CurrentThread <> Nil Then App.SleepCurrentThread(ms) Else ... End If

[quote=124412:@Tim Jones]In the sample I provided, the DoEvents call will have no ill affect since the code is running in a top down loop - basically, there’s no chance for that situation to create a recursive looping issue (where DoEvents issues occur).

DoEvents can be used safely in a UI app, just not by mere mortals.[/quote]

Nice to know you are not among us poor souls. Being a mere mortal, I tend to trust Xojo’s documentation and have abstained to use DoEvents in GUI apps upon their advice.

I do not get the ‘top down loop’ thing.

Could you please be so kind to elaborate about the conditions required to avoid the DoEvent issues ? Is recursion the only danger ? How can one recognize the difference and construct a program to be able to use DoEvents ?

Thank you in advance.

Simply put, if you manage the recursion opportunities, recursion isn’t an issue. If you have an application that allows a “Click anywhere and I’ll do something” model, you WILL run into recursion in a LOT of situations - even those that have nothing to do with DoEvents(). However, if you adjust your UI’s handling of user generated events such that buttons, scrollbars, menus, etc. can’t be activated while a specific event is being processed, then the user can’t cause events that could affect the current loop and cause recursion.

For instance, If you’re running a loop that should preclude all app operations except aborting that loop, then you should disable ALL controls and menus EXCEPT for the button that allows the user to abort the looping code. This way, you’re in complete control of the flow and DoEvents() will never call itself.

However, if you are writing a “click anywhere and I’ll do something” app, then the LR is correct in that using DoEvents() can cause all sorts of grief.

[quote=124416:@Tim Jones]Simply put, if you manage the recursion opportunities, recursion isn’t an issue. If you have an application that allows a “Click anywhere and I’ll do something” model, you WILL run into recursion in a LOT of situations - even those that have nothing to do with DoEvents(). However, if you adjust your UI’s handling of user generated events such that buttons, scrollbars, menus, etc. can’t be activated while a specific event is being processed, then the user can’t cause events that could affect the current loop and cause recursion.

For instance, If you’re running a loop that should preclude all app operations except aborting that loop, then you should disable ALL controls and menus EXCEPT for the button that allows the user to abort the looping code. This way, you’re in complete control of the flow and DoEvents() will never call itself.

However, if you are writing a “click anywhere and I’ll do something” app, then the LR is correct in that using DoEvents() can cause all sorts of grief.[/quote]

If I understand right, the idea is to suppress all UI input but break, akin to a command-line app, and as such, all is well ?

Exactly. The ONLY time that I use App.DoEvents() is in a controlled scenario where there is no opportunity for an alternate event loop to interact with what I’m currently doing. That truly is the only time it’s safe.

Otherwise, Threads and Timers are the answer to keeping a UI responsive without worrying about this type of very difficult to troubleshoot failure.

Back to the OP, that code was simply provided to sanitize how the shell is reacting to his code. It was not meant as a permanent solution.

Keep in mind the upcoming new Framework will not support DoEvents for UI apps. So avoid when possible.

That can be another reason to keep an older version around.

To date, I still use RS2007r1 and RS2012r2.1 as well as the latest Xojo. And, I still use Visual Studio 6, and Python 1.5.2 for specific projects. Just because the tool vendor moves on doesn’t mean that you must if the existing tool works for you.

thanks to all for your help
using threads completely resolve my problem.
thanks!