|
That message box is talking about the NT4 debug symbols (remember, VC6 is from 1998). Not having symbols for the system DLLs won't affect your ability to debug, the only thing you'll be missing is in the call stack - you won't see meaningful function names for parts of the stack that are in system DLLs.
The real problem is that "dllt.dll" is malware according to a Google search.
|
|
|
|
|
Cool Mike.... Thanks a lot...
What should be my next step... Merely delete "dllt.dll" or run Adaware? I know that is a rhetorical question but I wante to know if "that's all there is to it"...
Again... Thank you very much
Pierre
|
|
|
|
|
You can try deleting the file, but chances are it will be in use and it won't be that easy to delete it. Using AdAware or a similar scanner is the way to go.
|
|
|
|
|
What I'm trying to do is draw a background in a memory device context, and then blit it onto the window when necessary. There is no reason to redraw the background every time OnPaint() runs, so I think I would get better performance if I just drew the background once in memory, then blit the whole thing every time the screen needs to refresh. The program is running without any errors, but "It Works!" is not rendering on the screen. I'd appreciate any help. Are there any good books on this? Mine aren't very good.
Relavent part of implementation file:
void CGameWin::DrawBackground(CDC &dc)
{
CRect ItWorksDimensions;
mem_DC.CreateCompatibleDC(&dc);
ItWorksDimensions.left = 0;
ItWorksDimensions.top = 0;
ItWorksDimensions.right = 70;
ItWorksDimensions.bottom = 20;
mem_DC.DrawText("It Works!", ItWorksDimensions, DT_CENTER);
}
afx_msg void CGameWin::OnPaint()
{
CPaintDC Screen(this);
CRect WindowArea;
GetClientRect(&WindowArea);
OffSetX = WindowArea.right / 4;
OffSetY = WindowArea.bottom / 4;
DrawBackground(Screen);
Screen.BitBlt(OffSetX, OffSetY, 70, 20, &mem_DC, 0, 0, SRCCOPY);
}
Relavent part of header file:
class CGameWin : public CFrameWnd
{
public:
CGameWin();
afx_msg void OnPaint();
//file menu "File"
afx_msg void OnExit();
private:
void DrawBackground(CDC &dc);
CDC mem_DC; //memory device context
CGameKeyBindingDialog CGameKeyBindingDialog;
int OffSetX;
int OffSetY;
DECLARE_MESSAGE_MAP()
};
|
|
|
|
|
When you call CreateCompatibleDC() to create your memory DC, it has a 1x1 pixel monochrome bitmap
selected into it. You also need to create a compatible bitmap and select it into the memory DC
before rendering the text.
Also, creating an offscreen bitmap, just to render text on, and then blting it to the screen
you are not getting a transparent blt so whatever background was in the memory DC is going to
be blted.
There's still a major resource leak re-creating that memory DC on every WM_PAINT message 
You'll get better performance by NOT drawing in response to WM_PAINT, which is low priority
message.
|
|
|
|
|
I have CFormView with 3-Views. Where is the optimal place to
save data on each screen? If I save data as I go between screens,
it does save the data. However, if I hit File/Save as, the data
on the current view is not saved (because I didnt go to the next
view).
There has to be some function out there that will save data for
a screen before I hit File/Save on the menu.
If Im not making sense, please let me know.
Any response any one can give me will be greatly appreciated.
Sincerely,
Danielle Brina
|
|
|
|
|
You did not say anything about the document, but I assume you meant to. I assume you are updating the document when the forms are switched. I also assume that there is one document for all three views.
I think one solution is to update the document every place that the view is updated. You are not doing that but if it is possible to modify your program to do that then it is a more flexible solution.
Otherwise the solution is probably a little complicated. I think that what I have done is that I have used CDocument::UpdateAllViews with a hint that indicates that the view needs to update the document. The complication is that you only want the active view to update the document, correct? If the various views respond to the hint by updating the document only if they are the active view, then I think that will solve the problem.
|
|
|
|
|
Does somebody have experience wih MFC UI threads?
I have MFC dialog application and I need it to contain
child dialog. Is it possible to run message loop of this
dialog in separate thread ?
I do not want this child dialog to be able to freeze my main
dialog when performing some lenghty operation or it finish in
forever loop.
Is it possible to do this? I'm afraid that main dialog's GetMessage()
will be getting messages for child dialog because of window hierarchy.
Or UI threads are good only for windows with parent set to desktop window?
Thank you
rrrado
|
|
|
|
|
It's possible, anything is. Another design approach would be to just have one UI thread
and use a worker thread for the "lenghty operation", unless you really have a need to have the
child dialog's message loop on a different thread. Just my 2 cents.
Mark
|
|
|
|
|
Yes this is true.
So I have to explain it in more detail. Here is an example:
I'd like to create some tabbed web browser where
IE would be hosted in dialogs which would be childs of tab control.
Only one dialog would be WS_VISIBLE at a time. But it is not important.
So I'd like to run this dialogs in separate thread because
I'm afraid the only one message loop would be too overloaded
and crash/hang of one IE would hang whole application.
rrrado
|
|
|
|
|
Cool. For MFC use a CWinThread-derived class for your thread and create it with the appropriate
AfxBeginThread() function call (the one that takes a CRuntimeClass* as one of the arguments).
Override InitInstance() just as you would in your app thread and create the modeless dialog as
the "main window" of the thread.
|
|
|
|
|
I've tried this. But when I've set main dialog as parent of this modeless dialog,
the forever loop in it's message handler stopped main window too.
I guess it's because main thread's GetMessage loop is fetching also child dialog's messages ??
When I've set the desktop window as parent of the modeless dialog it worked but the
dialog was attached to desktop not to my app.
rrrado
|
|
|
|
|
I see what you mean. The secondary window shouldn't be a child of a window in a different
thread I suppose, so it shouldn't be a child window. Still it doesn't make sense that the main
thread is processing the child dialog's messages if the child dialog was created on a different
thread.
What is this "forever loop"? You are in an endless loop on the same thread as your UI?
Are you sure you're not just hogging too much CPU time of the thread's
timeslice in this loop?
-- modified at 13:33 Monday 11th December, 2006
Re-worded
|
|
|
|
|
sorry I mean endless loop. It was while(1) Sleep(1000); so it spent no CPU time.
I haven't tried to stop it in debugger and look what is each thread doing
it would be good idea, unfortunately I don't have that project here
rrrado
|
|
|
|
|
By the way, I don't think separate UI threads are necessary in this case. Unless you are posting
messages from another thread to the windows then your one UI thread should have no problem
keeping up. There's only so much a user can do at a time. Apps can have hundreds of windows
on the same UI thread no problem.
Mark
|
|
|
|
|
Having a parent and child window owned by different threads is problematic because the threads will be blocking on each other when any messages are sent between them (such as notification messages). Keep your UI on the main thread and do your lengthy work in a worker thread.
|
|
|
|
|
Thank you guys.
I wanted to make sure that child window in separate thread is not correct design.
I'll try to go with just main UI thread and I'll see how it will be working.
rrrado
|
|
|
|
|
Lets say ur child dialogs class is CChildDlg
Register this class by calling the function RegisterClassEx.
Implementation is below:
WNDCLASSEX wcex;
wcex.cbSize = sizeof(WNDCLASSEX);
wcex.style = CS_HREDRAW | CS_VREDRAW;
wcex.lpfnWndProc = ChildWndProc;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = _hInst;
wcex.hIcon = NULL;
wcex.hCursor = LoadCursor(NULL, IDC_ARROW);
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
wcex.lpszMenuName = NULL;
wcex.lpszClassName = "CChildDlg";
wcex.hIconSm = NULL;
if (!RegisterClassEx(&wcex))
{
//some error
}
Then declare the "ChildWndProc" wndproc for ur CChildDlg class as mentioned below:
ChildWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_COMMAND:
break;
case WM_MOUSEMOVE: break;
case WM_CLOSE:
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
this will help u..
but mind you always create the CChildDlg in a separate thread so as this doesnt stop the main application, else it will function as a normal child window class.
Sunil
|
|
|
|
|
Greetings:
I am looking for and evaluating MFC based charting libraries. Line charts, bars, pies, 2D, 3D, hyperspace, the works.
Any suggestions?
Thanks,
Mark
|
|
|
|
|
I'm using mouse wheel as user input in a CWnd. But when vertical scroll bars are on, I'm receiving OnVScroll() messages instead of OnMouseWheel() messages.
How can I ignore OnVScroll() messages, and always receive OnMouseWheel() as if the scrollers were not enabled?
Thanks
|
|
|
|
|
Jesper Knudsen wrote: But when vertical scroll bars are on, I'm receiving OnVScroll() messages instead of OnMouseWheel() messages.
Do you mean to say that, even if you are using mouse wheel for vertical scrolling, you are getting OnVScroll called ?
It should not.
Jesper Knudsen wrote: How can I ignore OnVScroll() messages, and always receive OnMouseWheel() as if the scrollers were not enabled?
I might have interpreted your question wrongly, but OnVScroll(WM_VSCROLL) will be called only when you use cursor to drag scrollbar. In case on mouse wheel it will not be called.
-- modified at 10:48 Monday 11th December, 2006
|
|
|
|
|
Well, I am infact not getting mouse wheel messages, only vscroll. That is, if the scroll bar is on. I think it depends on the mouse driver. Once I got two mice connected. One would send mouse wheel as expected, another would translate wheel messages to vscroll.
So I need to break in, where the mouse wheel comes in to reject cscroll messages on mouse wheel.
|
|
|
|
|
Hi
Can anyone point me in the right direction. I have a MFC application that I would like to profile. I have the right version of VC++ and have turned on all the profiling options according to the documentation as far as I can tell.
When I run the profiler I get the initial startup dialogs from my app but the main window never appears. Task manager shows that an app of the same name but with a ._ex extension is running. If I kill this process then the profiler complains that the .pbo file wasn't of the right format.
What am I doing wrong?
Many thanks for any guidance that can be provided.
Andrew Hoole
|
|
|
|
|
Profiled/instrumented application can take a LOT longer to run than even a debug version.
Is the process running or is it standing still ( 0% CPU ) ?
just to be certain, put a couple of output traces here and there in your code to let you know that the thing is running ok.
|
|
|
|
|
It is standing still on 0% CPU. I have left it for quite a while without seeing anything happen.
Andrew Hoole
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
