Prev: CIPAddressCtrl: focus handle
Next: How to embed a word document in CView
From: JRGlide on 23 Jun 2010 15:02
I currently have a MATLAB mex function that allows the user to view &
manipulate 3D point cloud data directly from MATLAB. A mex function is
nothing more than a standard dll with a specific MATLAB entry point. The
viewer was written in MFC using OpenGL.

My problem is that since it is a dll the user must close the viewer before
returning to MATLAB. In other words, the user calls the viewer from MATLAB,
looks at the data, closes the viewer and then returns to MATLAB.

I would like to find a way to keep the viewer up permanently so that it
works independently from MATLAB so they can both be run at once. What I
envision is that MATLAB would call another mex function (or dll) with the
data for display. This function would check to see if the viewer is active
and activate it if necessary. It would then pass the data to the viewer
using some sort of handshake and then return to MATLAB without the viewer
disappearing at it does now. If the user changed the data it would make the
same call and the dll would update the data in the viewer.

My question is that I'm not sure how to go about doing this:

1. I suspect that to do this, the viewer would need to be a regular
executable with some sort of interface and not a dll, but maybe I assume
wrong.

2. It would first have to know if the viewer is loaded or not and the load
it.

3. I'm not sure what the handshake would be between the mex function and
the viewer. The data could potentially be hundreds of megs in size. Is
there a way I can do that through shared memory or some sort of global memory
pool? I'm trying to keep from writing the data to disk and read it back
again. Having said that, if I have to limit the data size to say, less than
50 meg, I can live with that.

4. As far as closing the viewer, I guess that would be up to the user after
they are finished, just like any other application.

Thank you for your help.

From: Scott McPhillips [MVP] on 23 Jun 2010 15:32
"JRGlide" <JRGlide(a)discussions.microsoft.com> wrote in message
news:75C5F17D-92D6-465A-97DE-50B741907E58(a)microsoft.com...
>I currently have a MATLAB mex function that allows the user to view &
> manipulate 3D point cloud data directly from MATLAB. A mex function is
> nothing more than a standard dll with a specific MATLAB entry point. The
> viewer was written in MFC using OpenGL.
>
> My problem is that since it is a dll the user must close the viewer before
> returning to MATLAB. In other words, the user calls the viewer from
> MATLAB,
> looks at the data, closes the viewer and then returns to MATLAB.
>
> I would like to find a way to keep the viewer up permanently so that it
> works independently from MATLAB so they can both be run at once. What I
> envision is that MATLAB would call another mex function (or dll) with the
> data for display. This function would check to see if the viewer is
> active
> and activate it if necessary. It would then pass the data to the viewer
> using some sort of handshake and then return to MATLAB without the viewer
> disappearing at it does now. If the user changed the data it would make
> the
> same call and the dll would update the data in the viewer.
>
> My question is that I'm not sure how to go about doing this:
>
> 1. I suspect that to do this, the viewer would need to be a regular
> executable with some sort of interface and not a dll, but maybe I assume
> wrong.

The viewer would need to be a exe program if it is expected to continue
running after Matlab closes, or after Matlab unloads the mex.

>
> 2. It would first have to know if the viewer is loaded or not and the
> load
> it.

Named mutex and named events can be used for interprocess state indications.
The exe uses CreateMutex, the mex uses WaitForSingleObject (with a 0
timeout) to determine if the mutex currently exists.


> 3. I'm not sure what the handshake would be between the mex function and
> the viewer. The data could potentially be hundreds of megs in size. Is
> there a way I can do that through shared memory or some sort of global
> memory
> pool? I'm trying to keep from writing the data to disk and read it back
> again. Having said that, if I have to limit the data size to say, less
> than
> 50 meg, I can live with that.

Shared memory (even to 100s of MB) is practical. See CreateFileMapping and
MapViewOfFile. The mex would have to copy the data into the shared region,
then notify the exe there is a new data set. The notify could take many
forms, including SetEvent/WaitForSingleObject, or PostMessage to an HWND
that the exe places into the shared memory.

>
> 4. As far as closing the viewer, I guess that would be up to the user
> after
> they are finished, just like any other application.
>
> Thank you for your help.
>

--
Scott McPhillips [VC++ MVP]

From: David Ching on 23 Jun 2010 15:37
It sounds like MATLAB loads your DLL and calls an exported function which
shows the 3D window. And when user closes the window, only then does the
exported function return to MABLAB. So MATLAB waits for your exported
function to return before allowing any more interaction with the main MATALB
window.

If so, why don't you alter your exported function to create a new thread
that shows the 3D window and returns immediately? Then MATLAB and the 3D
window function simultaneously. The next time MATLAB calls your exported
function, you check if the thread/3D window already appear and pass the new
graph data to the window, if so.

-- David


