GUI Console

[Ashishm1995]

I have created many console applications with that boring black screen.
Does C++ console application support GUI.
If the answer is yes can you please help me.
Note:-
I dont want to use windows forms application template in Visual C++ .NET or any template like that.

[firedraco]

No, consoles do not support GUIs AFAIK.

[Bazzy]

Using VC++, with windows API you can create a window with a console program, but why would you do that?

eg:

LRESULT WINAPI WndProc(HWND hWnd,UINT Msg,WPARAM wParam,LPARAM lParam)
{
    if ( Msg==WM_DESTROY )
        PostQuitMessage(0);
    return DefWindowProc(hWnd, Msg, wParam, lParam);
}

int main()
{

    cout << "Hello World";

    HINSTANCE hInst = GetModuleHandle(0);
    WNDCLASS cls = { CS_HREDRAW|CS_VREDRAW, WndProc, 0, 0, hInst, LoadIcon(hInst,MAKEINTRESOURCE(IDI_APPLICATION)), 
        LoadCursor(hInst,MAKEINTRESOURCE(IDC_ARROW)), GetSysColorBrush(COLOR_WINDOW),0,"Window" };
    RegisterClass( &cls );
    HWND window = CreateWindow("Window","Hello World",WS_OVERLAPPEDWINDOW|WS_VISIBLE,64,64,640,480,0,0,hInst,0);
	
    MSG Msg;
    while(GetMessage(&Msg,0,0,0))
    {
        TranslateMessage(&Msg);
        DispatchMessage(&Msg);
    }
    return Msg.wParam;
}

[Duthomhas]

On Windows, the only difference between a Console and a GUI application are whether or not they have the windows console automatically attached to the standard I/O.

If you want that console attached to your GUI program, then Bazzy's example should get you going. (That is, start out as a console program and create and use your GUI windows.)

It is also possible to request a console attachment to your GUI application, but that requires that you attach the standard handles to it. For that, see the article at
Adding Console I/O to a Win32 GUI App
http://www.halcyon.com/~ast/dload/guicon.htm

Good luck!

[writetonsharma]

create win32/MFC application in vc++, this will create a gui application.

[Disch]

Or better yet

http://www.wxwidgets.org

cross-platform, ftw.

Shake the 'code for Windows' bug early by never getting bitten by it. If you get too used to WinAPI it can be a chore to leave and relearn something else. (not to mention WinAPI is a huge pain to work with -- especially if you want an OOP design).

Even if your only target is Windows and you never have any intention of coding for anything else, I'd still recommend .NET over WinAPI, as it's where the future of Windows is heading, and is at least somewhat portable through Mono. WinAPI is dying fast -- avoid it.

IMO

[writetonsharma]

Disch:

i personally dont like to program on windows but i have a couple of comments on your views...

I think we are talking about C and C++ here and .Net is nowhere near to C++. its weird to program and many times slow as compared to C/C++ or for that matter to win32/MFC.

secondly, .NET/C# is getting popular but if project requirement is to use C/C++ then no one will use .net. so you cant say win32/MFC is dying fast. it depends on requirement. .net cant give optimized applications.

[Duthomhas]

I agree on using wxWidgets or FLTK or Qt or somesuch.

I disagree about .net and Win API. All systems have their equivalent API, which must be used to program that system. A good toolkit is nothing more than an application layer over those APIs to make life friendlier for the programmer.

If .NET takes over, Windows will die. .NET is nothing more than an overblown OO framework over the Win32 API. Application code may be portable, but system code can never be.


As to GUI consoles, the Win32 Console is a "special" process which doesn't have a window procedure (well, that anyone can access anyway).

There are other ways of going graphical. Borland's Turbo Vision is a prime example. For the modern user, I recommend you check out the curses library.

PDCurses
Win32, DOS, OS/2, etc.
http://pdcurses.sourceforge.net/

NCurses
Unix/Linux/POSIX
http://www.gnu.org/software/ncurses/ncurses.html

Here are a bunch of great links for getting started with curses.
http://en.wikipedia.org/wiki/Ncurses#External_links

Just another thought.

[Disch]

writetonsharma

I think we are talking about C and C++ here and .Net is nowhere near to C++.

I don't know about C, but it is certainly possible to use .NET with C++. I believe the common term is "managed C++".

All systems have their equivalent API, which must be used to program that system.

For Windows, in the semi-near future, this is likely going to be the .net framework. Win32 API support likely only exists in current Windows releases to retain backwards compatibility. Some day, WinAPI support will no longer be native, and will actually be emulated by an underlying .net infastructure (if supported at all).

secondly, .NET/C# is getting popular but if project requirement is to use C/C++ then no one will use .net

