Detecting keypresses when application has no focus - c++

I have an application that lives in the tray, and I need to detect the user activity so that I can perform certain tasks. For windows, I know that I can use GetAsyncKeyState or SetWindowsHookEx, but I would like to have a cross-platform solution.
Does anyone have a solution for this? maybe a reimplementation of keyPressEvent? Or would it be easier to just setup some macros and do it separately?

This is inherently platform specific.
I'd make sure to isolate whatever you do and separate the mechanism of capturing the event and recording the keystrokes from the consumption of those keystrokes. That way you only have to implement the capture/record mechanism on each platform and all of the other code should be pretty portable.
You may want to take a look at what SDL has done here. http://www.libsdl.org/
They have managed to abstract off all of that sort of thing, not just keyboards.

Related

Best Practise for GUI development for vanilla C++ application

I want to know about developing of gui to vanilla C++ application. I have experience in mostly in command line application. My experience in C++ gui till now is cout and cin. I have some experience in WPF (just to mention that I do have some gui experience) I hope this will describe my level of experience with gui. Now,I want to develop an application which needs separate GUI with possibility of 3D display. Of course, one of the choice for GUI API is Qt.Also,after reading lots of stuff on internet, i think code separation would be really helpful in future.
So, here goes my question: Is it possible if I keep my logic as generic as possible (not using winapi or qt in my logic) and make only GUI part API specific (say winapi or qt). Or I will need to add some code in my logic section, say for synchronization between logic and GUI. One can say signal and slot from qt is possible but as far as i know signals and slots are qt specific. they are not standard C++.
In summery,my question is can i make my logic in standard C++ (to stay platform/ framework independent) and only design platform specific GUI? If yes, could you please suggest a link or tutorial or book. A sample code or implementation would be 'a wish come true'. Also, some insights in code separation tactics would be quite helpful.
Regards!!
EDIT::
I will elaborate my problem. I have an application which has separate GUI and Logic section. The gui uses WinAPI and as the communication mode used is windows messages, previous user has created a HWND object in Logic which communicates to GUI. So, there is a HWND in Logic and HWND in GUI. I don't find this approach satisfying. One of the reason is that Logic part will be edited by non-programmers in later stage (not much. just modification of constants or changing implementation of function without changing para or return value). So, I just want to keep logic part in standard format (as much as possible). So once again, could anyone help me in designing business logic in C++ and GUI in any API.
After reading some threads, I found that answering own question is not a bad practice. So I will share the answer I have got.
There is no standard way to build a C++ gui application without using external dependencies. The synchronization between gui and logic part is always framework specific. So, if I want to develop a C++ gui application, I cannot put logic part in standard C++. It must have some code from external framework which will communicate the logic part and gui part. Having said that, I have found my way in by following method. I am going to put my logic part inside a static lib and then I will attach this lib to gui part. It will increase coding in gui section, but it will keep the base functions in standard c++. This way (a function lib in standard C++ and machine operation in framework specific code) will work for me. I hope I am on right track. :)
You can to a large extent write completely separate logic and GUI code in Qt. However you will be able to create a much more useful GUI if you allow the logic and GUI code to interact. Qt has it's own classes for a lot of things (QString, QVector<> etc.) but you're free to ignore these for the most part and use the standard library instead if you'd prefer.
However, I do not think that it is worth trying to separate Qt from the logic code entirely because, as mentioned before, you will be able to build a much better GUI if they interact. For a simple example you could write a very simple Qt GUI with just a window and a button; press that button and some logic code is run. However with more interaction you could use signals and slots to update a progress bar on the GUI to let the user know how far the logic code had got. Also Qt is very portable, allowing you to build your program for Windows, Mac and at least some Linux distros.
Also for your 3D display requirement I recently found myself trying to do a similar thing and found this example very useful - http://qt-project.org/doc/qt-5.0/qtgui/openglwindow.html.
I think that by default, you should aim to separate business logic from presentation (GUI) code. In web development, the most commonly used pattern is MVC, and it's principles apply equally to native applications.
However, this separation might be more difficult to achieve in native applications. Mainly because there are no frameworks such as Symfony, which have already solved these architectural problems, and make it easy to keep UI and business code separate by following the established conventions. I have't used Qt but from what I know it's mainly a GUI toolkit - models, views and controllers are not as well-defined and integrated.
Depending on the nature of the needed interface, a simple OpenGL GUI might suffice. This is what I did for a simple uni project. The project needed to display a shapefile colored according to statistics in an XML file. I created a number of GUI widgets - button, label etc, and a custom map widget which encapsulates "business logic". Perhaps I should have "cleansed" the map widget, making it as generic as possible, and move all business logic to a separate library, but considering the business layer was very thin I thought the added complexity would outweigh the benefits.
Another factor is your skill-set - current, and areas which you want to improve. I was more interested in OpenGL and freeglut, then in learning Qt. If I had known Qt, I would have used that.
I have done some projects with vanilla C++ and a QT GUI. The idea of not mixing any QT code into the pure C++ stuff is always good but takes a lot of fun out of it. Usually you end up with a much more elaborate GUI than you expected and would often like to connect it better/easier to your code. Signals and Slots are a really great way to let the GUI interact with your code, but then you start mixing...
TLDR: Think really hard about why you don't want to mix your code with e.g. QT. It would not meand mixing GUI and Logic, no way, but your life could be a lot easier using QT classes like QStrings, QProcesses or QThreads...
If you manage to do all the interactions using QTs Signal & Slot mechanism, at some point you might even change you native QT GUI to a QT Quick (QML) one, which is highly customizable, has nice looks and animations and whatnot.
This is just my opinion.

