Comments by Hans Dietrich (Top 123 by date)

Yes, and could you double-size me, too?

I believe the OP is saying that he doesn't have a handle to the current app window, and therefore must pass NULL to MessageBox; this does *not* result in app-modal behavior, unless you use the option I mentioned.

Yes, I think MessageBox will do what he wants, if he chooses the right set of options.

Please take a look at MB_TASKMODAL option of MessageBox().

Good answer.

You are correct; one has to give attention where there is best opportunity to help and to teach. At the same time, I refuse to be be judgmental. My choice of which question to answer does *not* mean other questions do not deserve a serious, professional answer.

I did my best to understand that the OP had a real question. I don't think a lack of vocabulary should be penalized. So, as always, I believe there is no such thing as a bad question, although in this case it could have been phrased a little better.

Evil. God will get you for this.

Agree. Letting the system choose the processor is nearly always the right way. Great links. My 5.

Accurate, complete answer. My 5.

I'm not sure what you mean by "trusted", but be aware that there are utilities freely available that can be used to change the HD serial number. So while you can get the current serial number, don't think it can't change.

Nice link. My 5.

I love one of the user comments on that MSDN page: "This program doesn't work on Windows 7 machine, when trying to get information from a UNIX machine."

Thanks. I used to use windbg a lot, but the VS debugger has improved quite a bit over the years (unlike the IDE :) ).

Good complete answer. My 5.

There are extensions that provide this: http://www.han-soft.com/uninshs.php

Have you checked with the manufacturer of the projector?

Take another look at your function f. If i is NOT equal to 0, what is returned?

Unless it's a static, like Alain says.

Your statement is asinine. This thread is about languages, not compiled binaries. If you think C++ is dependent on the platform, then you should stick with java, because you don't know sh*t about C++.

I have seen a lot of blogs about MS Office and wine. For some people, it works; for others, it consistently crashes. If you know of a good beginners tut for wine, maybe you can post the link here, so the OP can try it for himself?

Correct, my 5.

Who cares?

I know you didn't; but from the 1-votes other people obviously thought that.

Thanks. Some people would associate lack of knowledge with being stupid, but I am willing to believe this was an honest question, from someone with little exposure to the subject. There's no reason not to encourage people like this.

I agree. This is a level of knowledge that comes before questions such as, How do I play a WAV file? We were all here at one point, so we shouldn't be surprised to find others here now. :)

I look at it as *before* the good and evil. I mean, there was a time when I didn't know what ASCII was. I know, I know; a little removed from COM interfaces and .NET interop. I'm not even sure if there are any articles on CodeProject that would help the OP. And if there were, they would probably be downvoted out the wazoo, what with our lovely voting system.

Well, the problem with that, is that the OP would need *two* collections, to match the gender preference of the interviewer. Maybe a Ctrl-key combo switches between them for demo purposes.

I had a similar problem with an MFC app that used the Feature Pack ribbon stuff. You may have to use SetWindowPos to make it top-most, redraw the window, and then call SetWindowPos again to make it non-top-most.

Right, because you said "I don't want it to be top most permanently". BringWindowToTop() will bring it to the top, without making it a top-most window. Did you try it?

Good answer, my 5.

Yes, exactly.

If you have created a Windows dialog-based app, just use ::MessageBox() to display the info in InitInstance() and then return - don't display the dialog.

I suggest you give QuickWin a try first - it's very simple to use. After that, you could go with a "real" Windows app if you needed to. Post a new thread if you want to do that.

MUST.NOT.SAY.DOS.BOX!

Good guidance, Nish.

Edited for grammar and SMS speak.

Very true!

Wow. Never heard of it before.

Maybe two people in the same class? :)

It's actually very well-written and fun to read.

That's exactly what it means. IMHO, Fred Brooks is a clown. If you read his famous book carefully, you will notice two things: 1) he is a good writer; and 2) he was in charge of one of the worst-managed computer projects ever. He did all the wrong things; he made every bad decision possible; he kept repeating these mistakes throughout the project. The project was completed in spite of him, not because of him. That he garnered so much fame for it is a joke.

I thought it was very good. The author makes the point that in any field, to be good at it one must learn the basics. Every day I talk to and work with people who have skipped this step, and treat programming as a cookbook art; they are able to do routine stuff, but anything non-routine is totally beyond them. Even worse, they don't seem to understand that they are writing code not for themselves, but for the maintenance programmers who will follow them, and have to figure out what they have written. Very few of them would be able to tell you what it means to write maintainable code.

Your English is fine, but use of "sms speak" (like "plz") is discouraged on these forums. Please have the courtesy to use standard English.

Except for the reference to Fred Brooks, an excellent link.

Microsoft bought code from BCGSoft and renamed it MFC Feature Pack.

The standard practice when working with "unknown" strings is to set the last character to zero after the copy. (I see this done on Unix more than on Windows.) Yes, the _s functions are nice this way, but to claim they are safe is a joke. See for example, Danny Kalev's analysis here: http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=260

