C / C++ / MFC

10-Nov-03 16:06

I may have programmed myself into a corner, anyways here is my situation.

I have a full screen dialog based application that serves as a menu.

Note: The main application and the plugins are all drawn using GDI+ so
I am not forced to use a dialog base application, but it happens
to be the direction I choose.

The menu has buttons which can:
a) start a dialog based dll b) Run an executable c) Execute a command

My intension was that this application would:

1) Act as a menu.
2) Watch for keyboard presses and send a message to plugins stating which key was pressed.
3) Watch for UIR (remote control) commands and send a message to the plugins stating commands
received.
4) It was not my intention to have each dll do #2 nor #3

Problem:

1) When I start a plugin from the menu application it no longer does anything. I placed a timer which fired every 4 seconds calling the MessageBeep(..) function and it was not called while the plugins dialog was active. So, it seems that there is no persistance when using dialogs the way I am using them.

Question:

How do I get around this problem? I want the main application to work as I have described above.

I am open to complete redesign or whatever options or opinions anyone might have.

Thanks,

Steve

Antti Keskinen11-Nov-03 11:21

11-Nov-03 11:21

I'll try to approach this problem from a perspective more closer to mine.

So, let's formulate that you have a standard Windows application, with a dialog as a main window. Okay, your application now loads two DLLs into it's address space. After these DLLs are loaded, you need to use GetProcAddress to get an address of an exported function, which you can then call from your application.. Correct ? No ?

Are your plugins supposed to act as little programs of their own ? Then you need to create a new thread and post the function to execute on that thread for the thread creator. For example, the Kernel creates a thread and specifies your 'WinMain' function to execute there. You can do the same: get the exported (worker) function from the DLL, and use it's address to start a new thread. Your function, then, can do anything it wants from just returning 'SUCCESS' to starting a message pump and creating a window. This is called multi-threading application, and is something I don't know much of. I've never needed it so far Smile | :)

You said that the plugins are represented as dialogs. So, let's assume you define a class for this dialog, a derived CDialog, for example. Then, you declare a global object in the 'DllMain', and use 'GetProcAddress' to get the address of an exported function, which does nothing more than return the address of this global object.

Here's the general flow chart:

Application XYZ starts -> App maps a DLL using LoadLibrary -> The DLLs DllMain routine creates a dynamic/static CMyDialog object -> The app uses GetProcAddress to get an exported function from the DLL and calls it -> This function returns the address of this object

App can now, in combination with the header file of the object, call dialog's member functions (Create / DoModal) and start it. Make it modal, specify your application window as parent, and vot, you got yourself an ordinary dialog Smile | :)

I believe using MFC classes this way requires a bit more thought, though, but this is the general idea. I am unsure how it works, look up MSDN for more help.

On the alternative, you can use the multi-threaded solution to create seperate threads for your plugin dialogs (Like, small applications with dialog as main window), then use SendMessage to send messages to these windows.

If this is not the idea you're after, then could you clarify more of your ideas. What is it that your plugins need to do ? Why are they placed in external DLL plugins ? Why just not objects inside your main application class ?

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

Steve Messer11-Nov-03 18:05

11-Nov-03 18:05

Antti Keskinen wrote:
So, let's formulate that you have a standard Windows application, with a dialog as a main window. Okay, your application now loads two DLLs into it's address space. After these DLLs are loaded, you need to use GetProcAddress to get an address of an exported function, which you can then call from your application.. Correct ? No ?

Correct.

Antti Keskinen wrote:
Are your plugins supposed to act as little programs of their own ?

Well, yes they are intended to act as their own little program as well as receive messages from the parent application. ( like I mentioned key presses and remote control presses )

Antti Keskinen wrote:
Then you need to create a new thread and post the function to execute on that thread for the thread creator. For example, the Kernel creates a thread and specifies your 'WinMain' function to execute there. You can do the same: get the exported (worker) function from the DLL, and use it's address to start a new thread. Your function, then, can do anything it wants from just returning 'SUCCESS' to starting a message pump and creating a window.

What if I where to use a modeless dialog with a callback function. I could process messages that way or I could use the SendMessage interface I added to my plugin interface. My problem is that when the dialog in the dll comes up Modal then it stops any processing from the parent application.

Antti Keskinen wrote:
If this is not the idea you're after, then could you clarify more of your ideas. What is it that your plugins need to do ?

The plugins can do anything. The plugin I am currently testing with gets the current weather from the internet and displays it. The dialog has buttons for refreshing and returning to the main application. This would be done by remote control. You select for example the back button which would cause the main application to send an ENTER command to the plugin. Well, this is my intention anyways.

Antti Keskinen wrote:
Why are they placed in external DLL plugins ? Why just not objects inside your main application class ?