Getting QT to respond to power-events (sleep/hibernate)

I'm trying to develop software that is intelligent wrt sleep events (cleanly closing network connections, making sure data restart locations are set properly, etc).
Are there mechanisms in QT (4.6) currently that facilitate me responding to system power events?
I dont think there's a native to qt and multi platform way for these but there are propably some ways and api's to do things you are looking for. Posix signals might provide something to notify your app about ongoing system events. Also you might want to look QDbus stuff, some cases dbus will broadcast system events.. But how to do the stuff you are really looking for is very os dependant and without knowning your target os, its rather hard to point out a optimal solution.
No, nothing like that in Qt no. Probably not and will not.
You need to use the API of the operating system.

Programatically opening and closing a console

I'm writing a windowed program in C++, but I would like to have the option to pop up a console to output to from inside the program (such as various things that go on behind the scenes of my program, to see that everything is acting correctly). Is there an easy way to do this?
EDIT:
In this particular case I'm using sfml on windows, but for the purposes of this question it can be any API or platform (and platform independent solutions are best)
If you are talking about MS Windows, which your question does not make clear, you can use the AllocConsole API to create a console. for your app.
Edit: You say that it could be any platform, but this is not so as many platforms have no concept of a console. For this reason, a cross-platform solution is not possible.
There are Windows API functions to deal with console management. This might be a good starting point.
Its easy to just open a console with system("cmd.exe"); But the communication part is not so easy. My intuitive feeling tells me that there exists a third party that satisfied your need. Might be worth looking at win32api or AllocConsole API (if you are using .NET) before experimenting with 3rd party libs.

C++ Custom GUI Button Question

I am designing a graphical application for which I've decided to write my own menu. I would like this menu to be platform independent. For the time being, my menu will mostly consist of a number of buttons. My issue involves the handling of events when a button is clicked. My dilemma is with a button "knowing" about the context in which it exists. It seems to me that if there is some larger piece of code that creates buttons and handles mouse events, the need for some type of switch statement might arise. The switch statement would have to invoke the appropriate action based on whatever uniquely defined the button that was clicked.
I would like to avoid this switch statement. My first idea was to have each button maintain a function pointer that it uses to blindly initiate the correct action when it is clicked. This would eliminate any button-specific code. Yet, it bugs me that a button should contain any context-specific information (such as a function pointer). I am fairly inexperienced and I am wondering if this is considered bad design. Regardless, how can I design my menu in a manner which eliminates the need for some type of switch statement and is considered good OOP design? I would like to hear what your preferred solutions are.
Thanks in advance!
You take a look at libraries :
SPTK (Simply Powerful Toolkit) is a cross-platform toolkit that provides a set of C++ classes for fast and easy application development. It provides GUI components that use FLTK, and features database support with seamless connection to GUI components.
eGUI
http://www.codeplex.com/egui
http://torjo.com/egui/
http://msdn.microsoft.com/en-us/magazine/cc534994.aspx
NovaTK is an object-oriented, cross-platform GUI toolkit. One of the focuses of NovaTK is to facilitate rapid development of cross-platform applications requiring fewer lines of code. The event system is based upon a powerful callback mechanism that makes application design simpler, easier to read, and logical.
Ecere Cross Platform GUI Applications
Develop applications once, deploy them on all platforms alongside a lightweight runtime environment.
Introduction to wxWidgets
ClassLib, A C++ class library
libgm - A mini GUI library for Windows
You can take a look at the
Command Pattern.
You can associate a command to a menu item, the command would contain the code to be executed.

