wack

What GUI toolkit you should chose does sometimes depend on what kind of result you want. The two big cross-platform ones are wxWidgets and Qt.

wxWidgets is just a thin wrapper around the platforms native controls, so it will always use the native GUI widgets of the platform, while Qt simluates them instead. This can cause subtle differences between your program and other programs on the platform. If that is a big deal to you, wxWidgets might be better. If it's not, you could use Qt.

According to the Windows 7 logo certification guidelines, which define what Microsoft thinks is a well behaved app, all applications must handle WM_QUERYENDSESSION and WM_ENDSESSION.

More info here:
http://download.microsoft.com/download/1/E/9/1E9580D9-2B2B-499C-918A-C9BA5EAC4A32/Windows%207%20Client%20Software%20Logo.pdf

Precisely those messages needed to do its job - no more, no less.

Why even answer if that's all you have to say?

Yes, it bloody is. Take it from someone who's worked professionally with it for over a decade.

I'm glad that you are talking from experience. Most people who shout "MFC sucks" have never used it extensively. I used to be one of those people myself.

I have worked with it professioanlly for six years. I have alwo worked with other toolkits. They all have quirks that make them suck in some way. Often these ways of suckage are the same as in MFC. Perhaps you could elaborate on what aspects of MFC it is that you think makes it suck so much more than other toolkits?

So if you're only targeting windows, why wouldn't you use the infinitely better winforms?

There could be lots of reasons. Perhaps you want write all of your program in one language? It's not like it's an order of magnitude more difficult to use MFC than to use winforms.

Yes, and if you have a legacy code base that uses MFC, that is exactly what you should do. If you're writing new code, use something else and leverage the huge library of code for that.

I am not completely against using MFC for new projects today. It does make certain types of UI a lot easier to create than any other toolkit. Also, unlike what was claimed in this thread, MFC is just as supported as any other library that comes with Visual Studio, and it is still being actively developed. There also exists excellent third-party components (BCGsoft, CodeJock) for it that have been refined for a very long time, and contain some stuff that really doesn't exist for other toolkits.

Of course, it would not be my first choice, but if the situation and type of application is such that using MFC could save a lot of time, I would at least seriously consider it. Shipping on time is a nice feature to have.

1) I looked up your question, and it seems that it's possible to do what you want:

 

http://msdn.microsoft.com/en-us/library/bb983663(v=vs.90).aspx

 

As for 2), I guess this is pretty much it:

http://msdn.microsoft.com/en-us/library/bb982354(v=vs.90).aspx

 

The MFC extension pack is based on components by BCGsoft, so looking at their documentation might help a little also.

Please don't use MFC for new code.

 

It's ancient, unsupported, non-idiomatic C++, and full of evil pitfalls and gotchas. It really needs to just go die in a corner somewhere.

It's not that terrible. If you only want to target Windows, it's perfectly fine. MFC is structurally pretty much like wxWidgets, but I never hear people complaining about that being evil.

 

In fact, you can save lots of time, as the OP is attempting to do, by using some of the ready-made stuff in MFC. It's pretty easy to set up a GUI that works exactly like some common MS programs (office, VS) and be done with it.

It's the runtime library for Visual C++ programs that dynamically link to the runtime library. It's not needed anymore.

I can see how this would be useful, but there was one (non technical) thing about the paper that didn't feel right.

 

"(The author of this proposal does not seriously endorse the use of macros for type aliases, and the 

I see NSIS has been mentioned aready. I admit it has been long since I last tried NSIS, but I always found Inno Setup more straight forward to use. It's free, and definitely worth a look: http://www.jrsoftware.org/

That's not one of the warning's I'd consider useless. Pointing a non-const pointer at const memory is bad juju. Why not just use a const char * instead?

Please, no religion Half of the people will say one should rewrite everything to const char * the other half will say it's an insane idea and this topic will turn into a discussion about good coding practices.

I just want to know how to disable it

It's not really religion... It's just plain wrong. If you attempt to write to your char* that is actually a const char*, you might in fact crash your program.

Anyways... If you're sure what you are doing I will offer this little tip, although I haven't used Code::Blocks much.

There most certainly should be some kind of project option where you can specify custom command line arguments for the compiler. If you can't find any place in Code::Blocks to specify a custom command line, you could try adding it to your CXXFLAGS environment variable.

I've had similar problems a few times, usually it ends up as an unholy mess of generics and reflection.

I think this is what you need.

http://www.libsdl.org/docs/html/sdlwmseticon.html

Your professor is correct.  Using a debugger to make poorly designed and written software just barely maybe work is lazy and an ineffective use of resources.

Using a debugger to analyze a problem or to learn how existing code works is appropriate use of the tool.  Using it in place of understanding a problem or instead of thinking through and designing a solution is not.

This is absolutely true. I remember when I was a young lad learning to program. I used the debugger a lot. Then one day I wanted to try and see how it is to do without all the fancy stuff, so I started a project using Emacs and GCC. Because GDB is pretty cumbersome to use in comparison to "some other" debuggers, I only used it when absolutely necessary.

Needless to say, I learned a lot from that project. Another way of thinking, you could say. A way of thinking that has helped me when coming back to the "fancy" tools. It's hard to explain exactly what I mean, but it has caused more defensive programming, and when something is wrong, a quick browse around the code is usually all it takes to figure it out.

For all people learning, I recommend doing some kind of learning project without too many "crutches" to try it out.

Remember that it can cause confusion that there are two different ways (that are completely unrelated) to sign assemblies. Using an snk file in the project options is called "strong name assemblies". This has nothing to do with the level of trust placed in the assembly, it's just a way of making sure the assembly "name" is unique. This is not what you want, if I understand your request properly.

If you want digital signatures with trust (and from your first post I gather that you do), you need to use a certificate obtained from someone like Verisign and use it with the tool linked in my previous post.

In general, it's bad practice to require admin priviliges, unless your app is for some kind of system configuration.

If this is the case, you can do it in the manifest: http://msdn.microsoft.com/en-us/library/bb756929.aspx