They are external because I want people to be able to write their own plugins given a dll template project. I want to application to be completely customizible and I don't want to give out all my source code just so someone can add desired functionality.

Hope that all makes sense. Thanks for your response.

Steve

Antti Keskinen12-Nov-03 8:25

12-Nov-03 8:25

smesser wrote:
What if I where to use a modeless dialog with a callback function. I could process messages that way or I could use the SendMessage interface I added to my plugin interface. My problem is that when the dialog in the dll comes up Modal then it stops any processing from the parent application.

The plugins can do anything. The plugin I am currently testing with gets the current weather from the internet and displays it. The dialog has buttons for refreshing and returning to the main application. This would be done by remote control. You select for example the back button which would cause the main application to send an ENTER command to the plugin. Well, this is my intention anyways.

Upon reviewing your original post again I saw a possible problem in your implementation: did you remember to start the message pump for the dialog when you created it ? A thread without a message pump can create a dialog, but the dialog won't do anything.

If you use MFC for the dialogs (CDialog derivance), see AfxLoadLibrary MSDN entry for an easy example on how to create the main application's portion of the code. There is an example (In MSDN Library April 2003), which loads a DLL, gets a CView-derived class's runtime info using an exported function, and creates a new document template based on the value returned by the function.

The Dll side would consist of your class definition (.h), and an implementation file. This implementation file has two requisities: it creates an object of the class on it's global level, that is, NOT inside DllMain. Also, it must export a function to return the address of the object.
Or if you would like to use the AfxLoadLibrary example straight on, the exported function would result a RUNTIME_CLASS( Your class name here )

You can use the same approach to pass out any type of class information, even a ready object, if you so please. I am not sure whether the AfxLoadLibrary creates a new thread upon which DllMain of the loaded library executes. In that case, you must be very careful when specifying the main application window as the parent, as inter-thread information may easily become corrupted :I

And yeah, use AfxLoadLibrary instead of LoadLibrary. The MFC version makes sure that main application data is not corrupted.

If you can't get it to work, you can download a small MFC application I made. It uses a DLL to create a dialog and then runs that dialog. See it's source file 'CLoaderApp' for a full description of it's soul life.

Here's a link: www.tpu.fi/~t1akeski/MFC_goes_DLL.zip[^]

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible., for example.

Steve Messer12-Nov-03 12:07

12-Nov-03 12:07

Thanks for the example but I am not sure how much it relates to my project in VC++ 6.

Antti Keskinen wrote:
Upon reviewing your original post again I saw a possible problem in your implementation: did you remember to start the message pump for the dialog when you created it ? A thread without a message pump can create a dialog, but the dialog won't do anything.

In my project the Loader as in your example has a dialog and is a full application.
So, I am not sure I see the relevance of starting the message pump manually. In my project 
the main application starts the dll and has a function for sending messages. I can also 
override the DefWindowProc() to catch messages that maybe sent to it's window.

The dialog in my dll does not have problems doing anything. It works fine, 
it just is blocking the main application from telling it anything.

My original problem was not getting the dialog in the dll to work it was getting it to not block the processing of the main application. It was doing so because the dialog in the dll was Modal.

In the mean time I have changed the dialog in my dll to a modeless dialog and it is no longer blocking the processing of the main application.

I either don't understand your answer or we are not trying to solve the same problem.

Are you saying that the thread in my dll needs a message pump? I am not using any threads.

Sorry for being so dense.

Steve

Antti Keskinen13-Nov-03 0:44

13-Nov-03 0:44

It seems there has been a misunderstanding when I readed your first message. My apologies.

When you use AfxLoadLibrary to map a DLL to the address space, it's DllMain (Or if you use MFC, it's CWinApp-derived object's InitInstance) gets executed on a seperate thread. This is a feature of AfxLoadLibrary, but I don't believe it will pose a problem.

It, however, means that you cannot pass C++ CWnd or CDialog objects (or their addresses) from the DLL to the main application. This will cause an assertion in the debug version of MFC, and most obviously, a crash in the release version.
You CAN pass the HWND of the dialog, if you need to post messages to it, or alternatively, create an exported function (from the DLL) to send the messages. Afterall, the function you export gets called within the DLL's thread, as you use GetProcAddress to get a POINTER to that function, which you then call from the main application.

Like said, if you export a function from the DLL which returns the HWND of the dialog, you can use this HWND to pass messages to the dialog. However, you can not return the address of the CWnd/CDialog object from the DLL. This violates the above-mentioned object sharing aspect.

The reason why I used custom message pumping in my application was because my application did not have a main window at all. MFC is designed to shut the thread down if, after the execution of InitInstance returning TRUE, the m_pMainWnd member of CWinApp is NULL.

I could've created my own dialog for the example application: I just didn't feel it necessary. Otherwise, your and my app work similarly. Both load a DLL, both create a dialog in that DLL. My case just is that I am force-running the thread to prevent framework from shutting it down before I want it to.