Window message procedures in Linux vs Windows

In Windows when you create a window, you must define a (c++)
LRESULT CALLBACK message_proc(HWND Handle, UINT Message, WPARAM WParam, LPARAM LParam);
to handle all the messages sent from the OS to the window, like keypresses and such.
Im looking to do some reading on how the same system works in Linux. Maybe it is because I fall a bit short on the terminology but I fail to find anything on this through google (although Im sure there must be plenty!).
Is it still just one single C function that handles all the communication?
Does the function definition differ on different WMs (Gnome, KDE) or is it handled on a lower level in the OS?
Edit: Ive looked into tools like QT and WxWidgets, but those frameworks seems to be geared more towards developing GUI extensive applications. Im rather looking for a way to create a basic window (restrict resize, borders/decorations) for my OGL graphics and retrieve input on more than one platform. And according to my initial research, this kind of function is the only way to retrieve that input.
What would be the best route? Reading up, learning and then use QT or WxWidgets? Or learning how the systems work and implement those few basic features I want myself?
Well at the very basic level you have the X Window protocol http://en.wikipedia.org/wiki/X_Window_System_core_protocol, which we can be pretty complex to handle if you want to do any application. Next on the stack there's Xlib http://en.wikipedia.org/wiki/Xlib which is a "convenient" wrapper around the X protocol, but still is complex for "real life" applications. It's on top of Xlib that most other frameworks are built, trying to simplify application development. The most know are: Xt, Gtk, Qt, etc.
Like in window you have a "event loop", and if you want you can implement on top of it a GetMessage/DispachMessage metaphor to mimic the windows behavior. That way you may have a WNDPROC, but natively X doesn't provide such thing.
Before reinventing the wheel is preferable to take a look at similar applications, what they are using.
If you need something simple you can try SDL http://www.libsdl.org/, which is a cross platform library to aimed to develop games/simple applications. Another alternative is Allegro game library http://www.talula.demon.co.uk/allegro/.
In principle it is absolutely the same. However, it has nothing to do with communication with the OS (nor does it on win32, using user32.dll is entirely optional)
A GUI application has an event loop somewhere, which processes messages from a queue at some level.
There are a lot of libraries typically used to "hide" this behaviour - you can use them (and indeed, you should). If anything, the Xlib event system is even more perverse than Win32's user32.dll one, and is less widely understood, therefore fewer people use it directly.
In Linux or in Windows, applications can use the low-level GUI, or can use a library. Most use a library. Applications can also choose to do neither and operate without a GUI (server applications typically do this). Applications can create multiple threads, one of which sits in an event loop, and others work differently. This is a popular approach too.
Most GUI applications use a higher level library for their GUI
Non-interactive applications, e.g. server applications, don't use the GUI at all and don't use the libraries (e.g. XLib, user32.dll)
Applications which don't lend themselves to an "Event loop" (e.g. Games) typically use a separate thread to process their event loop.
These things are largely true on Win32 and Linux.
It's totally and utterly different. That window procedure is 100% specific to the Windows OS. For linux, it will depend on the window manager (gnome, kde - as you've already mentioned). If you wish to do cross-platform development, you might want to look at things like QT.
You may wish to take a look at the following URLs:
http://www.qtsoftware.com/products/appdev
http://en.wikipedia.org/wiki/Qt_toolkit
As stated by xhantt, what transport the equivalent messages you are looking for is the X Window System. Which, indeed, can be a bit complex.
With XLib you will need to handle the events registering and dequeuing in your main loop. See the XLib manual for a complete description on how to proceed. But don't forget that you will only catch window and inputs events this way. Not every OS messages.
You can also look for XCB which is a newer, and probably easier, library.
If you build your application on top of those two library, it will run smoothly under (almost, we can never be too sure) every WM. And you won't require any dependency that most linux user don't already have on their installation. If you go with Qt, GTK, etc... It will be easier and work under any WM, but they may not have library installed.