(its a long story) but I have a large complex project file containing a windows program. Unfortunately the project was originally built as a console app. The program compiles and links ok but when runs brings up a console instead of the collection of windows I was hoping for. I looked at the command line and saw "/SUBSYSTEM:CONSOLE" whereas it should be "/SUBSYSTEM:WINDOWS". I have no idea how to change the command line. Is there some box I can tick in the project setting somewhere to make this change?
Right-click the project icon in the Solution Explorer, then Properties > Linker > System > SubSystem, and set that to Windows. You'll also have to change your main() method to WinMain(). And you'd better create some windows or there won't be much to look at.
Complementing Hans' answer: While under Properties, also remember to expand the C/C++ node and select Preprocessor. Then edit the Preprocessor Definitions - replace _CONSOLE with _WINDOWS.
Related
I am building a C++ OpenGL card game in Xcode 4.3.3, with the intention of running it on both 64-bit and 32-bit Macs, which is not my problem. My problem is that I have reached a point in the development of the program where I would like to test that it works on a different 32-bit Mac (mine is 64-bit) without having to install Xcode. This, obviously, requires me exporting it as an .app. I can find and run the exported Unix Executable File from my project, after some cd'ing, through Terminal, but that is undesirable for me and the intended audience of the program. I have trawled the google and Stack Overflow, looking for anything to help me, but all the things mentioning Archiving seem to have been unsuccessful with my particular project, and I think that's because it's a C++ command line tool project. So, can someone please help me export my project as a .app?
Thanks in advance.
The simplest way of doing this would be to create a Cocoa project, go to 'build phases' and remove all the objective-c frameworks from the 'link with libraries' build phase, remove any objective-c files added by the template (app delegate, etc.) and then replace main.c with your main.cpp file.
There's nothing really special about a Cocoa project except for the fact that it links against Cocoa and calls NSApplicationMain() from its main() function.
There are also a bunch of .plist entries used by Cocoa which you'll no longer need. But they won't affect the way OS X treats your application.
I'm searching for an XCode Settings solution but here's my current way to create an app:
You have to take your binary file (let say myapp) and put it in "MyApp.app/Contents/MacOS/myapp" then it can now be launched as a .app. That's a trick.
Just go to the targets folder in the file navigator on the left, and there will be an executable listed there. Left click on that executable and click "show in finder". (I'm describing from memory so I may have the exact details wrong.) The file path is ridiculously long (there is an arbitrary alphanumerical pathname involved, I have no idea why), so you probably won't be able to find it with the command line.
If you want you can change the extension of the file from nothing to ".app", it shouldn't affect the nature of the file at all. Also if you want a custom icon, you can "get info" on it in the finder, then click on the icon in the info window, and use Cmd-V to paste it in (obviously you have to have your icon copied to the clipboard). There is also a way to do this inside of Xcode, but I don't remember it.
What and how should I install in order to be able to create an ordinary console project in Visual Studio?
Here is what I have already installed and what options I have. The problem is that there is no option for creating an ordinary console project. Is it named somewhat different not just a console project in cpp?
Look under the "Installed" tab on the left side, not the "Online" tab you currently selected. You should find "Win32 Console Application" there.
I recommend to use 'Empty project' option for such purposes. Just type 'Empty' in the search field to find it.
In this case you have to manually add .cpp file, define a main function - and you will have simple console application with no Windows-specific overheads.
I'm new to wxWidgets. I'm using Code::Blocks (MSW compiler), version wxWidgets-3.0.2 on Windows 7.
I started learning this, but I got stuck when I found out that I couldn't develop a good looking wxButton when I write the codes myself without using wxSmith.
All I get as output are flat wxButtons and toolbars that look like buttons. I thaught it was my fault, then I created a little frame with wxButton in it, then compiled. The output suits my taste.
I copied the exact code for this little frame and created another project file without wxSmith and I pasted them in their corresponding file. When I compile this same code, all I get is a flat wxButton.
If I hover the mouse over it, it won't turn blue as it does in wxSmith compiled code. I also noticed that anything, e.g, toolBars that is likely to be clickable, will look flat, but not menus.
What am I missing?
It seems like you need to add the manifest to your application. The manifest is the thing that describes your application needs to system: what visual style you want to use, which OS are your app compatible with, etc.
The most simple way to do it with wxWidgets is to add a resource file (*.rc) to your project (or if you already have one then edit the one you have) and put this line of code there:
#include "wx/msw/wx.rc"
You may need to change the path to wx.rc file depending on your project settings. File location is:
<wxWidgets directory>\include\wx\msw\wx.rc
wx.rc will include correct manifest based on your build type:
x86 -> "wx/msw/wx.manifest"
x64 -> "wx/msw/amd64.manifest"
ia64 -> "wx/msw/ia64.manifest"
If you don't want to use wxWidgets default manifest files, then you need to:
create a file name your_app_name.exe.manifest (or your_dll_name.dll.manifest) and fill it manually (you can find description of application manifests and an example here: MSDN: Application Manifests (Windows);
place this manifest file in the folder with your executable file (just to be clear, if your app name is MyCoolApp.exe, then manifest must be named MyCoolApp.exe.manifest) or embed manifest into executable with mt.exe tool (mt.exe is shipped with Visual Studio, you can find the tutorial on how to use it to work with manifests here: MSDN: How to: Embed a Manifest Inside a C/C++ Application.
My application displays a grid of images. When the right mouse button is clicked a context menu is displayed where the first option is "Show in Explorer".
I was able to launch the default explorer on the directory by using:
QDesktopServices::openUrl(QUrl::fromLocalFile( directory ));
However I want also the file to be selected.
Is this possible? I suppose it should be, as many apps can do that.
openUrl is not suitable here. You need just start another process (with QProcess start or startDetached) with Windows explorer special arguments:
explorer.exe /select,"C:\pathTo\file.txt"
Ok, I want to thank #Chernobyl for his useful help.
However I've found a general solution posted here:
How to "Reveal in Finder" or "Show in Explorer" with Qt
It wasn't compiling at first because the QtCreator code is using a class called Environment which I tried to add to my project but that file then also includes others, etc. I checked and they are using it just to see if explorer.exe can be found on the system path. It was not so important (to me) so I removed that check and then I tested it. It's working perfectly. It's also supposed to work for Mac and Linux.
Using Visual Studio 2010, coding in C++:
So I've got a solution and two projects: Project 1 is a Windows application meant to act as the GUI for the program, while Project 2 is a console application meant to interact with some external applications.
I want to create a button in Project 1 that when pressed executes Project 2. What's the simplest way to do this? I'm thinking of just running Project 2 through the Command prompt with a "system("Project2.exe");" kind of approach, but I don't know how to reference a project executable instead of an external, already existing executable.
I'm pretty new to C++ and Visual Studio in general so I could be missing something obvious here, sorry. Thanks for your help!
If you want to run another program(even your other project or some unrelated executive that you get from your last traveling to moon) you should now the path of other project in either absolute or relative form or it should be in the path.
So in your system that you know the path, you can hard-code it in your source file, for example system( "C:\\path\\to\\my\\application.exe" ) or system( "..\\project2\\output.exe").
And in another system you have 3 options:
Put your project2.exe in the PATH by either adding its path to the system PATH or copy it into a folder that is already in the path like system folder
By using a setup copy it into a predefined folder( usually relative to project1.exe ), for example in the same folder or ..\\server\\project2.exe
Create a config file that user can put the path of executable of project2.exe in it
can you change project 2 to build as a class library, so you can just use that dll in your project 1?
I think what Mike said is the better way but I guess you'll encounter the same problem here. You have to define "Project Dependencies". Right click on project 1 -> Project Dependencies -> Select project 2. Now Project 2 gets compiled before project 1. (You have to do the same for libs if you decide to go that way).
If you want to move a file after compiling it you can define a post-build event in your properties. (Configuration Properties -> Build Events -> Post-Build Event) There you can copy a file by defining for example a command like xcopy /y "$(ProjectDir)Release/myexe.exe" "Some path"
Other than as mentioned by Mike Corcoran, you can also use any external program if you put it into the system's PATH variable and then have it executed by system(const char *) function
Driving it this way is passable, but its not the correct way. For example, if your program was interactive it would fail instantly or have an UB(undefined behavior). To avoid this, separate the logic of the program from the input/output and work your way around it in your code.
Some successful Linux programs have managed to get the output of the console application and display it on the GUI(having you to interact with it internally). Even Visual Studio does this - the output you see when you compile your applications such as "successful build" etc etc is executed in the command line and then the output of it is redirected.
Good luck.