Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I wants to make a GUI application with some fancy graphics, like flipping the window, creating translucent window on window/Linux platform.
What will be the steps for these, if I am using window/linux platform and C++ programming language using wxWidget or Juce.
As I know idea how to create such window, But i have some knowledge about wxWidget and Juce.
Thanks!
On wxWidgets, I found an interesting message that states:
Since wxFrame (which is usually the class you use for the main application),
is derived from wxTopLevelWindow, you can use wxTopLevelWindow::SetTransparent(int alpha) method, where: an alpha value of 0 sets the window to be fully transparent, and a value of 255 sets the window to be fully opaque.
There's a demo available here that seems to use this technique (search for Alpha.zip). I was able to compile it with:
g++ AlphaApp.cpp AlphaMain.cpp GUIDialog.cpp -o alpha `wx-config --libs` `wx-config --cxxflags`
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
Recently I made a program by Qt(c++) to get screen resolution and show it by moving mouse. Currently, it works well but just on the MainWindow form;
How can I make it work when I move mouse on desktop also?
I Really appreciate you if you answer.;)
If you want to get mouse input outside of the widget then you have to call QWidget::grabMouse() and later QWidget::releaseMouse() when done. Bear in mind that it may not work on some operating systems or it may stop working when your widget (MainWindow on your case) loses focus. Also it may work worse with next update of operating system. That is because operating system vendors do not like spyware that spies mouse clicks or malware that locks whole desktop.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Context: a native C++ desktop application that runs on Windows. The GUI uses plain old GDI and standard controls. The application itself is not GUI-rich but all the standard controls I use (static, button, edit and list as a base) are either owner-drawn, custom-drawn, or a mix of both.
My question is about some parts of the GUI I draw directly onto the dialog/window. Each one of these parts is clearly delimited by a rectangle, which is kept as a property for fast access, and these parts get painted only when their respective rectangle overlaps the one that comes from the WM_PAINT and similar messages. Mostly to draw text and icons (transparent background). These parts don't require any end-user interaction but they display valuable information (think status bar or any other GUI element that reacts to a state change).
The result is smooth and flicker-free thanks to the use of some tricks gathered here and there.
Q: Still, out of curiosity, I wonder in such a case (i.e.: non rich application) what would be the benefits of creating a child window for each one of these "parts" instead of just sticking to the current all-in-one drawing technique? Is there any reason why I would have to think about creating children windows?
From where I stand, I see only cons of creating children windows since it would mean more resources (children windows plus their context), plus having to deal with their procedure, which means more code to write-then-maintain.
Answering my own question a few month later...
The way the described application works is just fine as long as the amount of code to deal with those fake control rectangles (content and drawing) does not bloat parent window's code. Also, this technique spares the application from the creation of any resource associated to additional (child) windows, which cannot be a bad thing.
That being said, in the case of a layered parent window that is updated only with UpdateLayeredWindow, it can be preferable (more speed-optimized) to create child controls, especially if we need to update their content quite often.
The benefit of using child windows is simplification and code reuse. Microsoft has implemented many standard controls, and others are available from different sources, all of which are implemented as independent windows. A window will get messages directed at it so that the parent does not have to include logic to determine which function needs to respond to a particular message.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
i write a program who would have to interact with the mouse, so I would like to get the screen/monitor widht and height in c++, for linux.
I search on google and here and didn't find anything.
Thank you
You can use XLibs functions to get the size of a display.
For example, for de default display :
#include <X11/Xlib.h>
Display* d = XOpenDisplay(NULL);
Screen* s = DefaultScreenOfDisplay(d);
XOpenDisplay(NULL) to get the main Display of your X server (assuming you have a basic X config with only one display...)
Then get the screen you want the resolution from.
For the main screen, use DefaultScreenOfDisplay, otherwise use : ScreenOfDisplay(display, screen_nb).
Then you get your Screen * structure.
You can access to the height and the width member to get the resolution !
s->height;
s->width;
This is better than using WidthOfScreen/HeightOfScreen because it take only one request to populate the Screen struct. And you probably aldready have it if you are aldready using Xlib in your program and you have the choice of the screen (in case of multiple screen).
You can get the number of screens running on your display by using ScreenCount(display) function
If you're in a X environment, you can use the Xlib:
http://tronche.com/gui/x/xlib/display/screen-information.html
WidthOfScreen and HeightOfScreen
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I am writing a program that firstly shows Java GUI using JNI and then calls Windows simple GUI.
IF I call Windows simple GUI without calling Java GUI, it shows on the top of other windows so I can see it directly right after it starts.
the problem is, if I call Windows simple GUI after calling JAVA GUI, it shows its windows simple GUI at bottom of other windows: other Windows just hide it.
Here is a picture, you cam see my simple Windows GUI has been hide by visual studio when it starts.
I am not sure I understood the question but I am going to try to answer anyway. What I understand is that you are launching 2 programs and you want to bring one of them to the front of the desktop.
I suppose that you are using CreateProcess to start the programs. There are flags that you can set in the STARTUPINFO structure (wShowWindow), so see if you can use that.
Otherwise you can try calling ShowWindow after launching both programs (and possibly waiting for the Java program to start). You will need to pass the window handle to this function.
You can obtain the window handle by calling EnumWindows, checking the executable file name for each window using GetWindowModuleFileName.
Pseudo code:
foreach window in EnumWindows()
if GetWindowModuleFileName(window) == "program.exe"
ShowWindow(window, ...)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
#include "MessageBoxThread.h"
MessageBoxThread::MessageBoxThread(NfcUIConfirmProcessUC* dialogUC)
{
this->dialogUC = dialogUC;
}
MessageBoxThread::~MessageBoxThread(void)
{
}
void* MessageBoxThread::Entry()
{
this->dialogUC->Show(true);
return 0;
}
To quote from the wxThread docs:
GUI calls, such as those to a wxWindow or wxBitmap are explicitly not safe at all in secondary threads and could end your application prematurely. This is due to several reasons, including the underlying native API and the fact that wxThread does not run a GUI event loop similar to other APIs as MFC. [...] the recommended way is to simply process the GUI calls in the main thread through an event that is posted by wxQueueEvent()
So basically the best way to solve this problem is rather than calling Show to create an event (for example a wxThreadEvent) post it back to the dialog and then using an event macro or bind connect it to a dialog member which shows the dialog.