I agree you should use whatever platform your employer or teammates are using and should meet whatever requirements are set out. Obviously if the requirement for a project is to use C and WinAPI, then that's what you should use.

so you cant say win32/MFC is dying fast

When's the last time they were officially updated? (and remember when answering this question -- think about how long ago that was in computer years. They're dinosaurs.)

How come virtually everything MS has released in the past few years have been .NET based or .NET oriented?

Why would MS invest time and money in maintaining something that ultimately only competes with their frontrunner and doesn't come anywhere near it in terms of functionality?

Obviously professional companies may still use WinAPI because they use whatever is most cost efficient (if they already have a staff of programmers that know WinAPI, they're not going to invest the time/money in switching to a foreign API unless absolutely necessary).

.net cant give optimized applications.

I was hoping to avoid this turning into "code run through a VM can't possibly run as fast as a natively compiled program" since that's quite a hot topic. All I'll say on this matter is that smart VMs are getting better and better... and computers are getting faster and faster. And making the claim that Java/.net can't possibly be as fast as C++ is very risky.

And who's to say the next "big thing" in computer hardware won't be a processor that natively processes .net bytecode? Maybe this is how MS plans to finally break free of the crippling x86 chain they've been stuck to for the past 15 years (talk about a dinosaur).

Don't get me wrong. I'm still a big fan of C++, but it certainly isn't the only language that offers high-performance.

Duoas

If .NET takes over, Windows will die. .NET is nothing more than an overblown OO framework over the Win32 API.

Currently this might be true (though I'm not sure I buy that). But like I say, in the future, this seems very likely to change.

At any rate this statement is silly for a number of reasons. MS still holds the market and is actively keeping pace with the development world. They're not going to just die.

Application code may be portable, but system code can never be.

I guess my point is that you seem to be stuck in thinking that WinAPI has to be the system API for Windows. IMO, that's an ill advised standpoint.

The writing is on the wall if you look for it. MS is doing everything it can to get away from their archaic API and move towards .net without destroying backward compatibility. And it looks to me like they're doing it very effectively. Look at what they've been doing:

- .NET framework comes bundled with the OS
- All their commercial releases use .NET
- The latest DirectX is incompatible with older versions of Windows (no logical reason for this other than to force game developers to target platforms which are guaranteed to have .net installed)

They're basically saying: "Start using .NET or leave Windows"

The chances that they abandon .NET after all this and "fall back" to WinAPI is nill. And they'll only support both for so long. One of them is on the way out. I know which one I'm putting my money on.

[Bazzy]

When's the last time they were officially updated? (and remember when answering this question -- think about how long ago that was in computer years. They're dinosaurs.)

Last version of MFC was released in 2008


PS: if the Express edition of VC++ provides .Net but not MFC there should be a reason...

[Disch]

heh.. touche -- admittedly I wasn't sure about MFC.

[kbw]

.NET is definitely in vogue at the moment, but I remember when the same could have been said about DDE, OLE, OLE2, COM\DCOM, COM+.

If you add .NET to the end of that list, they capsulate the aims of the previous technology. Plus there's a litany of discarded technologies (anyone remember Connection Points, MailSlots, ...?)

By all means, use .NET, there's a lucrative living to be made from it, but don't think of any of these technologies are here to stay, or can be credited with "the future".

[writetonsharma]

i can ask the same question.. when was C or C++ updated???

long back.. so should we stop using them?? :D

secondly, microsoft technologies comes fast and they die faster.. as kbw said.. there was a time when com, dcom and com++ were hot... where have they gone..

if someone has used .net.. even a dialog box takes ages to come on the screen..

but i agree on one point what Disch said .. .NET is the future of Microsoft.. but not for me :)

[Duthomhas]

I guess my point is that you seem to be stuck in thinking that WinAPI has to be the system API for Windows. IMO, that's an ill advised standpoint.

No, you're quabbling with semantics.

If there exists an OS where .NET is the underlying structure, then it will be the API.

Windows, however, is not an OO framework. It is a DLL framework -- and the current architecture cannot natively support an OO framework. Hence, .NET is layered on top of the Win32 API. And yes, it makes programming some things much easier, but it isn't a panacea -- no matter how much MS or anyone else would like it to be. I didn't say it was bad.

Simply stated, Windows would need to be completely redesigned to get rid of the Win32 API in favor of the .NET framework. That is not good business. MS makes billions in existing software and compatibility.

Finally, you have tried to make the argument a false dichotomy, which is a logical fallacy. Both Win32 API and .NET will be around for many years to come.
- 1. Microsoft supports .NET with its OS because it makes money providing a powerful framework to easily work with OO languages on its architecture.
- 2. Why would MS not use their own .NET framework? Again, the whole point is to make it easier to consider the OS in an OO framework.
- 3. DirectX incompatibilities has nothing to do with .NET. It has to do with underlying changes to the way the OS manipulates the hardware. Using .NET is not causal -- just a convenient tool for MS as for other developers.

