Brundiez wrote:

Now what I want to know from you guys is, whether this is going to be a performance hit if I implement it in production. I think _no_big_deal_ but what is your opinion?

My understanding is that there are quite large overheads in doing a throw / catch. Also, what happens afterwards? Does the code keep running, or do you inform the user? Either way, I reckon it is no big deal. Especially when you include the time taken to actually deal with the line number information. The cost of storing the line number in a global variable is nothing in comparison. But I've just noticed that you say:

Brundiez wrote:

Before compiling the code write a script that will insert this statement after every line of code

*Every* line of code? Do you *really* need to know so precisely? Shraddhan

What I do is to buld a string containing the value of __LINE__ and pass this to a global ThrowError function which packages this into an object which throw can throw. For example: class CMyError : public CException { public: const char * Message; }; and somewhere in the code: static CString s; s.Format("File %s, line %d\nOverflow in addition", THIS_FILE, __LINE__); ThrowError(s); where ThrowError puts its argument into Message in an instance of CMyError and throws the CMyError. So basically I can send any information I want to via a throw. Shraddhan

Nick Cassavaugh wrote:

AfxDlg.rtf is auto-generated by the MFC AppWizard; is there a way to RE-generate this file?

As far as I remember, the file AfxDlg.rtf is generated by the AppWizard, but leaves lots of places for you to modify. If you have totally lost the original file, you could create a new project like your current one, copy the file, and delete the new project. Then make a copy of it just in case. But why are you using the old style help compiler? Use the newer HTML help system. You get a better product, and if you have to start from the beginning anyway, there is not much lost. Shraddhan

Owner drawn wrote:

Which version of Visual studio are you using.

Visual Studio C++.NET 2001

Owner drawn wrote:

File ->>>(Add your text here in the menu bar)Click here to drag the window. New Open Etc... This is just a workaround.

Err, no... If I understand you correctly, what I now end up with is my original window with an extra menu item on the right. When I click on it, I can certainly drag the window, except that if I make the window narrow enough, the new item drops down to a line below, and the dragging on the new menu item no longer works because it is in a different place (previously occupied by an edit control, and much further left than it used to be). I can still drag the window by clicking to the right of the menu. What I want to do is to somehow mark the whole of the window area to the right of the menu. When I increase the window to the full width, the menu that says "Click here to drag the window" is now almost centered in the window horizontally, and the issue remains, that nothing marks the drag area on the right.

It's not a matter of adding another menu item. What I want to be able to do is to draw some hatch bars like you see in the bottom right of some windows. The whole or the area to the right of the last menu item is used for dragging the window, and I just want to identify this area in some way. Adding a menu item prevents the window being dragged with a click in this area. Besides, my drawing code does not draw on top of the menus I've got. Plus, remember that the window's width can be changed by dragging its edges. Shraddhan

jhwurmbach wrote:

But you can - with a slight overhead of work, maintain the old as well as the new Project files and Solutions

Well, I suppose that this is a possibility. But unless there is a good reason to be able to use both IDEs on the one solution / project, I prefer to make a clean change over. (And what if I had both IDEs open at the same time on the same project? Chaos...) Shraddhan

Rage wrote:

Is this a Dialog or a SDI/MDI child window ?

Actually it is a CWnd which is behaving like a CDialog. (It used to be a CDialog, and for some unpsecified "good reasons" I noted in my comments long ago, it was converted to a CWnd.) As for the actual drawing coordinates, I used the following code in OnNcPaint: CPaintDC dc(this); // device context for painting dc.Rectangle(100, 1, 700, 3); dc.Rectangle(100, 5, 700, 7); dc.Rectangle(100, 10, 700, 12); dc.Rectangle(100, 15, 700, 17); RECT rect = {50, 0, 700, 20}; dc.DrawText("XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX", 45, &rect, 0); CWnd::OnNcPaint(); Commenting out the final line gave me a transparent header, though the menus still showed. The window varies from about 300 to 550 pixels wide. The string of XXXXXXXXXX seemed to be drawn and rapidly covered over. I thought that OnEraseBackground only handled the client area? Anyway, I tried it out, still did not paint to the right of the menu area. Shraddhan