"JRGlide" <JRGlide(a)discussions.microsoft.com> wrote in message
news:75C5F17D-92D6-465A-97DE-50B741907E58(a)microsoft.com...
> I currently have a MATLAB mex function that allows the user to view &
> manipulate 3D point cloud data directly from MATLAB. A mex function is
> nothing more than a standard dll with a specific MATLAB entry point. The
> viewer was written in MFC using OpenGL.
>
> My problem is that since it is a dll the user must close the viewer before
> returning to MATLAB. In other words, the user calls the viewer from
> MATLAB,
> looks at the data, closes the viewer and then returns to MATLAB.
>
> I would like to find a way to keep the viewer up permanently so that it
> works independently from MATLAB so they can both be run at once. What I
> envision is that MATLAB would call another mex function (or dll) with the
> data for display. This function would check to see if the viewer is
> active
> and activate it if necessary. It would then pass the data to the viewer
> using some sort of handshake and then return to MATLAB without the viewer
> disappearing at it does now. If the user changed the data it would make
> the
> same call and the dll would update the data in the viewer.
>
> My question is that I'm not sure how to go about doing this:
>
> 1. I suspect that to do this, the viewer would need to be a regular
> executable with some sort of interface and not a dll, but maybe I assume
> wrong.
>
> 2. It would first have to know if the viewer is loaded or not and the
> load
> it.
>
> 3. I'm not sure what the handshake would be between the mex function and
> the viewer. The data could potentially be hundreds of megs in size. Is
> there a way I can do that through shared memory or some sort of global
> memory
> pool? I'm trying to keep from writing the data to disk and read it back
> again. Having said that, if I have to limit the data size to say, less
> than
> 50 meg, I can live with that.
>
> 4. As far as closing the viewer, I guess that would be up to the user
> after
> they are finished, just like any other application.
>
> Thank you for your help.
>



From: Joseph M. Newcomer on 23 Jun 2010 15:53
See below..
On Wed, 23 Jun 2010 12:02:05 -0700, JRGlide <JRGlide(a)discussions.microsoft.com> wrote:

>I currently have a MATLAB mex function that allows the user to view &
>manipulate 3D point cloud data directly from MATLAB. A mex function is
>nothing more than a standard dll with a specific MATLAB entry point. The
>viewer was written in MFC using OpenGL.
>
>My problem is that since it is a dll the user must close the viewer before
>returning to MATLAB. In other words, the user calls the viewer from MATLAB,
>looks at the data, closes the viewer and then returns to MATLAB.
****
You are confusing unload the DLL and closing the viewer. It is not at all clear that
closing the viewer unloads the DLL (alhtough it might) or that the state of the DLL even
matters.

What you are complaining about here is the specified MATLAB interface, which has the
specification "create a viewer, and upon completion, close the view", and you have to take
that up with the MATLAB folks. It is NOT an MFC issue, or a DLL issue. It is how they
have required the interface to behave.
****
>
>I would like to find a way to keep the viewer up permanently so that it
>works independently from MATLAB so they can both be run at once. What I
>envision is that MATLAB would call another mex function (or dll) with the
>data for display. This function would check to see if the viewer is active
>and activate it if necessary.
****
This sounds like you want to build an out-of-process ActiveX server. Feel Free.
****
>It would then pass the data to the viewer
>using some sort of handshake and then return to MATLAB without the viewer
>disappearing at it does now. If the user changed the data it would make the
>same call and the dll would update the data in the viewer.
****
Getting MATLAB to pass new data in is a MATLAB issue. What you do with the data after you
receive it is up to you.
****
>
>My question is that I�m not sure how to go about doing this:
****
In the simplest case:
Your MATLAB plugin looks for an existing process
If the existing process does not exist, CreateProcess
Send data to the process
return

How you detect and send is up to you. I'd probably use a named pipe. But it really
depends on the format of the data, such as, can it be sent across a communication channel
(of any nature) and retain its meaning? A data structure full of pointers requires a lot
more work than one which is tuples of integers (e.g., vertex points), and in between all
is negotiable.
****
>
>1. I suspect that to do this, the viewer would need to be a regular
>executable with some sort of interface and not a dll, but maybe I assume
>wrong.
****
That would be the first and best choice. Note that your viewer might have a DLL, and in
the extreme case, it might share a DLL with the MATLAB plug-in to provide a communication
channel (e.g., by shared memory), but that is a mere implementation detail.
****
>
>2. It would first have to know if the viewer is loaded or not and the load
>it.
****
Lots of ways. But the best way depends a lot on the nature of how you need to pass
information. For example, I might use a SendMessageTimeout(HWND_BROADCAST,
(WPARAM)m_hWnd)