Since this is usually specified in stdafx.h and not in the source file, it is a Bad Idea. What if you were to take the source file and use it in another project, months from now? Then you would have to spend time trying to figure out why you get the warning on one project, but not another. If you want to be proactive about this warning, then do what I do; put this pragma at the top of each source file where needed: #pragma warning(disable : 4996) // disable bogus deprecation warning Note that I say "bogus" because that's exactly what it is; you can achieve the same effect from using strncpy(). Yes, you can be wrong about the length parameter in strncpy, just like you can be wrong about the length parameter in strcpy_s. With both functions, you have to be careful.

In general, unless there is no alternative, it's a Bad Idea to change the project properties just because of what's in a source file. What if you were to take the source file and use it in another project, months from now? Then you would have to spend time trying to figure out why you get the warning on one project, but not another. Even worse, what if someone else changed the properties, and you were not aware of it? Waste of time.

If that's true, then why didn't OP report an error on that line?

The OP didn't say he got an error on this line: if( this->m_StudentName == "" ) so he must not be using Unicode.

This is what I was going to say, but you beat me to it. My 5.

I'll bet you a beer the next MS OS will include the VS6 MFC DLLs.

Googlé

Exactly, which is what I said in my Solution 1.

If the message map entry or message handler is missing, it would be passed to default handler, which would close it.

A preprocessor macro is just that - it gets interpreted before the compile. So at run-time, a preprocessor macro has already come and gone, and can't possibly do what you want. You need something that runs at run-time, that will choose the correct code to run.

:) Who knows? He may learn something anyway!

OK, no problem.

That would depend on the code in the function.

Classic! This one should go to Q&A Hall of Fame.

Gave you a 5, one of my favorite tricks.

Yes, I use this too. Since it was a newbie question, I wanted to stick to the basics.

Brilliant! I now have a new goal in life!

To shortcut the back-and-forth, I have created a demo that shows how to display a dialog from a DLL, Please download it here: http://www.hdsoft.org/download/MfcExtDllTest.zip Please post here if you have questions.

It sounds like you have a dialog class in your DLL. Is that correct? If it is, then yes, you have to create an instance of your class. "MydllDlg.cpp" is a filename. This tells me nothing. Does it contain an implementation of a dialog class? Please show the contents of mydll.h.

If you are just trying to call a function in the DLL, then all you have to say is myfunct(); with the appropriate parameters, of course. Since you haven't shown any code, or said what was in the DLL, this is my best guess.

It's sad, pathetic, idiotic. I run out of words to describe.

:) :) :) Personal experience - from staring at a dozens of comboboxes and wondering why the listbox wouldn't drop!

No, SHGetFolderPath works fine on Win7. It's the MS-recommended alternative that does not work prior to Vista.

You're welcome!

The file memdc.h is from an article here on CP. Then MS came up with their own class, and called it by the same name!@&*$!! Easiest fix: rename memdc.h to xmemdc.h, and rename the class to CXMemDC (naturally, the MS version is not compatible).

It seems like this goes in cycles. First, we had INI files. Then that was bad (per MS), we should use the registry. Then with .NET we're told to use config files (aka INI files). I suppose it will be The Cloud next. :)

Hi Neil, (You responded to your own message rather than mine, so I did not get the notification.) I have always found the CButton class to be annoyingly limited. In fact, I wrote my own XButtonXP class to get around some of these problems. Having said that, I can't say that you can't do what you want with CButton; I have just not seen it done. Maybe someone else can give you a better link.

Correct, my 5.

Most of these books are available used, very cheap. The fundamentals of MFC have not changed that much since VS6, so don't think that these books are obsolete. What has changed in MFC are some new controls, that you will find described on the internet. Another thing to consider if you really want to understand MFC: it is a thin wrapper of many Win32 functions, including GDI. Quickly reading through the Petzold book will give you a feel for what GDI is, and how MFC wraps its functions. Petzold - every Windows programmer should read this at least once (non-MFC): http://www.amazon.com/Programming-Windows-Microsoft-Charles-Petzold/dp/157231995X/ Two very good basic MFC books: http://www.amazon.com/Programming-Windows-Second-Jeff-Prosise/dp/1572316950/ http://www.amazon.com/Professional-MFC-Visual-C-6/dp/1861000154/ A more advanced MFC book: http://www.amazon.com/MFC-Internals-Microsoft-Foundation-Architecture/dp/0201407213/ Intermediate to advanced GDI book: http://www.amazon.com/Windows-Graphics-Programming-Hewlett-Packard-Professional/dp/0130869856/ Finally, don't forget that reading code - like in the articles published here - is a great way to learn. Good luck.

Don't you keep a list of the drawing objects? Simply repaint the list in OnPaint().

Maybe he's going for the market in engineering books written in SMS-speak?

Which is clearly not happening here. In general, to allow for moving the app, etc., it's safest to specify full paths, preferably ones that the user can modify

Correct. #3 is the one I usually use. My 5.

Despite your reference to hoe (which has a particular connotation here in LA :) ), your answer is exactly right. My 5.

Thanks for the discussion. It sounds like you keep up with this stuff. Why don't you write an article that discusses possible future post-Windows OS's?

