|
The idea is to havesome kind of application running my code and another
thread which is capable managing my administration needs of the main
thread as well as showing log information in the special window.
Is there a way to do thet? Or I have to connect to my application with some
kind of communication stuff and send all the information force and back between my main application and administration tool?
Gollum
|
|
|
|
|
Hey all,
I'm getting exceptions thrown when I create a CPen like this:
CPen(PS_SOLID, 4, RGB(0,0,0))
CPen's constructor uses the following code:
if (!Attach(::CreatePen(nPenStyle, nWidth, crColor)))
AfxThrowResourceException();
and Attach() fails coz ::CreatePen() returns NULL. I can't descend into ::CreatePen(), I assume because the source-code isn't supplied.
Now according to MSDN, "If the function fails, the return value is NULL". But why is it failing?
The constructor only starts throwing exceptions after my app has been running for a while (i.e. about 10mins of hard work), but I don't know enough about MFC to deduce what that means about my problem.
In the ::CreatePen() documentation MSDN says "Windows NT/2000: To get extended error information, call GetLastError.". I tried that in a catch(...) straight after calling CPen's constructor, but the string I get is "Operation Completed". Not really that helpful. And yes, I am running NT
Why Oh Why is this happening ? Has anyone else experienced this? Can anyone suggest anything?
And here's another wierd thing. I have another call to CPen::CPen(...) in another class's member function, and that seem's to work. Or at least it doesn't throw an exception as far as I know.
I hope someone can stop me pulling /all/ my hair out over this!
TIA,
Pete
|
|
|
|
|
Ummm... The only reason I can think of for ::CreatePen failing is that you're running out of GDI resources. After creating and using a pen, you must delete it with ::DeleteObject , but I guess the CPen destructor takes care of this. Also, if you're selecting the pens into a DC, you must deselect them back when no longer needed.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I think you're onto something.
I just noticed that once things start failing, the stock error messages that VS displays (i.e. for an ASSERT(false) ) are not in their normal font, they're in the default ugly font.
I guess I'm running out of resources coz I'm not deselecting Pens, Brushes etc.
I'll try doing that, and see if that fixes it.
Thanks a lot for your help Joaquin
Pete
|
|
|
|
|
Use windows resource meter or VC++ stress utility to watch your resources drop of the face of the earth if your not selecting orignal pens back into the DC.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I have a situation where I have #define with an identifer but no token string.
The identifier is defined and can be tested if it is defined or not, but how can I test the identifier for no token string ?
|
|
|
|
|
Very interesting problem! Try this:
#ifdef IDENTIFIER
enum {length_identifier=sizeof(#IDENTIFIER)-1};
#else
enum {length_identifier=-1};
#endif
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
How do you make to change the background color of CView into SDI (default is white)
(without called CView::OnPaint is possible)
thx
|
|
|
|
|
overriden WM_ERASEBKGNG .
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here." Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
no, because WM_PAINT is the last message and the backgound stay white. But i FillRect the RectClient of CView but there are clippings during windows sizing.
|
|
|
|
|
I don't quite understand your point for not wanting to do it this way. Here is more information for WM_ERASEBKGND.
WM_ERASEBKGND is called when you call ::BeginPaint or use the CPaintDC inside of your WM_PAINT handler. If you try to do this in the WM_PAINT handler or somewhere else, you will get a flicker from the default handler for WM_ERASEBKGND erasing the background to white.
The wParam in WM_ERASEBKGND is the HDC that you should use to erase the background. This HDC is pre-initialized with the update region for the window, so it will clip anything automatically for you. Use this code:
COLORREF clr = RGB(255,0,255);
HBRUSH br = ::CreateSolidBrush(clr);
RECT rClient;
::GetClientRect(hWnd, &rClient);
::FillRect((HDC)wParam, &rClient, br);
::DeleteObject(br);
|
|
|
|
|
The solution is :
CView::OnEraseBkgnd(CDC* pDC)
{
CBrush backBrush(RGB(0, 0, 0));
// Save old brush
CBrush* pOldBrush = pDC->SelectObject(&backBrush);
CRect rect;
pDC->GetClipBox(&rect); // Erase the area needed
pDC->PatBlt(rect.left, rect.top, rect.Width(), rect.Height(),
PATCOPY);
pDC->SelectObject(pOldBrush);
return TRUE;
//return CView::OnEraseBkgnd(pDC);
}
don't use return CView::OnEraseBkgnd(pDC);
|
|
|
|
|
Hi,
I have a vanilla SDI app with a scroll view in it. I have also created a CWnd derived window intended to be used as a child window in a dialog etc to pick colors from. It is populated with about 400 colors obtained from a 3rd party source.
All drawing seems to be OK, apart from:
I choose a color in my derived child window, then click in the SDI view to 'draw with it' and the colors don't match up. I'm not sure if the view or the child window is drawing the colors wrong (hopefully not both as the colors are different!). I did put the RGB value of one color into Paint SHop Pro and it corresponded to the view, so I think the view is right.
Is there anything you have to do to get a window (my derived child window) to have the same color depth as the view? Or is something else amiss?
Thanks in advance,
Simon
|
|
|
|
|
If you've managed to make different parts of your screen the same colour depth then I salute you. You may have a DIBSection that you are drawing on, and it may be any colour depth, so check that first - if it's 8 bit then there's your problem right there.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
Christian,
Thanks for the response.
To be honest, I think there is a problem with the CDC that I am given. I simply pass it to the render function that creates a compatible dc with a compatible bitmap attached to it. I do this because I am drawing the state off-screen for flicker-free drawing.
I will try drawing direct to the given DC, but I don't feel this will help at all.
Is there anywhere that you can influence the color depth of a window's DC at creation or after?
Simon
|
|
|
|
|
Hmmm, most interesting. In case anyone was interested, I have overcome the problem, but storing the color not as 3 bytes, but as a COLORREF structure.
I am slightly confused, since I thought all the COLORREF structure was is 3 byte values, but if it works, I ain't going to kick it!
Simon
|
|
|
|
|
The problem was obviously in converting the COLORREF to unsigned char values, because that is all they are in the COLORREF
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
Soup,
while not having an answer as to why the two colours don't match up I do have this link for you. Try Color Picker, it's free and will show the RGB values for any area of the screen that is under the cursor. Should make it a bit easier than copying into Paint Shop Pro.
Michael Martin
Australia
mjm68@tpg.com.au
"Don't belong. Never join. Think for yourself. Peace"
- Victor Stone
|
|
|
|
|
Thanks for the input guys. Everything is back on track now.
Simon
|
|
|
|
|
does anyone know how to make the OK button the default button in a property page created in my MMC snapin? For now, it defaults to the "Cancel" button.
Tx
Michel
If I am wrong or said something stupid, I apologize in advance
|
|
|
|
|
First of all, If I am wrong or said something stupid, I apologize in advance. Try adding this to CYourPropertySheet:OnInitDialog :
GetDlgItem(IDCANCEL)->ModifyStyle(BS_DEFPUSHBUTTON,0);
GetDlgItem(IDOK)->ModifyStyle(0,BS_DEFPUSHBUTTON); If CYourPropertySheet:OnInitDialog is not available for modification (don't know what those "MMC snapins" are), try moving the code to CYourPropertyPage:OnInitDialog :
GetParent()->GetDlgItem(IDCANCEL)->ModifyStyle(BS_DEFPUSHBUTTON,0);
GetParent()->GetDlgItem(IDOK)->ModifyStyle(0,BS_DEFPUSHBUTTON); Hope it helps.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I try to send messages from my program to Word 2000 but it doesn't resieve them... All is OK with Word 95 & 97... What should i do?...
|
|
|
|
|
I think it is better to put your codes here,then people can help you better.
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here." Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
Hi,
I'm having a difficulty with using the docking windows and how they are laid out. Currently, I can get the windows to layout like in DevStudio:
--------------
| | |
| | |
| | |
| | |
--------------
| |
| |
--------------
I would however like the window on the left to run the full length from top to bottom and have the bottom window have it's left side against the left window, not the client window. Like this:
--------------
| | |
| | |
| | |
| | |
| |----------
| | |
| | |
--------------
Does anyone know if this is possible and how I can make this work?
Thanks in advance,
Craig
|
|
|
|
|
Seems like defining the splitters in the correct order should do it.
Split the main frame into s1 and s2 vertically
--------------
|s1 | s2
| |
| |
| |
| |
| |
| |
--------------
Split s2 into s3 and s4 horizontally
--------------
|s1 | s2
| |
| | s3
| |---------
| | s4
| |
| |
--------------
Split s3 into s5 and s6 vertically
--------------
|s1 | s2 | s2
| | s3 | s3
| | s5 | s6
| |---------
| | s2
| | s4
| |
--------------
split s4 into s6 and s7 vertically
--------------
|s1 | s2 | s2
| | s3 | s3
| | s5 | s6
| |---------
| | s2 | s2
| | s4 | s4
| | s7 | s8
--------------
So An outline view clarifies the nesting of the splitters
s1
s2
s3
s5
s6
s4
s7
s8
Hope this helps,
Bill
|
|
|
|