I need to create a windows application in C++ and it has to show just a TaskDialog (see http://msdn.microsoft.com/en-us/library/windows/desktop/bb760540(v=vs.85).aspx ). The TaskDialog should show a text passed as parameter to the command line.
I can make a "Win32 Console Application" and call TaskDialog but then I will see the black windows of the console.
I can make a "Windows Application" and just calling TaskDialog inside WinMain, is there any problem with this solution?
Any other idea?
I can make a "Windows Application" and just calling TaskDialog inside WinMain, is there any problem with this solution?
That is the way to implement such an app. There is no problem with it all. Of course you don't create a window explicitly in your code and you don't run a message loop. Just call TaskDialog.
The main point is that you don't want a console app because, as you have discovered, a console window is shown by default. There are two main subsystems, the console subsystem and the GUI subsystem. The latter is somewhat confusingly named. You are not compelled to show GUI in a GUI subsystem app. It's up to you whether or not you choose to do so. Really the choice comes down to whether or not you want a console. So the subsystems could be better named as console and non-console!
You have to create a empty windows application.
The entry point of a windows application is calles WinMain and looks like this:
int WINAPI WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance,LPSTR lpCmdLine,int nCmdShow)
{
//Place your code here
}
This means your solution is correct. You just have to make sure that your application uses version 6 of Comctl32.dll. Otherwise TaskDialog will fail.
Related
I am running a C++ console application,
for some period of time,
I want to minimize the window in which my application is running.
for eg. I launch myApp.exe from cmd. Then its launched in new window.
So what are libraries which can minimize the window in which application is running.
Application doesnt have any GUI
I suppose your application is running on Windows (this is not portable across different operating systems).
You have first to get handle of your Console window with GetConsoleWindow() function, then you can use ShowWindow() to hide/show it as required. Ddon't forget to include windows.h:
ShowWindow(GetConsoleWindow(), SW_MINIMIZE);
Instead of SW_MINIMIZE you can use SW_HIDE to completely hide it (but it'll flash visible once when application just started).
Note that if you have control over process creation you can create it as DETACHED_PROCESS: a detached console application does not have a console window. CreateProcess() function has also other workarounds you may be interested in (for example you may create a child process for outputting...)
UPDATE: as follow-up of Patrick's answer you may change the subsystem from Console to Windows and then, if you require to write to console, create a new one using AllocConsole:
if (AllocConsole()) {
printf("Now I can print to console...\n");
FreeConsole();
}
Another option is to change
Properties... | Configuration Properties | Linker | System | Subsystem
from Console to Windows.
However, you then need to add a WinMain() entry point, such as:
int __stdcall WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{ int argc = 0;
LPWSTR* argv = CommandLineToArgvW(GetCommandLine(), &argc);
return Main(argc, argv);
}
assuming unicode. To avoid confusion, I rename the console's wmain() function to something like Main(), as above. Of course printf no longer has a console to write to.
I just started learning programming for windows in c++. I had this crazy image, that win32 programming is based on calling windows functions and sending parameters to and from them. Like, when you want to create window, you call some win32 function that handles windows GUI and say "Hi, please, create me new window, 100 x 100 px, with two buttons", and that GUI function says "Hi, no problem, when something happends, like user clicks one button, I will change this variable xy located in this location".
So, I thought that it will be very similiar to console programming. But the very first instruction surprised me. I always thought that every program executes main() function first. So, when I launch app, windows stores some parameters on top of stack and run that application. So I assumed that initializing main() is just a c++ way to tell the compiler where the first instruction should be.
But in win32 programming, there is function called WinMain() which starts first. So I am little confused. I thought it´s rule that compiler must have main() to start with, that main just defines where it starts, like some start point identifier.
So, please, why is there WinMain() function instead of main()? When I thought that C++ programming is as logical as assembler, it confuses me once again.
main() is as arbitrary an entry point as WinMain() is. The standard only requires a function named main for consistency. The entry point (whether it's main or WinMain) is actually called by a hidden function that is the real entry point. On some platforms that "real" entry point is called something like _start. It's that function that does all of the initial work like initializing globals, setting up the environment, etc., and then it calls main(). On Windows, that start function happens to call WinMain() if available.
Edit: check out this answer for a more detailed explanation.
To understand how Win32 application works requires additional effort compared to usual console application.
"I had this crazy image, that win32 programming is based on calling windows functions and sending parameters to and from them"
my hints ...
1 )True , but also windows message that are the beats of a Windows Application , some example include WM_CREATE, WM_MOUSExx , WM_KEYxx , WM_PAINT where xx can be DOWN UP and so on .
Messages are sent to your application by Windows itself , it is up to you to define a specific function to trap them (the "WindowFunc").
There are hundreds of messages, luckily is not necessary to understand all them at first .
2) Every widget you can imagine to create in your app is a "Window" , and you can create Windows by CreateWindow function .Each window will be identified by a 32 bit integer value the so called Window Handle (HWND)
3 There are so many different class of windows as you can imagine (mainwindow , clientarea , edit, button) both available from the system and also created by yourself...
Windows are different as they belong from different WindowClass ...
To define a WindowClass you have to fill a WNDCLASS c structure and call RegisterClass
A field in the struct is a pointer to the WindowFunc
4 The WindowFunc is a function that takes 4 input parameters (HWND,WM_XX,wParam,lParam)
That function will be called from the system as soon as something happens regarding that window (HWND)
said that let me rewrite your statement
"Like, when you want to create window, you call some win32 function that handles windows GUI and say "Hi, please, create me new window, 100 x 100 px, with two buttons", and that GUI function says "Hi, no problem, when something happends, like user clicks one button,
...I will send you a message to the windowFunc as the user click... please check for the messagetype by yourself and if it is the WM_MOUSEDOWN you was waiting for then change the value for xy
What else ? i suggest to look at some simple sample in the sdk to get confident on how a win 32 app flow is
cheers
It is just a convention for native Win32 programs. You can easily change it, the MSVC linker accepts the /ENTRY:main command line option to change the entry point name to "main". You will however also have to change the signature of the main() function, it takes different arguments:
int APIENTRY main(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
// etc..
}
Which I guess was the point of giving it a different name 20 years ago.
You can check this article and another one from a microsoft developer. Briefly there're several reasons: the name are arbitrary, windows' WinMain required a different signature, and windows predates c++ standarization.
I'm writing a console program.
The program doesn't print anything.
So, it doesn't need to a console window.
I tried to call FreeConsole() function at program starting point.
When I execute the program from windows explorer, a console window appears and then disappears.
But I wish the console window never appears.
How can I do that?
Thanks in advance.
If you are using Visual Studio .Net then create a normal console application and change the output type to Windows application.
Use WinMain instead of main as your program's entry point: WinMain at MSDN
I know how to "hide" them. I know about FreeConsole(); and then finding the handle and changing it's attributes. However with these methods the window still pops up for a second than goes away. How can I stop it from showing up completely?
Have you considered creating a windows application (with windows subsystem) instead of a console application? That should hide the console window all together.
Try looking at WinMain
I believe you need to be a GUI application to not have the console displayed. Check out /SUBSYSTEM:WINDOWS
I have a written a Visual C++ console application (i.e. subsystem:console) that prints useful diagnositic messages to the console.
However, I would like to keep the application minimized most of the time, and instead of minimizing to the taskbar, appear as a nice icon on the system tray. I would also like to restore the console when the system tray icon is clicked.
How should I change my program to do this?
This is going to be an ugly hack.
First, you have to retrieve the hWnd / hInstance of you console application. Right now, I can only come up with one way:
Create a Guid with CoCreateGuid()
Convert it to a string
Set the title of the console window to this guid with SetConsoleTitle()
Find the hWnd of the your window with the Guid as the tile with FindWindow()
And you can do it from the usual way from this point. See http://www.gidforums.com/t-9218.html for more info.
Don't forget the rename your console window to the original title once you're done.
As you can see, even though this is possible to do, it's a horrible and painful solution. Please don't do it. Please do not minimize console applications to the system tray. It is not something you are supposed to be able to do in the Windows API.
You might want to write a separate gui to function as a log reader. You will then find it much easier to make this minimize to the tray. It would also let you do some other stuff you might find useful, such as changing which level of logging messages are visible on the fly.
To learn the console's hWnd you have two choices:
On Windows 2000 or later you can use the GetConsoleWindow() function. Don't forget to define _WIN32_WINNT as 0x0500 or greater before including windows.h to have access to this function.
If you want to run your program on earlier Windows versions as well then you must use something like the GUID trick described above.
Probably your best bet is to create a "Message-only window" (a message queue without a visible window) to receive the Notification Area messages.
The answer with a GUID is completely ridiculous (no sense at all)
The Console hWnd is of course given by GetConsoleWindow() (!)