I am using VC6 and VS2001 together, no problems. Except that, if you try to run your VC6 code on a later system, you will be told that it needs to be altered first. If you allow this to happen and open your old programs on you new IDE, I don't know of any way to go back. So until you choose to move your code over, it is certainly best to keep the projects apart. I had a fairly large project on VC6 and decided to use VS2001 on it. This was fine for a long time, but a week ago I finally ran into some problem that I could not resolve, and decided that the time had come to properly update my project. So I made sure I had an extra backup, renamed the old folder, created a new project in VS2001, and transferred all the source files over. This tooke a morning, what with having to change a lot of include paths due to VS2001 using s different layout from VC6 for its files. But it was certainly worth it in the end to move to a newer system. Cleared out a lot of junk files in the process. But I still use VC6. For one thing, there is inforamtion in its help system that you will not find in VS2001 and, I assume, in all later versions. And from time to time I come across code written for VC6 which I would not want modified. I would upgrade to VS2005 if I could find a supplier. Whether I would then still use VS2001, I don't know. Buying it was a bit of a mistake, being a new IDE at the time. More mature code tends to have bugs / deficiencies that are less glaring. Shraddhan

I have a window which contains a menu, two large edit boxes filling the whole space underneath, and nothing else. No caption / title bar. To allow dragging the window, the area to the right of the menu can be used instead of the caption area. All works fine, but I would like to draw something on this area to indicate that it is an area on which the user can click to drag the window. So my question is, how do I draw in the menu area? Not on an actual menu item, but in the empty space to the right? I tried this in OnPaint and no luck, I tried OnNcPaint. I thought I could just detect some flicker from my drawing when I resized the window, and the window border at the far right did have something drawn on it, but too low down, below the menu. Is what I am trying to do possible without creating my own menu and menu handler? Shraddhan

khan++ wrote:

then the stack might even get corrupted

Didn't I say that the array of CEdit controls was a member of the window class, a CDialog? I assumed that the controls would be allocated memory anywhere but the heap, and being created by the class's constructor, if this failed the dialog would surely not open. Or am I missing something here? Shraddhan

With two monitors, you just have a larger screen. So if with one monitor you have a screen that is 1024 x 768, with two monitors both set to the same resolution, the screen will be 2048 x 768 if they are arranged side by side, or 1024 x 1536 if one is logically above the other. (I find the vertical arrangement confusing, but very handy for word processing when you want two views on the same document.) Be warned though, that with two monitors the screen coordinates can now be negative. The primary monitor will always have it top left corner at 0, 0 but the secondary monitor (assuming that you ONLY have two) can be placed to cover any rectangle that touches the primary monitor's screen area. So the secondary monitor could be up and to the ledt and have its top left corner at -1024, -700. You will find it tricky to navigate your mouse between the two in this case. Also, now that you have two monitors, make a point of checking out code to handle monitors. Some companies write software that pops up dialogs that can not be moved, and which come up right in the middle of the screen. So the dialog is half on one monitor and half on the other. Make sure this does not happen to your code! Shraddhan

Whether or not 500 controls will fit on a mere 1024 x 768 display surely depends on how big they are and what they do. I don't know what the original questioner had in mind. I know that I have a dialog that will hold up to 120 CEdit controls and about a dozen others, and the property sheet technique will not help as they all need to be visible at the same time. However, as my screen resolution is a pleasant 2304 x 864, this is perfectly OK. I note with interest your comment on my code smippet that CStatic m_Static[500]; is not a very good idea. Please tell me why not? As the array is a member of a class (a CDialog), I don't need to worry about deleting it. So in what way is using new better? Shraddhan

... initialise local variable storage to 0 Not that I have noticed. In fact, Visual C++ 6.0 and .NET 2002 both set unassigned variables to something like 0xCDCDCDCD. Also in Debug mofe, apart from the preprocessor variable _DEBUG being defined, changes are made to several system functions, including new and delete to help catch problems with memory allocation. Allocated blocks of memory have guard bands around them. All user-written functions have code added at the beginning and end to look for problems. If you release a Debug build, beware - there is debugging information in the .EXE file, a wonderful opportunity for hackers. Makes life so much easier for people to disassemble your program. Try writing a program that WILL crash, and compile it both in Debug mode and in Releae mode. Run the Release version outside the Visual C++ environment, as if it was an ordinary program being run. When it crashes, the system will offer to help debug it. Accept the defaults offered, and you will find yourself back in Visual C++, wondering what on earth you are looking at. Do the same with the Debug build and you will see the difference. Note that the checks for unassigned variables are not foolproof, unfortunately. I have sometimes have the Debug version work perfectly, and the Release version of the same code crashes due to unasigned variables not being detected. Shraddhan