But, like you said, the problem is solved after you changed the plugin dialog to modeless. Good luck for the future development of the app, and feel free to ask if you run into any more problems Smile | :)

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

Steve Messer13-Nov-03 1:35

13-Nov-03 1:35

No apologies necessary. I learned from our discussion and appreciate your time and effort and your example. After all you were the only one to respond so again I say thanks. This does not seem to be an area that most people have a lot of experience with. I know that it has been eye opening experience for me.

One final question though, you mentioned that:
Antti Keskinen wrote:
It, however, means that you cannot pass C++ CWnd or CDialog objects (or their addresses) from the DLL to the main application. This will cause an assertion in the debug version of MFC, and most obviously, a crash in the release version.

Since I am not currently using AfxLoadLibrary could I if I wanted pass a CWnd handle of my dll back to the main application? I am not clear on that point.

- Steve Messer

Antti Keskinen13-Nov-03 5:17

13-Nov-03 5:17

In short, you can pass the HWND of the Windows object bound to a CWnd from the DLL back to the main application. This is legal. Now for some explanation:

I ran into a strange problem while creating the example app, and when debugging, my application fired an assertion as I created the CDialog in the DLL and then passed the active C++ object's address to the main application. Here, the term "active" refers to an MFC object means that is bound to an existing Windows window/GDI/whatever object. An "inactive" object would be one that has not had it's 'Create' method (or any other initialization method) called.

Here is an exerpt from wincore.cpp, a MFC source file which defines the behaviour of CWnd::AssertValid, among other things.

C++

    ASSERT((p = pMap->LookupPermanent(m_hWnd)) != NULL ||
	   (p = pMap->LookupTemporary(m_hWnd)) != NULL);
    ASSERT((CWnd*)p == this);   // must be us
<DIV>
    // Note: if either of the above asserts fire and you are
    // writing a multithreaded application, it is likely that
    // you have passed a C++ object from one thread to another
    // and have used that object in a way that was not intended.
    // (only simple inline wrapper functions should be used)
    //
    // In general, CWnd objects should be passed by HWND from
    // one thread to another.  The receiving thread can wrap
    // the HWND with a CWnd object by using CWnd::FromHandle.
    //
    // It is dangerous to pass C++ objects from one thread to
    // another, unless the objects are designed to be used in
    // such a manner.
</DIV>

So, like you see on the commented lines, passing the addresses of created C++ objects from one thread to another is a dangerous business, especially if the object is bound to a Windows GDI object already.

The reasons for this are in the core functionality of the MFC. Like you might already know, MFC is just a (huge) collection C++-based classes, which encapsulate the functionality of the major Windows base services (Windows, pens, brushes, DCs, sockets and so on). This is why it is so difficult for most people to make the difference between MFC and the Windows API.

Building on this theory, you now understand why the passing of an active CWnd object's address is dangerous: the object itself is created on a seperate thread, and if you call it's methods, they are executed in the context of the seperate thread as well. The Windows window object bound to the CWnd exists on the seperate thread as well. So, if you were to use the DLL's existing, active CWnd object's address or a reference to it in order to construct a new CWnd object in the main application, you would most likely be greeted by an access violation. Cross-thread communication is very vulnerable to causing those. However, you can store the object's address and call it's methods through a pointer. This is completely fine and legal Smile | :)

Alternatively, you can always use a simple HWND variable in the main application, and use Windows API's SendMessage to post messages to that HWND.
Just create an exported function to the DLL which returns the HWND of the Windows window bound to the CDialog/CWnd object in question. Then call this function through a pointer from the main thread, and vot, you have the HWND.

MFC Reference, however, cautions us from binding two CWnd objects to a same HWND handle, as this may result in serious implications if one of the object is destroyed while the other is still attached to the Windows window object. The destructor of CWnd, by default, attempts to destroy the underlying Windows window object as well. So, if you pass the HWND, use the API's SendMessage to send your message to the window. Do not wrap the HWND into a new CWnd object.

The most safest way is to use pointers. Cross-thread pointers are a very safe way to exchange information between two (or more) threads.

-Antti Keskinen

----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.

Steve Messer13-Nov-03 7:18

OnGridEndEdit and MessageBox

13-Nov-03 7:18

Very informative I am sure your information will save me hours of headaches in the future.

Thanks,

-Steve Messer

adonisv10-Nov-03 12:48

adonisv

10-Nov-03 12:48

I'm throwing up a message box inside the OnGridEndEdit function of a CGridCtrl object. I want to inform the user that a duplicate name has been entered and a unique one must be supplied. However, after the message box is clicked on, the cursor highlights cells in the grid control and its a wierd side effect. Any suggestions?