The very abstraction represented by .NET is the basis of all computer programming. It is a Good Thing. But it is not the only One True Way.

And making the claim that Java/.net can't possibly be as fast as C++ is very risky.

No, it is quite solid, but also stupid because raw speed for an application framework misses the point. MS is not a realtime OS.

Why would MS invest time and money in maintaining something that ultimately only competes with their frontrunner and doesn't come anywhere near it in terms of functionality?

You do mean "ease of use" over "functionality", right? (Seeing as .NET is implemented atop the Win32 API.) They invest time and money because it makes money, because it is easy to use in OO environments and because it encapsulates more complex operations in simple ways.

[edit] Argh, hit "Submit" when I meant "Preview"

I think the problem is that you are too easily caught up in the "only the best is right" mentality. In real life business, you use what works. Wasting time on an ideology is not productive.

So please just relax and stop attacking my views with religious zealotry. I'm not a fan of .NET. That doesn't make it evil -- nor have I ever said anything remotely approaching that thought. I have not ever said you are stupid or that your opinion is foolish. Please afford me the same courtesy.

[writetonsharma]

point taken. :)

[Duthomhas]

Ack! Sorry, I hope you didn't take that as an attack on you. You aren't stupid.

I just tire of half-truths being spread as gospel, so to speak, and people often repeat them without thinking. I do enough thoughtless thinking myself... I actually came back to apologize for my tirade. Sorry I got miffed for the response against my provocative, anti-.NET statement. Alas. :-(

Thanks for being kind. :-D

[writetonsharma]

hahahaha...

but whom you are saying sorry to?? the last post was mine.. but i dont think you should apologize to me.. i was in support of anti .net people from the very beginning of the discussion!!!

[Duthomhas]

Heh, yes I know. I was just just trying to make sure you didn't take my native-vs-VM code comment as a personal attack (which it wasn't).

:-)

[Disch]

Well I didn't take offense by any of that either. ^^

Obviously I can't really predict the future, but if I had to bet on it, I know where I'd put my money. MS seems to be pushing .net as hard as is possible without destroying their market.

I didn't want to give the impression that I was spreading gospel (as Duoas put it). Perhaps I shouldn't have spoken in such an absolute tone originally, or maybe I should have qualified every statement with "imo". Sometimes I get very opinionated and forget to tone it down for the sake of civility. I apologize for that. I didn't mean to offend anyone here, nor do I think any of you are stupid (quite the opposite in fact -- I have a lot of respect for the regulars here. So knowledgable!)

Windows, however, is not an OO framework. It is a DLL framework -- and the current architecture cannot natively support an OO framework. Hence, .NET is layered on top of the Win32 API.

I guess I don't see why an OO framework and a DLL framework have to be mutually exclusive. The .net framework's API is very OO, yet I'm sure its implementation is spread across several DLLs.

Currently, .net is layered on top of WinAPI, sure. But will that still be the case 7-8 years from now? If I were MS, I'd try everything possible to shift towards a fully .net geared environment. I don't think this is an unreasonable goal for them... they've already strongarmed most of their userbase into installing the .NET framework, and have recruited a significant portion of the development world with their introduction of C#.

It wouldn't surprise me at all if future versions of Windows run .net natively (or at least as natively as the underlying hardware allows*) and WinAPI is implemented as a layer on top of it as legacy support. As soon as something like this happens... coding in WinAPI not only means you're opting for a less friendly and non-OOP API, but you're also not getting any performance boost out of it. But again -- this is speculation as to what the future holds. I know this isn't the case yet.

* I already touched on this point before, but as for the hardware comment -- x86 has been around a long time purely out of necessity (because Windows uses it, and because Windows is so popular -- they're forced to stick with it or break backwards compatibility, which as has been mentioned, is very bad for business). Because .net gets compiled to bytecode and not native assembly, this might be MS's way to break out of the x86 shackles and switch to a more modern architecture. They might not get something which runs .net bytecode natively, but they might get something which has a bit better performance. There are reasons virtually every non-PC computer that is released (phones, video game systems, mp3 players, etc) all tend to use "anything but x86".


As for the VM vs. native topic -- I've gotten in quite a few debates about this before. It isn't really a topic which concerns me much, as most programs are "fast enough" so that whatever minor speed difference there is between them generally goes unnoticed by the end user. And in my experience, CPU speed isn't what tends to bottleneck the program anyway.

Anyway it dawns on me that I mostly just repeated what I already said XD. So I guess this post wasn't really necessary. Oh well.