Here's a fragment of code from a dialog I wrote earlier: Declare some controls CStatic m_txtLabelIn [ 500 ]; And create them with any arbitrary size for now for (i = 0; i < sizeof(m_txtLabelIn) / sizeof(m_txtLabelIn[0]); i++) m_txtLabelIn[i].Create("", SS_LEFTNOWORDWRAP, rect, this); and then do a SetWindowPosition on each one to put them where you want them. (You ARE sure they will all fit the space available?) Shraddhan

I couldn't find information on GetTextExtentPoint32. GetTextMetrics returns a TEXTMETRIC structure that gives average and maximum character width, which are no good for my purposes. Under GetTextExtent and GetOutputTextExtent, Microsoft notes: Since some devices do not place characters in regular cell arrays (that is, they carry out kerning), the sum of the extents of the characters in a string may not be equal to the extent of the string. So clearly ambiguous! My notes on my problem with fitting strings into CEdit controls mention that the text is shown with white space on either side. In fact, with large font sizes. the output is chopped on the right if it gets anywhere near the edge of the edit box. But I have no idea what the whitespace allowance should be. It depends on the face as well as the size. So is this a feature of CEdit controls? As for finding the overall height, one last ditch method occurred to me: draw the text to a bitmap and measure the height of the drawn area by scanning the pixels. Don't ask me how, though. Shraddhan

I totally agree that some people go overboard with Hungarian notation, presumably in the belief that it will make their code easier to understand. Me, I have four rules: a pointer variable always starts with p, and a class member variable always starts with m_ and boolean variables always start with b (unless they are called ok or failed). Finally all (of the very few) global variables start with a g_ to highlight that they are global. (I once came across some code, perhaps 200 lines, where the 'programmer' (or idiot, more likely) had defined a global variable called i presumably to save having to define it in every function!) The first rule certainly helps save confusion, like, Is what I am passing to this function a pointer or a reference? The second rule's benefit comes largely from the fact that with complicated code it is easy to run out of variable names. By sticking a tag in front of a load of the variables, I create room for more. The g_ and m_ prefixes certainly help me stop worrying how the variable got its value. As for putting an i in front to show that the value is an integer, this is a waste of time at best. And I don't see the point in adding a prefix to strings to indicate that they are null terminated. How many strings are NOT null terminated? Besides, suppose I decide to define CString Name; and later in the interests of speed decide to redefine as char Name[100]; Should I rename Name as psName to show that it is now a pointer to a string? Or call it sName to show that it is an array which works as a string? No, just call it Name, capitalised here because it is an important variable, as distinct from name which is just some temporary name used very locally, a throw-away version. A name should describe the purpose or algorithmic behavior, not the implementation. The IDE will tell me about implementation. As a programmer looking at ancient code I wrote last month, I want to get an idea of what the code is meant to be doing, what its purpose is, and I do not want to be distracted by irrelevant low level details. Shraddhan If you want my advice, contact my secretary for a quotation first.

That's what I do too, doing each control 'by hand'. I reckon it can give a much better appearance, as various things need different changes. In fact, in some dialogs I even alter the layout as the size changes. It can be a bit of a pain to do, so it is worth doing methodically, and commenting clearly. It is easy to get into a muddle doing this kind of thing. Oh, I also take screen images and load these into graphics software so that I can enlarge them enough to be able to count the pisels. Shraddhan

I believe that in Visual C++ 6.0 there is a key combination that will take you to / from #if and #endif but Microsoft in their 'wisdom' removed this very handy functionality from VC++.NET 2001. Yes, thanks Microsoft... Personally, when I need to comment out large chunks of code, I use #if defined dfkagtljarogh #end if // defined dfkagtljarogh where dfkagtljarogh is the result of some random keystrokes. Copy and paste to make sure that two instances match, and then it is not too bad to use Find to jump from beginning to end or vice versa. And as for being unable to nest /* ... */ comments in C++, this is an abomination that should never have been put into the language. Is there any reason whatsoever why C++ (or C even) HAVE TO REFUSE to allow such useful nested comments? Thanks again, Microsoft. Some C++ compilers do allow this. Shraddhan

I hope you don't mind me sneaking in here. I have the same problem with showing numbers in CEdit controls. How to find the TRUE pixel width of the text? I need to know how many digits can be shown in the control so that I can put in as many as possible, and round the number correctly. It is easy enough to use DrawText() with the DT_CALCRECT flag, making sure that SetFont is done correctly, and for small font sizes the code works well. But as the fonts get bigger, DrawText's calculations just do not agree with those of CEdit. I'm stumped too, and have temporarily had to restrict the font face and size, and apply magic numbers to get the stuff to work. Shraddhan