to tell anyone who is listening that I have data to send it, and if I don't get a response
in a few hundred milliseconds, I will assume the app is not running. Or I might try to
open a named pipe. I might do EnumProcesses (although I would consider than the least
likely implementation I'd choose). I might have an invisible top-level window which
receives HWND_BROADCAST messages, and if it has a NULL handle I know the other app isn't
up, and if it has an HWND it is the HWND of the other app, to which I can use WM_COPYDATA.
The choices are numerous, but without knowing anything about the nature of the data, it is
hard to guess which one would be the better choice. I'd start with the idea of a named
pipe and work with that unless I found a reason it was not a good idea. For example, if I
need to pass megabytes of data, it would not be a particularly good choice. Then I might
choose a memory-mapped file approach.
****
>
>3. I�m not sure what the handshake would be between the mex function and
>the viewer. The data could potentially be hundreds of megs in size. Is
>there a way I can do that through shared memory or some sort of global memory
>pool? I�m trying to keep from writing the data to disk and read it back
>again. Having said that, if I have to limit the data size to say, less than
>50 meg, I can live with that.
****
Hundreds of megabytes gets interesting. A memory-mapped file MIGHT work, but you are
pushing the limits here. The nature of the data is also important. An ordinary file
might work just as well. To use a memory-mapped file effectively
(a) the data may not contain pointers (except based pointers)
(b) both processes must have enough address space to hold the mapping

That said, you can create piecewise "views" of a memory mapped file, and you only need
enough address space to hold the view, but you need a lot more effort to deal with writing
the mapped file through multiple views, and you probably need another IPC mechanism (named
pipe, window message, named event) to indicate the view is valid. You must also ensure
that you are not changing the view when the app is displaying it, so you have to be able
to tell the app to stop using the view data until told it is now good again, and in all of
this I favor inter-process PostMessage calls.
>
>4. As far as closing the viewer, I guess that would be up to the user after
>they are finished, just like any other application.
****
Or you can have a DLL_PROCESS_DETACH that does a PostMessage to indicate that the DLL Is
closing; this works only if MATLAB only loads the DLL once and doesn't unload it until
MATLAB exits, so that's a MATLAB question.

In addition, you can have your process PostMessage its process ID to the viewer; the
viewer does an OpenProcess, then WFSO on the process handle, and when the process handle
becomes signaled, it knows that MATLAB has terminated. This will work correctly even if
the DLL is unloaded each time, as long as you don't create a new watcher thread in your
viewer each time MATLAB reloads the DLL (not hard, just see if the process ID you have is
already in use as a target [via its handle from OpenProcess])
joe
****
>
>Thank you for your help.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: JRGlide on 23 Jun 2010 16:42
Thank you. You are right that MATLAB loads a DLL and then calls another DLL
which displays the data. In case it matters, the viewing program is an
application that I converted into a DLL, so it has its own CWinApp, menus,
CView, etc. In fact, you may have been the one who helped me develop it
several years ago.

My question about your approach is that I alway read on this forum that the
GUI should always be in the application and never in a thread - that only
processing should be done is a separate thread. So why is this different?


"David Ching" wrote:

> It sounds like MATLAB loads your DLL and calls an exported function which
> shows the 3D window. And when user closes the window, only then does the
> exported function return to MABLAB. So MATLAB waits for your exported
> function to return before allowing any more interaction with the main MATALB
> window.
>
> If so, why don't you alter your exported function to create a new thread
> that shows the 3D window and returns immediately? Then MATLAB and the 3D
> window function simultaneously. The next time MATLAB calls your exported
> function, you check if the thread/3D window already appear and pass the new
> graph data to the window, if so.
>
> -- David
>
>
> "JRGlide" <JRGlide(a)discussions.microsoft.com> wrote in message
> news:75C5F17D-92D6-465A-97DE-50B741907E58(a)microsoft.com...
> > I currently have a MATLAB mex function that allows the user to view &
> > manipulate 3D point cloud data directly from MATLAB. A mex function is
> > nothing more than a standard dll with a specific MATLAB entry point. The
> > viewer was written in MFC using OpenGL.
> >
> > My problem is that since it is a dll the user must close the viewer before
> > returning to MATLAB. In other words, the user calls the viewer from
> > MATLAB,
> > looks at the data, closes the viewer and then returns to MATLAB.
> >
> > I would like to find a way to keep the viewer up permanently so that it
> > works independently from MATLAB so they can both be run at once. What I
> > envision is that MATLAB would call another mex function (or dll) with the
> > data for display. This function would check to see if the viewer is
> > active
> > and activate it if necessary. It would then pass the data to the viewer
> > using some sort of handshake and then return to MATLAB without the viewer
> > disappearing at it does now. If the user changed the data it would make
> > the
> > same call and the dll would update the data in the viewer.
> >
> > My question is that I'm not sure how to go about doing this:
> >
> > 1. I suspect that to do this, the viewer would need to be a regular
> > executable with some sort of interface and not a dll, but maybe I assume
> > wrong.
> >
> > 2. It would first have to know if the viewer is loaded or not and the
> > load
> > it.
> >
> > 3. I'm not sure what the handshake would be between the mex function and
> > the viewer. The data could potentially be hundreds of megs in size. Is
> > there a way I can do that through shared memory or some sort of global
> > memory
> > pool? I'm trying to keep from writing the data to disk and read it back
> > again. Having said that, if I have to limit the data size to say, less
> > than
> > 50 meg, I can live with that.
> >
> > 4. As far as closing the viewer, I guess that would be up to the user
> > after
> > they are finished, just like any other application.
> >
> > Thank you for your help.
> >
>
>
>
 |  Next  |  Last
Pages: 1 2 3
Prev: CIPAddressCtrl: focus handle
Next: How to embed a word document in CView