user-friendly application entry points in MATLAB or SciLab - user-interface

I have an application I would like to write in either MATLAB or SciLab. This question is not about the application itself, but about entry points.
I would like a way for users to click on an icon or shortcut or whatever, and execute the following steps:
If MATLAB or SciLab is not running, launch it and wait until the launch is complete. If it is running already, proceed to step 2.
Run my application (MATLAB or SciLab script)
Any suggestions?
If the only way to do this is from within MATLAB/SciLab (vs. at the command-line) then I'll live with that, but I need to know how to do it.
Put yourself in a user's shoes: You know nothing about MATLAB or SciLab, and a coworker has given you this application that runs under MATLAB/SciLab to use.
What is the easiest way to get that user to be able to use the application, without having to teach them MATLAB commands or setting the MATLAB path or anything like that. (Ditto for SciLab.)

You can call Matlab from the command line. So you could wrap the command line call in a shortcut and all the user would have to do is double click it. I would take a look here and see if these use-cases will help, although I suspect they will.
You can do things like:
matlab -nosplash -nodesktop -r 'plot(0:.1:pi,sin(0:.1:pi))'

Related

Livecode standalone program takes 30 seconds to load

I've run into an issue with a program I created using Livecode, and now I'm looking for some help from the experts. My Google-fu is strong, yet the answer eludes me...
So here's the deal. I made a very basic note-taking program for Windows only, using very noob skills. I've been using it daily for work for the past month at least. It functions exactly as it should, except for these few things that don't make sense:
When loading the program, it takes 25-30 seconds to load. Not convenient considering it's pretty basic; one button and 5-6 text input fields, with the same number of label fields. And one background. The button just clears the text input fields.
I started to notice a problem when I went to create a batch file to load all my work programs. When the program is loaded thru Command Prompt, if I close CMD it will close the program too. I tried the same using Powershell, and it still closes as soon as the Powershell window closes. Really really strange.
I managed to find another standalone program made with Livecode, downloaded it and tested the CMD command to see if the same thing happened. It didn't, that program loaded instantly and it is ENORMOUS. It also didn't close when I closed the CMD window. I even tried this: opened my program and the downloaded program using the same CMD session, and when I closed CMD, my program closed but the downloaded one did not.
Then, I downloaded the source code for the program that was working correctly. I created a standalone for it, and tried to open that. It acts the same way as my note program does.
I don't get it. It's got to be something in my Standalone Application Settings considering what happened in the last step I mentioned, and I've been over and over those settings for hours, but I just don't have the knowledge of LC to know what to look for. I've scoured the web looking for answers to this, but it seems to be just me having this issue (story of my life, lol).
I'll be happy to post any codes, scripts, or files needed, please let me know. I just don't know which things to post =P
Any suggestions are very much appreciated!! Thank you. =)
If you call the program from the prompt directly, e.g. using
C:\program files (x86)\your_standalone.exe
the app is treated as a command line app. I have also noticed that a LiveCode app can sometimes close if the invoking command line prompt is closed, while it may sometimes continue to run. Perhaps the handling of the relaunch message has to do with it, since this message basically handles commands from the command line.
If you want the command line process to finish independently from the invoked LiveCode application, you can use the start command:
start "" "C:\program files (x86)\your_standalone.exe"
don't have enough info to be able to tell what your issue is. But that much of a delay is not usual for LiveCode apps so something is definitely wrong. How long does your app take to load if you open the stackfile in the IDE?
Not sure what StackOverflow allows but if you could upload your scripts and if possible stackfile that will give us more to go on
This has nothing to do with Windows, Batchfiles, or CMD.
CMD can workaround your problem, if it's a GUI program. See Start command, and read the help as it explains the starting behaviour of CMD and CMD's Start.
Explorer has different rules. Anything else that starts programs call CreateProcessExW which has it's own rules.

How to detect from console or GUI app was run?

Is it's possible to detect inside app from where it was run? From cmd/bash or from GUI? Assume that we are working in graphical mode, not in pure console.
Not really, but sort of. Short answer: better not to try, get the user to tell you via an argument, which you can pre-fill in a shortcut.
Long answer:
In both cases, the program is launched in a similar way: the shell application (whether cmd/bash or Windows explorer/whatever gui launcher linux has) call CreateProcess or ShellExecute on Windows or fork+exec on Linux and the way the user executed it gets lost.
However, the process does have a parent ID which might be useful.... but it isn't reliable either for a few reasons: telling if it is a gui or command line shell isn't easy (best you can do is look at the image name) and the parent might terminate as soon as you launch, so there'd be no parent! (Linux gui apps often fork themselves to detach from the terminal. Of course, if you do this you'd probably know, but if you use a library it might happen without you realizing it.)
Well, the fact that I'm going off on parenthetical asides after every sentence shows how unreliable and complicate that is. If you want to try though, looking at your parent process ID before doing any fork/detaching might be helpful.
BTW looking for a parent console isn't very helpful: a Windows GUI subsystem program won't attach to the parent console even if one exists and a Linux GUI program may attach to the controlling tty of the X window manager.
What I'd actually recommend though is passing an argument to your function to tell it how it got started. When you create the GUI shortcut, make it automatically pass the "started by gui" argument to you. Then you can check args for it and react accordingly.
It still isn't perfect, but it is fairly easy to implement and probably good enough - gui launchers would probably use a shortcut anyway and you can pass arguments through them, so the user doesn't need to know about how it is implemented.
Or you could install two programs, one which is convenient from the command line and one which is optimized for the gui environment.
But I think that's the best you can do.

