rechi, thanks for all your help, apparently it had to be created with the desktop window pointer. hey

AHHHH!!! I finally got it, you have to create the dialog with the desktop as the parent and not set it as the parent later dlg->Create(IDD_DIALOG, GetDesktopWindow()); Boy do i feel stupid :wtf: hey

directly how? you mean without using a dialog resource, or without using CDialog? My modeless dialogs are already made with CDialog, and it would be an overhaul to change them. Is there some way to intercept MFC and selectively stop it's internal message handling? hey

DavidCrow wrote: Which might be an indication that no one has an answer I guess I was secretly hoping somebody was going to pull out their secret MFC internal mapping chart they swiped from the MS complex in Washington and answer this eventually, but alas, it doesn't seem to be happening :( hey

1. MFC dialog app is created 2. 2nd modeless dialog is created with extended style WS_EX_APPWINDOW, it's then shown and updated. The parent is set to null or desktop with SetParent(NULL) or SetParent(GetDesktopWindow()) 3. Main dialog window is minimized, and as it is, the taskbar space for the non-modal disappears and the non-modal dialog is also minimized 4. NO, i repeat NO messages at all are sent to the non-modal dialog such as you would expect (ex. WM_SIZE message). My Question is simple, what the heck is going on? How does one stop MFC from stealing the non-modal dialog's messages and reducing it automatically and removing it's taskbar space? So far no one has been able to answer this, and I've posted it a couple times. hey

1. MFC dialog app is created 2. 2nd modeless dialog is created with extended style WS_EX_APPWINDOW, it's then shown and updated. The parent is set to null or desktop with SetParent(NULL) or SetParent(GetDesktopWindow()) 3. Main dialog window is minimized, and as it is, the taskbar space for the non-modal disappears and the non-modal dialog is also minimized 4. NO, i repeat NO messages at all are sent to the non-modal dialog such as you would expect (ex. WM_SIZE message). My Question is simple, what the heck is going on? How does one stop MFC from stealing the non-modal dialog's messages and reducing it automatically and removing it's taskbar space? So far no one has been able to answer this hey

1. MFC dialog app is created 2. 2nd modeless dialog is created with extended style WS_EX_APPWINDOW, it's then shown and updated. The parent is set to null or desktop with SetParent(NULL) or SetParent(GetDesktopWindow()) 3. Main dialog window is minimized, and as it is, the taskbar space for the non-modal disappears and the non-modal dialog is also minimized 4. NO, i repeat NO messages at all are sent to the non-modal dialog such as you would expect (ex. WM_SIZE message). My Question is simple, what the heck is going on? How does one stop MFC from stealing the non-modal dialog's messages and reducing it automatically and removing it's taskbar space? So far no one has been able to answer this hey

i would say off hand it's because it doesn't really matter. I put the braces where ever I feel like at the given time. hey

you may want to go to amazon.com and looking up windows shell programming by dino espisito. They still sell it new on e-book hey

CMapStringToString mYmAcMaP; mYmAcMaP[_T("192.168.2.61")] = _T("00:50:8D:39:61:E1");

1. MFC dialog app is created 2. 2nd modeless dialog is created with extended style WS_EX_APPWINDOW, it's then shown and updated. The parent is set to null or desktop with SetParent(NULL) or SetParent(GetDesktopWindow()) 3. Main dialog window is minimized, and as it is, the taskbar space for the non-modal disappears and the non-modal dialog is also minimized 4. NO, i repeat NO messages at all are sent to the non-modal dialog such as you would expect (ex. WM_SIZE message). My Question is simple, what the heck is going on? How does one stop MFC from stealing the non-modal dialog's messages and reducing it automatically and removing it's taskbar space? So far no one has been able to answer this :( hey

glad to hear you worked it out hey

I was thinking the same thing. A global system hook should catch messages without any code in the target application. That's what a global hook does. hey

"One idea could be to try to find all CHARFORMAT PARAFORMAT or CHARFORMAT2 PARAFORMAT2 structures and modify their dwMask member. That would give you some control over what is changed." ???, it would only give it control if that CHARFORMAT was being selected into the A CRichEditCtrl. dwMask should always be filled with all bit flags even if you're not using them, CHARFORMAT cf; cf.dwMask = CFM_COLOR | CFM_FACE | CFM_SIZE | CFM_BOLD | CFM_ITALIC | CFM_STRIKEOUT | CFM_UNDERLINE; or the RTF box will inherit properties from the last CHARFORMAT that was selected into it, or default if none. having all bitwise flags on dwMask then setting dwEffects to 0 like hmmm...( cf.dwEffects = 0; ) will kill all previous styles of the RTF selected font This ensures that no other previous styles are lingering. Alternatively, if you never change the font and are just using the RTF box because it has an autoscroll and CEdit doesn't, you can use SetFont(&CFont, TRUE), then you don't have to worry about all that crap. hey

are you using SetSelectionCharFormat(CHARFORMAT) or SetFont(&CFont, TRUE) ??? also, I assume you were talking about CRichEditCtrl hey

You can use std::string as Christian suggested then, I assume you mean you can't use CString because you are using Borland CPP, or linux CPP with KDevelop or something. I suggested CString because this forum is supposed to be for Visual C++. I also assume that if you meant you don't want to use MFC, that you'd have posted something along the lines of "I don't wanna use MFC" CString is readily available to Visual C++ CPP projects through the MFC headers Mazdak wrote: Beer wrote: I think CString is for you. I'm using C++. Mazy No sig. available now. hey

first, go to classwizard from by right clicking on your dialog class click the member variables tab and add a variable for your picture CStatic as a CStatic CONTROL, and call it m_picture. Now left click on your CStatic in the resource editor and make sure it's set to type: bitmap Now double click on the button you want to control the picture change in the resource editor and let it add the mapped function for you by hitting "ok". Now you should be in your dialog with the new button pressed mapped function now add this code like so void Cdlg::OnButtonClick() {HBITMAP hBitmap = (HBITMAP) ::LoadImage(NULL, _T("C:\\some\\image\\location.bmp"), IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_CREATEDIBSECTION); m_picture.SetBitmap(hBitmap); } now compile and watch as the code works. PS- that obviously works just as well using a resource bitmap, and if it's not a dialog you would obviously create the CStatic naming it m_picture(class member) and initialize it and show it before using it.

this may sound awkward, but did you try passing the CString by value instead? I've had some nasty stuff happen when I tried passing CStrings by a pointer then using them in controls. hey

I think CString is for you. hey

ModifyStyleEx(0, WS_EX_APPWINDOW); SetParent(GetDesktopWindow()); Tried it this way in the non-modal initdialog. No Go Senior! Thanks for the suggestion, but I knew it wasn't going to work because i had previously tried setting it to NULL. The maindlg window of my dlg app is still minimizing it and removing the taskbar spot on minimization. And all the while sending No messages to the WndProc of the modeless dialog. I have a feeling that this is some powerful MFC voodoo that can only be resolved deep within the cavernous realms of the microsoft building. In other words unless somebody just knows, i don't know if it can be "figured out", since it's depriving any Wnd after the initial dialog of any type of messages about the altered window state hey