That looks interesting. Why don't you write an article about how to use Libharu?

It will be interesting to see the migration path for current applications to the post-Windows OS (for brevity I will simply refer to this as POS). Microsoft has to walk a fine line here; if they piss off too many app vendors, the vendors will simply switch to Linux. I have already had several clients talk to me about switching to Qt, because they don't trust Microsoft's plans for the POS. A few years ago, I would have said that not even Microsoft is that stupid; now, I think Ballmer has proven to everyone that he is in fact even stupider. So it will be interesting. Fortunately, I've done a lot of Unix work, so what happens with the POS doesn't matter to me.

You might be right about that. I don't have a better answer. Maybe Chris would consider a temporary jobs forum until the worst of the recession is past. I mean, it wouldn't be taking money away from CodeProject, since the jobs board is defunct.

Yes, I agree. It's too bad there isn't a regular forum for posting job ads. On Usenet, people post jobs all the time in C++ forums, etc., so it makes sense to post job in this forum, where C++ programmers may see it.

Sandeep, If there was still a jobs board here, I would agree with you 100%. I'm sure you've seen posts about people losing their jobs, and I think there are many others who haven't posted who are also looking for work. During this recession, I think we should relax the rules, in order to help members of this community.

aka header guard. :)

I was thinking, Why would someone want to do this? I suspect your #2 point is correct.

Thank you, Espen. What you said is exactly right. My 5.

Is 0 a success code or a failure code? In any case, look at the Qt documentation and check why the API could fail.

Show us your code.

Note that MSDN says: "For some common controls, the default WM_PAINT message processing checks the wParam parameter. If wParam is non-NULL, the control assumes that the value is an HDC and paints using that device context." The standard way to do this is by using code like this: case WM_PAINT: PAINTSTRUCT ps; HDC hdc = (wParam != NULL) ? (HDC) wParam : ::BeginPaint(hWnd, &ps); if (hdc == 0) return 0; [ do some drawing here] if (wParam == NULL) ::EndPaint(hWnd, &ps); return 0;

This looks like you have forgotten to include the module "Seque" in the compile.

You're probably getting downvoted because you posted a VB question in the C++ forum. Choose the Visual Basic forum next time. :)

In case you're wondering, the C++ purists in this forum are probably annoyed at seeing an MFC question, and so downvoted your question. Next time, post MFC questions in the C++/MFC forum. :)

Unless you're dealing with a tightly-controlled in-house app, this is almost always a bad idea. Also bad is putting DLLs in system32. Application DLLs should be put in the app's directory. If you pollute the system path or system32 with non-system DLLs, you could easily end up with a destabilized system with random app crashes. Don't do it. Microsoft says not to.

Wow. Just learned something new. Thanks for this answer. Fived.

Totally agree about Lippman. Only wish Stroustrup would adopt his style.

I considered GDI's performance for .5 seconds before answering, then I figured the OP would like to have something that actually works in the general case. :) If you're really keen on this, why not dash off an article comparing relative performance (GDI vs. ?) for image resize? I would love to read that. There are many algos floating around for doing this, but most simply don't work (at least on the images I've tried). StretchBlt() always works. Seriously, if you know this stuff, please write an article.

Actually, all you need to do is have a boilerplate answer handy, like "See this page on MSDN." Submit that, and then immediately edit it to fill in details. That way, yours will be #1 answer. :)

Andrew! Wow. That's almost an article right there.

Every occurrence of '\' in a string literal must be doubled: '\\', like 'C:\\Users...".

The OP asked about a dll that "exports a number of functions". No mention of classes, etc. I think it's important to address questions that are asked, and not add unnecessary detail; questioners are often beginners and just get confused. I realize that you're very experienced and add extra details gained from that experience. My suggestion: write a tip to record your knowledge.

Good answer. (Don't understand the 1-vote.) I would add that if this situation is likely to occur again, then maybe there should be a 'size' member in the struct.

Nish, you've got it wrong. He is obviously a CIA troll, looking for people who can read his mind. Anyone giving the appropriate response will be whisked away to a secret CIA lab for more testing and possible use as remote viewers.

The version info for my mt.exe in v6.0a\Bin: Version 5.2.3790.2075 Size: 719KB (there is a different mt.exe for x64)

Wow. .NET 4.0 wasn't around when VS2008 was released. Are you sure you're using the right mt.exe? What does the version resource say?

Maybe the OP has no choice? If he works for a company that uses MFC for internal apps? Probably many other reasons, too.

Are you compiling for MBCS or UNICODE? If you are compiling for MBCS, there is code in stdafx.h (#ifdef _UNICODE) that will prevent the manifest from being activated. Just comment out that line and its #endif.

It's not necessary for the radio buttons to be in a group box. It IS necessary that the first radio button have the WS_GROUP style, and for all the radio buttons to have the BS_AUTORADIOBUTTON style.

Cute but patronizing. If you don't have an answer, it's best to pass on by. If you really have to tell him to google, then say it, without the cute stuff.

Thanks for sharing the solution.

Geez. The only answer with code and you got 3'd.