In OSX, how to use Automator to launch a program whose absolute path is not known

I have a program which I want to share with another Mac user who will not use the command line. This is essentially the same problem faced here:
Easy way to launch Python scripts with the mouse in OS-X
The simplest solution proposed in answer to the above question is to create a clickable application with Automator that runs a shell script that opens the program. However, this appears to require locating the program with an absolute path, which relies on my knowing where my fellow Mac user will install it on his or her hard drive. What is the simplest way of automating the launch of a program that is in the same folder as the Automator application, when we don't know the absolute path of that folder?
In that other question you refer to, I suggested Platypus. I think that's better than Automator for your use case. Is there a reason you don't use that?
If you want to use Automator, you could paste the script into it rather than having it run a script that runs your standalone script.
Depending on quite how allergic your user is to the Terminal, you could simply supply the script with a .command file extension. In that case, when they double click it, it will open and run in Terminal automatically. They won't have to enter any Terminal command manually, which may be what they want to avoid, but they will have to see Terminal.

How to prevent error pop-up message box for failed program (.exe) when running batch file

I'm running a test script from batch file.
Because it is test, the programs are expected to fail once in a while. It is file as long as error code is returned so I can continue and mark specific test as failed.
However there is very annoying behavior of executable files under Microsoft Windows - if something fails it pop-ups window like:
This application has failed to start because foo.dll was not found, Re-installing the application may fix the problem
<OK>
Or even better:
The instruction at "..." referenced to memory at "..." ..
Click on OK to terminate the program
Click on CANCEL to debug the program
The result is known - the script execution blocks till somebody presses "Ok" button. And when we talk about automatic scripts that may run automatically at night in some headless virtual machine, it may be very problematic.
Is there a simple way to prevent such behavior and just make an application to exit with failure code - without changing the code of the program itself?
Is this possible at all?
The answer is following: You need to disable WER.
Simplest description for this I found at http://www.noktec.be/archives/259
Simply (ON XP): Right Click on My Computer > Advanced > Error Reporting > Disable
Voila - programs crash silently!
This does not solves problem when DLL is missing, but this is much rare case and this is good enough for me.
You can suppress AV's and such from showing a dialog box by running your application, or the script (the script engine, like cscript.exe), under a debugger.
Use Gflags.exe, or modify the registry directly, and set Image File Execution Options for the image in question. See this article for details on how to use the appropriate registry keys. You can set it up using a debugger commandline like "C:\Debuggers\ntsd.exe -g -G -c'command'", where you can pass commands to ignore certain types of exceptions in the -c"commmand" argument. This will effectively give you a tool to suppress interactive dialogs as a result of exceptions like AV, and will let the process continue (presumably to immediate end after the exception has occured).
This article explains the commands you can use to control exceptions and events from withing the debugger.
The -g and -G flags make sure that the process won't break into the debugger automatically during process start and end respectively. You'll have to play with the various exception suppression options to make sure that you 'eat' all possible first and second chance exceptiosn that might cause the process to break into the debugger.
Also, if you can tolerate a process being broken into the debugger (as against being stuck showing a dialog box), perhaps that would be a better option overall. You can evaluate each debug break in batch mode at a later time and decide which bugs you care to fix.
It is possible. We used to use IBM's Rational Robot product which could monitor the screen for specific items and, if found, send keystrokes to windows and other sorts of things.
We actually used it for fully automated unit and system testing, much like you're trying to do.
Now I thought that Robot has been through quite a few name changes so it may be hard to find but there it is, right on IBM's web page and with a free downloadable trial for you. It's not cheap, clocking in at a smidgeon under USD5,000 but it was worth it for us.
There's also TestComplete where you could get a licence for just unedr USD1,000 - it touts "Black-box testing - Functional testing of any Windows application" as one of its features and also has a downloadable demo to see if it's suitable before purchase.
However, you may be able to find another product to do the same sort of thing.
I initially thought of Expect but the ActiveState one seems to concentrate on console applications which leads me to believe it may not do graphics well.
The only other option I can suggest is to write your own program in VBScript. I've done this before to automate the starting of many processes (log on to work VPN, start mail, log in and so on) so I could be fully set up with one mouseclick instead of having to start everything manually.
You can use AppActivate to bring a window to the foreground and SendKeys to send arbitrary keypresses to it after that. It's possible you may be able to cobble together something from that if you want a cheaper solution.

