I have created a standalone executable (for Windows), called ‘v1′, that has a Help Menu. I want the user to be able to use the Help Menu to open a pdf User Manual, but get an error when trying to do this from the deployed/compiled version. I think it has to do with the path. When compiling, is there something that I should be doing to make the User Manual file available to the standalone? Right now, the User Manual file is in the same folder as the executable file. In the code for v1, The callback for the User Manual Help menu contains the code: open(’UserManualv1.pdf’). My other thought is that this needs to be modified, but I do not know what needs to be added/changed.

This is the error I get when using the exe file:

??? Error using ==> open at 127
File ‘UserManualv1.pdf’ not found.

Error in ==> v1>menu_help_userguide_Callback at 2336

Error in ==> gui_mainfcn at 96

Error in ==> v1 at 42

Error in ==>
@(hObject,eventdata)v1(’menu_help_userguide_Callback’,hObject,eventdata,guidata(hObject))

??? Error while evaluating uimenu Callback

Thanks in advance for any help!

I’m glad to hear that you guys have plans to improve the compiler quality. Quality-wise, I think most people can live with minors bugs if there’s a workaround, but if the scheme/idea is not well-thought out (like single instances and default settings like Windows Vista that drives user nuts), it might start to shake people’s confidence about whether they’re using the right tools.

I was tempted to scratch my project and switch to C# for 4~5 times when I had to fight with the MATLAB compiler, and thanks to the quick and helpful support, I got through most of them and was back on track. The most fustrating experience was DCOM: the apps engineer sent me a documentation page that remote DCOM is not supported by the compiler, and I ended up setting up two virtual machines, taking the difference in the Windows+/-MATLAB/MCR installations and found that it’s just one single line that I have to add to get MCR to use remote DCOM! If that’s the one that you’re talking about, I look forward to remove my ’secret sauce’ in the deployment installer.

For internationalization, if all the developer’s machine are set to display ‘Japanese’ for non-Unicode programs, the daily problems in compiled programs will annoy them enough for them to fix it (even if the developer can read Japanese, the characters are still messed up for half of the times). If the developers assume users set the non-Unicode programs to display Japanese because they can read Japanese (bilingual), then I am hoping that at least if MCR chose to display Japanese error messages in the console, display it properly in Japanese code page. Of course, it’d be the best if English MATLAB consistently shows everything in English, in any OS.

For uitable, an apps engineer called (a long time ago) and promised to work on it, but I hadn’t heard back from anybody ever since. The request ID is 1-5Y36TS. Basically the uitable() in my compiled program displays blank until I refresh it again with something else, and that doesn’t happen to the full MATLAB. We can take this discussion offline for better nettiquette.

I feel MATLAB compiler can expand its territory a lot more. If Steve can have a blog on something as specific as Image processing, I certainly appreciate a blog on Application Deployment branch of MATLAB products, as they can be quite obscure and daunting and maybe a community can help promoting the product through more success cases.

Long-term, we certainly plan on further improving the quality of the MATLAB Compiler (and all of the Builder tools). I’m not sure exactly which bugs you’re referring to; I took a look in our list and didn’t find any mention of uitable, but I noticed several internationalization and COM bug fixes going into the next release, so perhaps we’ve already addressed some of your concerns.

I think the information in comment #9 might help you as well. If you compile using -C, and place the CTF archive in the same directory as the executable, then CTFROOT will return the directory containing the executable.

It’s like CTFROOT but for the EXE.
Do you know if it is possible to have that ?

Thanks a lot.

Best regards.

Even with the -C switch, the MCR still breaks my path structure as now /myProgram/core is extracted to /myProgram/myProgram_mcr/core, but it’s better than having it extracted to somewhere deep under ‘local settings’.

To shorten development time, I took a chance on MATLAB compiler when I decided to use MATLAB for a software project meant for distribution, and I found a bunch of things that ought to be right (DCOM, internationalization, single instances, uitable, paths, etc.) that wasn’t. I filed bug/enhancement requests for all of them, but it will take a long while before the developers actually do something about it.

I really hope Mathworks can invest more on developing MATLAB compiler to make it a more polished product. With cheap dual-core computers @1GB RAM minimum ready to run MCR, developing applications (especially GUI with data visualization features) using MATLAB is a competitive alternative to C#/Java.

You can exercise more control over where the encrypted files are installed via the Compiler’s -C switch or the MCR’s “component cache” environment variables.

The details: http://www.mathworks.com/access/helpdesk/help/toolbox/compiler/brl4_f1-1.html

If you place the CTF archive and the executable in the same directory at installation, then CTFROOT will return the directory containing the executable.

However, I still don’t like the idea of having MCR messing with the my path structures. This only adds unnecessary mental gymnastics to the programming task, hurting productivity.

If a programming language feature is clearly unintuitive to users like the MCR paths, it better has a good justification other ‘it’s easier to develop the compiler that way’.