When I try to execute the following CREATE TABLE command, even directly in Access' query analyzer, I get the message "Cannot create child list for field Table". I can't find any reference by Googling that doesn't refer to binding data grids or navigating away from a record, which I'm obviously not trying to do here. CREATE TABLE test ( [code] INTEGER) I tried adding PRIMARY KEY just in case, but no difference. The table itself *is* created successfully - it seems to be trying to do something after creating the table and that's what causes the error message. Any ideas?

The co-ordinates specified in the control's Create() call are specified in the parent's (your dialogue's) CLIENT co-ordinates. 'Client' co-ords have their (0, 0) at the top-left of the space *within* any border and title bar the dialogue has. If it has no border and no title bar, then this is the same as the top-left of the full dialogue. If you want to know how far the control is from the top-left of yoour dialogue and you have a title bar and / or border, then you need to get the dialogues 'window' rect, and the control's 'window' rect, and then you can calculate the offset. Note, though, that if you ask a control for its client rect, it gives you co-ordinates relative to *its*own* client area, not its parent. If you ask a control or window for its 'window' rect, it gicves you co-ords relative to *the*screen's* top-left. So, to get the offset from a dialogue's client arrea to a control's top-left, do this: CRect rctControl ; MyControl.GetWindowRect(&rctControl); // It's relative to top-left of screen. MyDlg.ScreenToClient(&rctControl); // Now, relative to top-left of dlg's client area. To get it relative to the full dlg's top-left (ignoring title bar and border): CRect rctControl ; MyControl.GetWindowRect(&rctControl); // It's relative to top-left of screen. CRect rctDlg ; MyDlg.GetWindowRect(&rctDlg); rctControl.OffsetRect(rctDlg.left - rctControl.left, rctDlg.top - rctControl.top); // Now, relative to top-left of dlg's full area.

Trying to set the back colour like this will not work. You need to override WM_CTLCOLOR in the dialog class to change the colours of the dialog itself and its controls.

It should work exactly the same - your connect() call can specify 'www.codeproject.com' just as easily as it can specify '192.168.0.5' - if this does not seem to work, perhaps a small code sample showing how you try to connect to the remote server would help us see where the problem lies?

I believe you should add it to the 'pstrRemoteFile' parameter of the PutFile() / GetFile() calls instead of to the server address. Instead of asking for myfile.txt ask for subdir1/subdir2/myfile.txt See if that works for you.

Calling OnNcPaint() directly won't work; you must let the system call it so that you know it has invalidated the right area. I'm not sure why it doesn't call your OnNcPaint() handler when going inactive; I suspect it is a bit of a loophole in the MFC framework whereby it doesn't behave consistently. Perhaps if you tell us why you are trying to paint in this area, we can suggest an alternative approach? Trying to override the system is always erratic at best {:v)

In both cases, the parent or owner has been set as the parent of a control (e.g. SetParent(), or by specifying in the parent parameter of a Create() call). The difference is that if the control was created with the WS_CHILD style, then the outer window is a PARENT. If it was created without this style, it is only an OWNER. For a parent window, when the parent is minimized all child controls are hidden. For an owner only, 'owned' windows remain in place and can be minimized separately. Note that only 'windows' can be owned - 'controls' *must* have a parent and are therefore created with WS_CHILD. (GetParentOwner() will find the nearest window that is *either* a parent or an owner, but not a child - the others will keep walking up the chain until they find specifically one or the other.)

What shows in the tooltip is simply the current caption of your window. So you can use SetWindowText() to change it. Note, though, that this is not always advisable, especially if writing in MFC - the MFC framework handles the window title.

Take a look at ShellExecuteEx() in MSDN. (Hint: you need the _T("open") verb.)

The most obvious thing to say is... is the bitmap's ratio of width to height much taller than the printer page? {:v) It might help if you show us the code that actually 'prints' the bitmap, so we can see if you're doing anything unusual. If you could specify the size of the test bitmap in pixels and the resolution of your printer page in pixels (using the CDC's GetDeviceCaps() method), that would be useful too.

One possible reason that springs to mind is that the file somehow contains an embedded null. If this is true, strTemp probably *is* being added, but the embedded null stops the variable watch window from displaying the entire string. Also, if you try and use string manipulation routines on m_strFileBuffer, they will be affected by this null equally, and terminate the string early. To test if this is the problem, try modifying your code to this: CString strTemp; const int MAX_LINE_LENGTH_EXPECTED = 1024 ; TCHAR cBuffer[MAX_LINE_LENGTH_EXPECTED + 1]; while( ar.ReadString(cBuffer, MAX_LINE_LENGTH_EXPECTED) != NULL) { if (cBuffer[_tcslen(cBuffer) - 1] != _T('\r') && cBuffer[_tcslen(cBuffer) - 1] != _T('\n') ) { // We may have a prematurely-truncated string. // Or it will be the end of the file {:v) assert(false); <=== put breakpoint on this line. } m_strFileBuffer += strTemp + _T(" "); } If there's an embedded null, the character found at where it believes the end of the string is will *not* be the / it should be. Obviously the genuine end of the file may also not end with CR / LF, so be prepared for that. If you think your file might contain lines longer than 1024, adjust MAX_LINE_LENGTH_EXPECTED as appropriate.

Unfortunately this is not the problem - it was from a full recompile. The lowest project compiles fine; when I try and compile the layer above, which depends on it, it then throws out the multiply defined symbols. I already compiled the static lib again {:v(

My hunch was strangely accurate. If you look at the constructor for CFontDialog in MSDN, it has a sample (reproduced below) that sets a negative value (the pixel height) into lfHeight, not 1/10ths of a point as you have: // Show the font dialog with 12 point "Times New Roman" as the // selected font. LOGFONT lf; memset(&lf, 0, sizeof(LOGFONT)); CClientDC dc(this); lf.lfHeight = -MulDiv(12, dc.GetDeviceCaps(LOGPIXELSY), 72); strcpy(lf.lfFaceName, "Times New Roman"); CFontDialog dlg(&lf); dlg.DoModal(); I believe this to be the source of the problem.

The check boxes in trees and list controls are done by creating an image list. The image list is applied to every item in the same manner. To get check boxes for individual items, you cannot use this feature. Instead, create your own image list for the blank (no checkbox), empty check box and filled checkboxes, and whenever you insert an item into the tree, set the appropriate image to check box or no checkbox. It does mean, though, that you will need to process NM_CLICK to 'toggle' the check state by updating the item's image accordingly.

I would hazard a guess to say that it is to do with how Windows maps fonts. In the LOGFONT structure, for example, it needs a *negative* value to get the full character height - a positive value gives a slightly different size as it doesn't check against the full character cell height. Now, this doesn't necessarily mean it's true in your case. I think we are going to need to see some sample code and / or an explanation of what you do as a user with the font dialogue in between examining those values - for example, do you simply cancel it, or do you choose something?

Does xxx.Items(0).Selected = True (where xxx is your list view) not work?

I'm trying to port a project (workspace / solution) from VC6 to .NET 2002. The workspace consists of a DLL front-end, a DLL back-end, and a static library of utilities. They depend on each other in the order listed. In Release and Debug under VC6, they compile (rebuild all) with no problems whatsoever. When I import the projects into a new workspace in VS7 and rebuild all, I get a big wodge of linker errors like this: yyy error LNK2005: "public: __thiscall CPoint::CPoint(int,int)" (??0CPoint@@QAE@HH@Z) already defined in xxx.lib(xxx.obj) where xxx is the static library back-end. I used Project Dependencies to instruct VS7 as to which project depended on which; if I do not, I get linker errors regarding classes in the static lib needed by the middle layer (I haven't even got to the front end). Both static lib and DLL are multi-threaded. Curiously, it's MFC simple classes like CRect, CSize, CPoint and their member functions that are involved; none of our classes or methods. Any ideas on how to resolve this, and why it changed between Visual Studio versions?

When you say "system menu" I believe you mean the right-click menu in Windows Explorer? Search in MSDN for "Shell Basics" and then look at the "Extending the Shell" section onwards.

If you make your text boxes of a class you have derived from CEdit, then you can handle the WM_SETFOCUS message to know when a new edit box has gained focus after the user pressed tab. Since you now know which edit got the focus, you can use GetWindowRect() (followed by ScreenToClient() on the window that holds the edit boxes), and compare this to your window's client rect - *after* the current scroll position has been used to offset the top and bottom of the window's rect. This will tell you if the new edit control is visible; if it is not, you can determine which way to scroll to bring it visible. This can be achieved by calling SetScrollPos() on the scroll bar. I'm assuming you are comfortable with moving the edit controls to simulate being scrolled?

How are you getting your menu to pop up? It sounds as if you're using WM_NCLBUTTONxxx, and I guess when it's in the task bar you don't get this kind of message - am I close? If this is correct, consider using GetSystemMenu(FALSE) and *modifying* that menu to be what you want. I would suggest that it's 'controversial' to meddle with the standard user interface if you can find other ways to achieve your goal. It may be a simple case of disabling all standard items and adding your items to the end...