Matlab on cmd (winxp)

I've just started experimenting something with Matlab, and since I'm used to Vim's interface, I try to stay out of Matlab's editor as much as possible. What's troubling me is that every time I start a .m file, it brings up the interface.
Is there a way to start test.m from a cmd line, and let it give output out on a cmd, as it would normally do in Matlab's environment.
Something like a "Matlab shell" (like Python's, only Matlab's)?
To answer your question, start matlab like this:
matalb -nodesktop -nosplash
This does work on both linux and windows. On linux, you type this at the command prompt, and matlab will run in that same command window in text mode. So you would get the "matlab shell" you wanted. On windows, cd into the directory where matlab is installed, and type the same command. It will open a stripped-down matlab command line window, without all the bells and whistles of the matlab desktop.
Now in my personal opinion, the matlab editor with its integrated debugger is your friend. It also has emacs key bindings, if that helps. It is also easier to execute commands and look at the results in matlab desktop then when matlab is run in text mode. The only time you really want to use the text mode is if your matlab code takes a long time to run, and you are only interested in the final result. Or if you are running multiple instances of matlab. The text mode takes much less memory, and on linux you can easily start a run from the command line and put it into background.
In fact, check the command line arguments for matlab. You can do other interesting things, like have matlab execute a single function and exit, a la perl, or redirect a script into matlab like this: matlab < script.m
Are you really willing to do dev work with no m-file debugger? Seems to me that would limit you to practically trivial programs. After a very brief learning curve, I think you'd find the Matlab integrated debugger to be fantastic (and I'm a VS person).
If you insist on doing so, your best option is to compile your m-files to be runnable stand alone. That would require access to the (not cheap) matlab compiler.
Note that there is a significant difference between the compiler distributed with matlab versions up to 6.5, and those distributed with matlab 7+ (don't know the compiler version numbers). In 6.5, the compiler generated c-code, that could be than edited and compiled separately. From 7 onwards, the compiler did no compiling, converting, or any code generation for that matter: running a 'compiled' program today practically runs it on a virtual Matlab machine called the MCR - which encompasses almost all matlab functionality. It is a massive one - MCR installer (installer!) weighted 130M last time I checked.
Some debate on this can still be found on newsgroups, but that's not important now. In fact, the MCR approach seems closer to what you seek.
And btw, for me matlab -nosplash -nodesktop works perfectly on windows - it launches matlab as a console, but that would deprive you both of a text editor and a debugger...
What I would do is:
Start MATLAB
Do not open the .m file within matlab
Open the file in your editor of choice
Run the function from within MATLAB as usual
I can't imagine any reason why this wouldn't work as MATLAB should not care what was used to edit the file.
This won't give you a "shell", but the whole GUI, but I can't think of any reason why you would not want to have that, if it is available.
On Linux environments, Matlab can be started in text mode
matlab -nosplash -nodesktop
but this doesn't work on Windows. which starts it in the current shell. On Windows, this opens a new text-only window. I know of no way to get it to run inside the current console on Windows.
Perhaps there's some way you can attach to it running it in http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/ref/matlabwindows.shtml&http://www.google.com/search?rlz=1C1GGLS_enUS302US311&sourceid=chrome&ie=UTF-8&q=matlab+command+line+windows'>automation server mode.
Another option if you're really desperate could be to make a virtual machine and install linux in it. Then I imagine there are ways to configure vim to work nicely with Matlab (I'm an emacs person these days and there are solutions for emacs).
I had the same problem as Kigurai. I needed to drive Matlab with Python so I found this solution:
In Python:
import os
os.chdir('W:\\monrépertoire')
os.spawnl(os.P_NOWAIT, 'monscript.bat')
In monscript.bat:
matlab.exe -r interp_3D -nodesktop –nosplash
There are cases when indeed not much debugging is needed and state of the Matlab shall be preserved between invocations. One (the only?) example would be Emacs org-mode . it can be used to write text interleaved with code according to literate programming etc. While it is possible to use comments in Matlab and publish code be it HTML or LaTeX, it does however require to leave the comfort of Emacs.
There is a standalone program available that uses Matlab engine to evaluate commands received on stdin, and dump the result. This particular version, however, lacks support for multiline commands like if/else/end or for/end. This is a limitation of engEvalString that expects everything at once. There is an ugly workaround available that makes it usable enough for org-mode.
#+begin_src matlab :session *MATLAB* :exports none :cache no :results value
if 3>1
'wow!!!'
end
#+end_src
#+RESULTS:
: wow!!!

Resources