Here is the code:

<br />
void RDialogForEditingCanalObjects::OnGridEndEdit(NMHDR *pNotifyStruct,LRESULT* pResult)<br />
{<br />
	bool bAcceptChange = false;<br />
	CGridCellBase* pRow = NULL;<br />
<br />
    NM_GRIDVIEW* pItem = (NM_GRIDVIEW*) pNotifyStruct;<br />
<br />
	if (this->m_eCanalObjectType != CO_SSFC) <br />
	{<br />
		<br />
		if (pItem->iRow == 1 && pItem->iColumn == 1)<br />
		{<br />
			<br />
			pRow = this->m_PrimaryGrid.GetCell(pItem->iRow,pItem->iColumn);<br />
			<br />
			if (pRow) <br />
			{<br />
				switch(this->m_pCanMan->IsNameUnique(pRow->GetText())) {<br />
				case 0:<br />
					Beep(999,189);<br />
					Beep(999,189);<br />
					MessageBox("Please enter a unique name for this object",<br />
					"Duplicate Naming Error!",MB_OK);<br />
					bAcceptChange = FALSE;<br />
					<br />
					break;<br />
				case 1:<br />
					bAcceptChange = TRUE;<br />
					break;<br />
				}	<br />
				<br />
			}<br />
		}<br />
	}   <br />
}<br />

FILETIME compilation error

rmnowick10-Nov-03 12:31

rmnowick

10-Nov-03 12:31

All,
I am trying to compile some code that uses the FILETIME structure. When I try and compile it I get the following error message:

c:\Documents and Settings\Me\My Documents\my projects\CPP Projects\First Project\Hello World Proj\Form1.h(27) : error C2872: 'FILETIME' : ambiguous symbol
could be 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\WinDef.h(354) : _FILETIME FILETIME'
or 'stdafx.cpp(0) : System::Runtime::InteropServices::FILETIME'

It appears that there are two different declarations for FILETIME. When you search the MSDN Library for just "FILETIME" it tells you to just include windows.h. If you search the MSDN Library for "about FILETIME structure" it says that it is located in the namespace system.runtime.interopservices. I should mention that I have both an include of windows.h and a line for:

using namespace System::Runtime::InteropServices

If I comment out the using namespace line in order to fix the error I get a profusion of different errors because I use message boxes and apparently they need that namespace definition.

c:\Documents and Settings\me\My Documents\my projects\CPP Projects\First Project\Hello World Proj\Form1.h(208) : error C2653: 'MessageBoxA' : is not a class or namespace name

Thanks in advance for any ideas,
Robert

Re: FILETIME compilation error

Dave Bryant10-Nov-03 14:04

Dave Bryant

10-Nov-03 14:04

Here's two options:

1) Qualify FILETIME as being in the global namespace as: ::FILETIME, so that the compiler knows you are not refering to the one in System::Runtime::InteropServices.

2) Instead of importing the entire InteropServices namespace, either qualify them explicitly, or just include the classes that you actually need (e.g. using System::Runtime::InteropServices::Blah).

Dave
http://www.cloudsofheaven.org

How to change a toolbar bitmap image?

ElizabethC10-Nov-03 11:08

ElizabethC

10-Nov-03 11:08

I want to change a toolbar bitmap image Inbox to a different bitmap (or a bitmap with a very different color background) when there are messages in the Inbox. Or some way to give the user an alert that there are new messages in the Inbox. Can this be done?

Elizabeth

Roger Allen11-Nov-03 0:40

Roger Allen

11-Nov-03 0:40

One quick method would be to have two cpies of the same toolbar in your resources which have the same buttons, but one has a different image. When you need to switch bitmaps, you just call pToolbar->LoadToolbar() with the correct resource id for the correct images you want.

I do somehing similar in an app of mine to switch between small/large icons and it works fine.

Roger Allen
Sonork 100.10016

Death come early, death come late,
It takes us all, there is no reason.
For every purpose under heaven,
To each a turn, to each a season.
A time to weep and a time to sigh,
A time to laugh and a time to cry,
A time to be born and a time to die.
Dust to dust and ashes to ashes,
And so I end my song.

ElizabethC12-Nov-03 6:47

ElizabethC

12-Nov-03 6:47

I tried out your method. However, the toolbar flashes whenever the mouse is over it. I had LoadToolBar() at ON_UPDATE_COMMAND_UI(ID_INBOX, OnUpdateInbox). The flashing is very annoying.

Elizabeth

Roger Allen12-Nov-03 6:49

Roger Allen

12-Nov-03 6:49

It sounds like you just need to add a small amount of extra processing that only calls LoadToolbar() when a change in the button state is required. That should remove the flashing in the ON_UPADTE() handler.

Roger Allen - Sonork 100.10016
If your dead and reading this, then you have no life!