I'm using sfml to write a game, and I thought that since I was working in Xcode I would make a Mac version and a windows version. In the mac verision I thought that it would be nice to take advantage of NSMenu to make a menu for the game. Here's what I've tried so far in a file called main.mm:
#include <iostream>
#import <AppKit/AppKit.h>
void Launch()
{
NSMenu* menu = [[NSMenu alloc] initWithTitle:#"string"];
}
int main()
{
std::cout << "Mac main\n";
Launch();
}
The code doesn't compile. Xcode doesn't show any errors in the code itself. Any idea why this doesn't work?
You must return from main. Also, you should call NSApplicationMain() if you are using AppKit. For games, this means that you write your game in C++, and you call the C++ code from Objective-C classes.
int main(int argc, char **argv)
{
std::cout << "Mac main\n";
return NSApplicationMain(argc, argv);
}
To call into your C++ code, I would create an application delegate and launch your C++ code from -applicationDitFinishLaunching:. You can create the application delegate in your main nib file, as well as your menus.
I don't know how to integrate with SFML. I would either use NSMenu and AppKit, or use SFML and avoid Objective C.
Related
I have the following code:
#include <iostream>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/core/core.hpp>
#include <opencv/cv.hpp>
using namespace std;
using namespace cv;
int main()
{
Mat image(200, 200, CV_8UC3, Scalar(0, 255, 0));
namedWindow("Displayimage", CV_WINDOW_AUTOSIZE);
imshow("Displayimage", image);
int key = -1;
while (key!=27) {
key = waitKey(0);
cout << key << endl;
}
return 0;
}
When I run it on Windows (CodeBlocks + minGW) and press "Shift" -> nothing happens and give different codes for "a" and "A" --> Good
When I run it on Linux/Ubuntu (CodeBlocks + GCC) and press "Shift" -> it returns a code for the Shift key and does not allow me to press "SHIFT+a". It always return the same code for "a" and "A".
Do you have any idea?
Thanks,
The implementation of the cv::waitKey(int) function is quite dependent on the underlying UI framework. For windows OS, common window display frameworks include .Net, QT and MFC. While in Linux distributions, the window display frameworks usually include GTK, QT, VTK and etc. You can find different versions of waitKey(int) implementations is the highgui module of OpenCV source, and the gtk version seems not to handle keystrokes combination, it's handled by using GMutex. So if you want to handle key combinations, you might have to change your UI framework or modify the implementation, and recompile your OpenCV with the selected UI framework.
I created a Visual C++ project, and made a button in the form. Visual Studio generates this method for a button click event:
private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) {
}
This code is in the Form1.h file, no problems for now. However, if I try to call a function, in the event method, using other classes, like std::cout (doesn't matter if I define it in the Form1.h file or I #include it from another file), the compiler gives me an error (C2079).
Why does this happen? Please be patient as I am a total noob in Windows GUI programming, thanks in advance to whoever can help.
Well, there's an explanation that's part of C2079. It's something like 'identifier' uses undefined class/struct/union 'name'. This is NOT related to either Windows or GUI programming. The problem is simply that you must have defined the name you're using.
For instance, std::cout is defined in <iostream> which you probably did not include. BTW, exactly where did you expect std::cout to print to? A normal GUI doesn't have a text console.
I have a global enumeration
enum class CColour{
BLACK,
WHITE,
GOLD
};
that has its own headerfile CColour.h wich is included in stdafx.h
I was trying to fix some bugs (EDIT: I'm done with that) and encountered the following:
#include "stdafx.h"
using namespace System;
int main(array<System::String ^> ^args)
{
[...]
CColour colour1 = WHITE;
[...]
}
I've set a watch to colour1 in Visual Studio, and I have some other functions using CColour too, but in the watch it is always displayed as <undefined value> with no type specifier. (and a small lock next to the icon, don't know if that's relevant)
this seems strange because every function that uses CColour works perfectly fine.
can anybody explain why that is and how to fix it?
I'm developing a Qt 4.8.4 GUI application targeting Windows 7. I'm trying to implement the "Solving a Problem Step by Step" approach to keep the GUI responsive during a long-running computation, which is nicely divisible into many small steps.
Here is a minimal working example of this technique:
Computation.h
#pragma once
#include "QtCore/QCoreApplication"
#include "QtCore/QDebug"
#include "QtCore/QObject"
#include "QtCore/QTimer"
class Computation : public QObject {
Q_OBJECT
public:
Computation() : amount_(0) {}
public Q_SLOTS:
void start() {
amount_ = 100000;
QTimer::singleShot(0, this, SLOT(calculate()));
}
private Q_SLOTS:
void calculate() {
if (--amount_ > 0) {
qDebug() << "Calculating..." << amount_;
//QCoreApplication::processEvents();
QTimer::singleShot(0, this, SLOT(calculate()));
} else {
qDebug() << "Finished";
}
}
private:
int amount_;
};
main.cpp
#include "Computation.h"
#include "QtCore/QDebug"
#include "QtGui/QApplication"
#include "QtGui/QMainWindow"
#include "QtGui/QPushButton"
int main(int argc, char* argv[]) {
QApplication app(argc, argv);
Computation computation;
QMainWindow window;
QPushButton button(&window);
button.setText("Test");
QObject::connect(&button, SIGNAL(clicked()), &computation, SLOT(start()));
window.show();
return app.exec();
}
There's also a CMakeLists.txt for this example in case anyone wants to try it out.
Now, on to the actual problem: when the computation is running, certain GUI interactions lead to a lockup of the mouse. The cursor can still be moved, but clicking on any part of the desktop has no effect at all in this state. The computation still goes on. The only way to escape this lockup is to switch to another application with the keyboard (e.g. Alt+Tab, pressing the Windows key, or Ctrl+Alt+Del) or to wait until the computation has finished.
The GUI actions which lead to this state include attempting to move or resize the application's main window. Instead of changing the window's geometry, the mouse lockup explained above happens. However, the window instantaneously jumps to the position is was to supposed to be moved to as soon as the computation finishes (and you didn't switch to another window in between).
Opening the system menu (by clicking on the application symbol in the title bar) also leads to similar behavior, but this time only the application (including the system menu) is indifferent to mouse clicks.
I tried to work around this problem by issuing QCoreApplication::processEvents() in my calculate() method (commented line in the above example). This only helped a little: instead of locking up the mouse every time one tries to move or resize the window, you now have to do it about 3-5 times to trigger the behavior. Different combinations of QCoreApplication::sendPostedEvents() and QCoreApplication::flush() didn't help either.
How can I solve this problem? Is this a known Qt bug and/or is there a workaround?
If you need to make an application multi-threaded, you can use Qt's slots and signals architecture. Just emit a signal from your thread when something changes. Then in your UI thread, connect a slot to the signal from your thread:
Qt: Background thread refreshing UI thread
Using QThread is definitely a better strategy than chunking the computation and trying to do everything in one thread.
Then in the calculate thread, use a timer every 1/15 sec (for example) to call a signal that has been connected to a slot in the main thread, which informs the UI to update any data you want to see from the calculations.
I am debugging an issue for my app in iOS 4 and above where it doesn't appear to save progress when it's closed. I'm using Xcode 4.0 and running it in the simulator, and, when I close the app in the simulator, remove it from the background apps bar, then relaunch it from the simulator, it appears to break in the retval line below:
int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
It cites "Thread 1: Program received signal: "SIGKILL" and I'm not quite sure what to make of it (also I'm just minutes new to using Xcode 4).
Can someone explain what's going on here, whether I simply can't debug once I stick an app in background (and/or remove it), or whether this potentially points to my issue with saving progress? I basically trigger the save when my main delegate receives:
- (void)applicationWillTerminate:(UIApplication *)application
You should save in applicationDidEnterBackground:, not applicationWillTerminate:. When an app in the background is closed, it is killed without sending applicationWillTerminate: (this is the SIGKILL you are getting). However, if you are supporting devices or versions without multitasking, you will need to save in applicationWillTerminate: also, since it is used in those circumstances.