|
Thank you very much.
I tried and it works.
The most important thing is that the CDialog class MUST be derived from the empty constructor from CDialog.
Many Thanks
manu
|
|
|
|
|
I have some Borland C++ source files. I want to extract parts of them and use them in a C# project.
I modified/recompiled one of the simple C++ .cpp files into a .dll file successfully and have been able to access its classes from my C# project.
But...and there's always a butt...some of the C++ .cpp files make calls to classes in other C++ .cpp files. If I have two C++ .cpp files and one of them calls a class from the other C++ .cpp file, can I compile the two files into one .dll ? If so, I'm not having much luck doing this with Borland Builder 6, maybe you have some pointers.
If it is not possible to do what I have described, what is the correct approach?
|
|
|
|
|
I recently un-installed and re-installed Visual Studio 6.0. Something I noticed at the end of the installation process (I don't remember seeing this before) was a message box that popped up saying"
Setup has installed an icon in the Microsoft Visual C++ 6.0 group, that will allow you to install a subset of the Windows NT system symbols(.DBG) files....
For easier application debugging, it is strongly recommended that you install these files..
When I try clicking on the icon they mentioned, I get messages saying that the files I am trying to install don't coincide with the DLLs in my system32 area. This is strange because it is asking me to load the CD that I just used to install Visual Studio.
Anyways, I built a small dialog app with only one button. When I try to debug this app even with no breakpoints, after the dialog box for the app is put on the screen, I get a message box that says
User breakpoint called from code at 0xa725cd.. and the break pointer is at that address in machine code.
If I put a breakpoint inside OnInitDialog(), everything works fine, the code stops and I can look at watch points. But, once the app is allowed to run to where the dialog box is displayed, I get what I mentioned above.
Once I "stop debugging" the output window has the following in it
Loaded 'ntdll.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\kernel32.dll', no matching symbolic information found.
Loaded symbols for 'C:\WINDOWS\system32\MFC42D.DLL'
Loaded symbols for 'C:\WINDOWS\system32\MSVCRTD.DLL'
Loaded 'C:\WINDOWS\system32\gdi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\user32.dll', no matching symbolic information found.
Loaded symbols for 'C:\WINDOWS\system32\MFCO42D.DLL'
Loaded 'C:\WINDOWS\system32\comctl32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\advapi32.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\rpcrt4.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\uxtheme.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\msvcrt.dll', no matching symbolic information found.
Loaded 'C:\WINDOWS\system32\dllt.dll', no matching symbolic information found.
First-chance exception in MoreButtons.exe (DLLT.DLL): 0xC0000005: Access Violation.
The program 'D:\PROJECTS\MoreButtons\Debug\MoreButtons.exe' has exited with code 0 (0x0).
Is it possible that I might have some corrupt files in my system32 folder????
Thank you in advance for any help
Pierre
|
|
|
|
|
I forgot to mention....
I am running Windows XP Pro with SP2
thanks
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
