Probably MFC tries to delete your CFrameWnd on application exit, but you have allocated it on the stack. MFC expects that frame windows are 'automatically allocated' by the framework, as they are when you use the 'normal' MDI/SDI approach with the wizards. They get automatically deleted when the application shuts down. Therefore, if you create a CFrameWnd manually, you have to allocate it via new and must not delete it on application exit. The framework does this for you... This is one of the more obscure "features" of MFC, for which I never found any documentation... Hope this helps, Nick EDIT: some typos

Well, the most simple way is to move all 'exported' functionality (i.e. that part of the application the plugins should be able to access) into a separate dll itself. Plugins then just need to link to that dll in order to use them, as does the main application. (This would most likely be done via implicit linkage) That way you also have enforced a modular concept for your application, which I'd recommend anyway as soon as your appication gets complex. Many of my bigger projects evolved to a main exe that only served as 'launcher' for the dlls that contain the 'real application'. Hope that helps, Nick

CDialog::SetMenu() should do the trick. Nick

Simply add an icon resource to your .exe. Visual Studio does not automatically create resources and icons for console apps, as it does with dialog based ones, which is why the have no icon by default. Windows uses the first icon in the resources as the app icon by default. Cheers, Nick

Ah, I see. That escaped my attention. Quite obvious though, come to think of it. (->silly me) So the fact that my example code works OK is only by chance and not a regular case and more complicated classes or a release version compile might produce unpredictable results. Thanks for the comment. Nick

Hi! I recently stumbled over this interesting phenomenon using abstract member functions: The situation is this: We have an abstract base class that defines an interface. In the constructor of the base, a specific implementation dependent task needs to be carried out, so an abstract member function is invoked in the constructor. The behaviour of this member function is defined by derived classes. If no function body is provided for this abstract function in the base class, a linker error occurs (unresolved symbol). If we provide an empty body, in the base, everything links fine and the vtable lookup correctly resolves the implementation of the deriving class. The question is this: If the abstract function is resolved at run-time anyway, through use of vtables, why give me a compile-time error if I don't provide a body that will, due to it being an abstract function, never be used in the first place?! Is this a Microsoft specific behaviour bug/"feature", or is this standard ISO behaviour? I compiled this using MS VS .NET 2003 Thanks for any thoughts about this. Nick Here is some exaple code for you to check it out: #include class base { public: base() { abstractFunction(); } virtual ~base() {}; /* if you don't provide the function body with {}, a linker error occurs. Try uncommenting the part of the next line to make it work. */ virtual void abstractFunction() = 0 /*{}*/; }; class derived : public base { public: derived() {}; virtual ~derived() {}; // should be called by base::base() void abstractFunction() { printf("works\n"); } } testInstance; //create an instance right away... This code should print "works" to the console, since the As soon as you uncomment the function body of base::abstractFunction(), everything will link fine and work as expected.

Hi! I need to be able to control the life time of a window that was created in a different process. For that purpose I set a CBT-hook to check for the HCBT_DESTROYWND notification. The problem is that I only get notifications for destroyed windows that were created by threads in my own process. The hook callback function is, as the docs request, in a separate dll. I use this function call to set the hook: ::SetWindowsHookEx(WH_CBT, _CBTProc, hInstance, NULL); Here, hInstance is the handle to the loaded separate dll and _CBTProc is the pointer to my callback inside that dll. As I said: it works, I get notifications, but ONLY for windows owned by threads in my process. That's not what I consider a "system wide" hook! As a workaround I also tried to get the ID of thread owning the window I want to be informed about via GetWindowThreadProcessID() and used that ID instead of the NULL parameter when setting the hook - to no avail... In this same separate dll I use a system wide mouse hook. This mouse hook _does_ work however. So my question is: did I miss something important concerning CBT hooks? How can I get a really system wide CBT hook installed? Thanks in advance Nick

Yeah, I remember that problem. It seems to be special Win98 index behaviour. I circumvented it by simply using: int x = 0; while() { InsertItem(x, ""); x++; } BTW I'm not sure it's safe to use NULL as text either Nick

I don't understand what you mean. Timers should have no impact on repainting of the screen. you only call Shell_NotifyIcon from the timer routine... I don't see how that should distort your screen...

Thanks for the reply. It shed light on some details I wasn#t aware of. Anyway, I discovered that, for some reason, the dll was not unloaded at all (the statement was never executed due to some weird conditions I still don't get). Restructuring the code lead to unloading of the dll and now all works smoothly. It can be so simple sometimes... Nevertheless I got some more insight in the works behind the scenes, so this experience wasn't completely useless ;) Nick

I guess that's because the taskbar where your Icon was registered is closed when logging off and thus your Icon is 'forgotten'. Right now, I don't know of any smart way to determine when a user logs on, so the simplest approach would be a timer that (re-)registers the TaskIcon with the task bar in a reasonable interval, but I'm sure there are more elegant ways to do this via notifications. Nick

Hi! I'm having quite annoying problems when dynamically loading libraries of the type "MFC Expansion Dll". After I load an optional dll at runtime via AfxLoadLibrary(), my main window fails to locate its resources. Interestingly enough, dialogs are constructed OK, but fail when doing data exchange (when using GetDlgItem() I assume). This happens even when I unload the optional dll again (AfxFreeLibrary()) before creating any main window dlls. As far as I understand it, this should remove the loaded Dll from the resource chain, but it never seems to happen (The AfxTermExtensionModule() function is called though). I tried to 'correct' the resource handle via AfxSetResourceHandle() but nothing changed at all. Has anyone had similar problems and can give me a hint what's wrong? Thanks, Nick