Using MFC dll from non-MFC application
in [MFC]
|
From: JRGlide on 11 May 2008 12:22 "Scott McPhillips [MVP]" wrote: > "Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message > news:83264DC9-21F3-46F5-AE76-2D9C14D2F03B(a)microsoft.com... > > > > > >> The original problem is that I couldn't get the MFC dll to remain active. > >> It would become active for just a split second and then disappear. > > > > What does this mean? DLL is loaded in memory unless you unload it, its > > still there. > > > He moved an entire MFC application into the DLL and wants it to run as it > did before. I.e. he needs to run the MFC message pump in the DLL. Calling > Run is probably the way to do that, but I don't know about the problem on > Close that has caused. > > -- > Scott McPhillips [VC++ MVP] If I have to I can get around the problem by keeping it as an exe, but modify it to pass data through some sort of shared memory. This is assuming that I can access global shared memory through the non-MFC calling routine. I still need to read up on how to do that. It just seems like the dll approach should work... The original application was a viewer for 3D laser point cloud data using Open GL. I now want to allow other applications such as MATLAB or LabView to be able to call it directly. They may be passing millions of points (40-100 Meg of data, or more). I thought converting it to a dll was the best approach. Otherwise I have to write a wrapper for any other program that wants to use it, but maybe that is what I need to do. BTW, I've tried linking it both statically and dynamically. Dynamically it crashed when loading instead of closing! I also tried converting it to a non-Doc/View app and it also crashes.
From: David Ching on 11 May 2008 12:20 "JRGlide" <JRGlide(a)discussions.microsoft.com> wrote in message news:79B758A2-7217-4451-B36C-122A26B04179(a)microsoft.com... > >> > The original problem is that I couldn't get the MFC dll to remain >> > active. >> > It would become active for just a split second and then disappear. >> >> What does this mean? DLL is loaded in memory unless you unload it, its >> still there. > > > Here is the basic calling routine. (I'm actually trying to call it from a > MATLAB mex function which is a non_MFC dll. But this simplifies things > and > is what I use for testing.) > > > __declspec(dllimport) int ViewPointCloud (void); > > int main(int argc, char* argv[]) > { > ViewPointCloud(); > return 0; > } > > And this is the hook function in theApp: > > > __declspec(dllexport) void ViewPointCloud (void); > > void ViewPointCloud (void) > { > AFX_MANAGE_STATE (AfxGetStaticModuleState()); > } > > > So what happens is that the main function calls the hook function, > ViewPointCloud, which in turn invokes the dll as you said. But since the > hook function has nothing to wait on, it immediately returns to the main > calling routine which then exits, which I think causes the dll to unload > from > memory. I can't figure out how to get hook function to wait until the > user > is finished with the MFC program before returning, and unloading the dll. > I was going to suggest you do something like post a Windows message to the calling app in CMainFrame::OnClose(), then in the calling program receive the message and continue your processing, ON_MESSAGE(UWM_VIEWPOINTCLOUDDONE,OnViewPointCloudDone) but now you say the calling process is MatLab, which I don't think lets you receive Windows messages. Therefore, due to the limited nature of caller, I would encourage you to leave the functionality in the .exe, and just launch the .exe from MatLab. I'm pretty sure it has such a function that can wait until the .exe terminates before continuing. -- David
From: Scott McPhillips [MVP] on 11 May 2008 14:16 "JRGlide" <JRGlide(a)discussions.microsoft.com> wrote in message news:AFCA12E5-DC04-42E8-BFA3-70BCFD4A9DCF(a)microsoft.com... > If I have to I can get around the problem by keeping it as an exe, but > modify it to pass data through some sort of shared memory. This is > assuming > that I can access global shared memory through the non-MFC calling > routine. > I still need to read up on how to do that. It just seems like the dll > approach should work... > > The original application was a viewer for 3D laser point cloud data using > Open GL. I now want to allow other applications such as MATLAB or LabView > to > be able to call it directly. They may be passing millions of points > (40-100 > Meg of data, or more). I thought converting it to a dll was the best > approach. Otherwise I have to write a wrapper for any other program that > wants to use it, but maybe that is what I need to do. > > BTW, I've tried linking it both statically and dynamically. Dynamically > it > crashed when loading instead of closing! I also tried converting it to a > non-Doc/View app and it also crashes. Here's a suggestion you might want to try, either as a permanent solution or perhaps as an experiment to see what you can learn about the OnClose problem. You could create a new (MFC) thread in the call from Matlab. That's done by deriving a class from CWinThread and calling AfxBeginThread with the class name. The thread has an InitInstance, just like your original application did, and all of your windows etc. would run in the new thread if you put your original InitInstance code there. The call from Matlab would merely sit suspended in a WaitForSingleObject until the thread exits. The advantage is that this would get you out of undocumented territory, and it would start your thread and message pump (the Run function) using the normal MFC initialization code. -- Scott McPhillips [VC++ MVP]
From: David Ching on 11 May 2008 14:50 "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message news:%23V3juM5sIHA.5832(a)TK2MSFTNGP02.phx.gbl... > Here's a suggestion you might want to try, either as a permanent solution > or perhaps as an experiment to see what you can learn about the OnClose > problem. You could create a new (MFC) thread in the call from Matlab. > That's done by deriving a class from CWinThread and calling AfxBeginThread > with the class name. > > The thread has an InitInstance, just like your original application did, > and all of your windows etc. would run in the new thread if you put your > original InitInstance code there. The call from Matlab would merely sit > suspended in a WaitForSingleObject until the thread exits. The advantage > is that this would get you out of undocumented territory, and it would > start your thread and message pump (the Run function) using the normal MFC > initialization code. > It's a good idea to start the secondary thread to wait for the window to close. But I don't think it's proper behavior to call CWinApp::Run() from the 'hook' function. That seems plain wrong. It's already been called when the DLL was loaded and I've never seen it called again. So I would ditch the idea of calling CWinApp::Run(). But everything else sounds good. Just move everything that was in the CWinApp::InitInstance() to the CMyWinThread::InitInstance(), then start it in the hook function using AfxBeginThread(), then WaitForSingleObject() of that thread. The reason I suggested just executing the .exe was because there was no sign of any data passing anywhere. I guess that is done through other exported functions that haven't been shown. -- David
From: Joseph M. Newcomer on 11 May 2008 16:37
A DLL is a DLL. A .exe is a .exe. You can't magically convert one to the other. Generally, since matlab output can be made into a subroutine, I'd be more likely to write an MFC app that called a matlab subroutine, rather than a matlab application that called an MFC DLL that pretended to be an entire app. I have two clients right now who use matlab, one for signal processing and one for signal conditioning, and what they send me is matlab code in a DLL, which seems a lot more sensible as an approach. The advantage of doing the DLL is that if they tweak the algorithms, we can distribute new DLLs and everyone gets the tweak without any changes to the interface. It sounds to me like you are approaching the problem from the wrong direction. joe On Sun, 11 May 2008 09:22:00 -0700, JRGlide <JRGlide(a)discussions.microsoft.com> wrote: > >"Scott McPhillips [MVP]" wrote: > >> "Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message >> news:83264DC9-21F3-46F5-AE76-2D9C14D2F03B(a)microsoft.com... >> > >> > >> >> The original problem is that I couldn�t get the MFC dll to remain active. >> >> It would become active for just a split second and then disappear. >> > >> > What does this mean? DLL is loaded in memory unless you unload it, its >> > still there. >> >> >> He moved an entire MFC application into the DLL and wants it to run as it >> did before. I.e. he needs to run the MFC message pump in the DLL. Calling >> Run is probably the way to do that, but I don't know about the problem on >> Close that has caused. >> >> -- >> Scott McPhillips [VC++ MVP] > > >If I have to I can get around the problem by keeping it as an exe, but >modify it to pass data through some sort of shared memory. This is assuming >that I can access global shared memory through the non-MFC calling routine. >I still need to read up on how to do that. It just seems like the dll >approach should work... > >The original application was a viewer for 3D laser point cloud data using >Open GL. I now want to allow other applications such as MATLAB or LabView to >be able to call it directly. They may be passing millions of points (40-100 >Meg of data, or more). I thought converting it to a dll was the best >approach. Otherwise I have to write a wrapper for any other program that >wants to use it, but maybe that is what I need to do. > >BTW, I've tried linking it both statically and dynamically. Dynamically it >crashed when loading instead of closing! I also tried converting it to a >non-Doc/View app and it also crashes. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |