Thread Subject:

Shell to Stand-alone Matlab application from VB

Dear all:

It is a long question, please bear with me.

My question is how to "automatically" locate the installed path when I
shell to a stand-alone Matlab application from VB.

My program includes a VB interface and a Matlab stand-alone
application, i.e, an exe file, which is compiled by Matlab Graphics
Library. What the VB interface does is to send the user-input to some
temporary files and shell to the Matlab exe file; the Matlab exe file
should read those temporary files and return a figure.

Everything works fine now. However, if I want to distribute my
program to users, I have to let the Matlab exe file automatically find
its installed path.

In VB, I can do so by using "AppPath". In Matlab, "which" command is
not supported by Matlab Graphics Library. I also tried "cd" command
and it works when I create the exe file and run it. Nevertheless,
when I use VB to shell to the compiled exe file, the exe file fails to
recognize the path.

For example,
VB code is:
Dim value As Integer
value=1
Open AppPath() & "\test.txt" For Output As #1
Print #1, value
Shell (AppPath() & "\test.exe", vbNormalFocus)

Matlab code (it is compiled to test.exe) is:
path=[cd];
fid1=fopen([path,'\test.txt'],'r');
X=fgetl(fid1)

Say, if users install the program (both VB and Matlab exe file) in
C:\temp\, I have to "hardcode" the path in the Matlab code like
path=['C:\temp'];
fid1=fopen([path,'\test.txt'],'r');
X=fgetl(fid1)

Is there any other way to let Matlab find its installed path?

THANK YOU SO MUCH~~
     

Kevin,

No doubt you've tried and it doesn't work, but 1's and 0's are cheap
today: If your VB code and matlab .exe are in the same directory, do you
even need to specify the installed path? Can't you just:

fopen('test.txt','r')

-Chris

Kevin Yang wrote:

> Dear all:
>
> It is a long question, please bear with me.
>
> My question is how to "automatically" locate the installed path when I
> shell to a stand-alone Matlab application from VB.
>
> My program includes a VB interface and a Matlab stand-alone
> application, i.e, an exe file, which is compiled by Matlab Graphics
> Library. What the VB interface does is to send the user-input to some
> temporary files and shell to the Matlab exe file; the Matlab exe file
> should read those temporary files and return a figure.
>
> Everything works fine now. However, if I want to distribute my
> program to users, I have to let the Matlab exe file automatically find
> its installed path.
>
> In VB, I can do so by using "AppPath". In Matlab, "which" command is
> not supported by Matlab Graphics Library. I also tried "cd" command
> and it works when I create the exe file and run it. Nevertheless,
> when I use VB to shell to the compiled exe file, the exe file fails to
> recognize the path.
>
> For example,
> VB code is:
> Dim value As Integer
> value=1
> Open AppPath() & "\test.txt" For Output As #1
> Print #1, value
> Shell (AppPath() & "\test.exe", vbNormalFocus)
>
> Matlab code (it is compiled to test.exe) is:
> path=[cd];
> fid1=fopen([path,'\test.txt'],'r');
> X=fgetl(fid1)
>
> Say, if users install the program (both VB and Matlab exe file) in
> C:\temp\, I have to "hardcode" the path in the Matlab code like
> path=['C:\temp'];
> fid1=fopen([path,'\test.txt'],'r');
> X=fgetl(fid1)
>
> Is there any other way to let Matlab find its installed path?
>
> THANK YOU SO MUCH~~
>

cem48105@yahoo.com (Kevin Yang) writes:

> I have tried to use
> fid=fopen('test.txt','r')
> Unfortunately, it does not seem to work.

Where does it not work? In Matlab? Or in the application that
contains this code?

Peter

--
disp(char(size(ones(74,85,83,84,0,65,78,79,84,72,...
69,82,0,77,65,84,76,65,66,0,72,65,67,75,69,82))+32))

For text files, you should use 'rt'. Don't know if this is the
problem though.

Jason

Kevin Yang wrote:
>
> I have tried to use
> fid=fopen('test.txt','r')
> Unfortunately, it does not seem to work.
>
> I can run the exe file (the applicatiob created by Matlab compiler)
> but when I tried to shell to the exe file from VB, things went bad...
>
> Sigh, any other suggestion?
>
> Thanks...