I have created two Ncurses windows: Window 1 and Window 2. I am able to write to Window 1 before Window 2 is called; however, after I call Window 2, I am unable to write to Window 1 using mvwprinw(window1, "Bla"). To illustrate:
...
initscr();
Window* window1 = newwin(10,10,0,0);
mvwprinw(window1, "i am writing to window"); // this works
wrefresh(window1);
Window* window2 = newwin(10,10, 12, 12);
mvwprintw(window2, "whee"); //works too
wrefresh(window2);
mvwprintw(window1, 0,0,"writing new sentence");
// this does not show on the screen
wrefresh(window1);
...
Why is that so?
SOLVED:
If anyone encounters a similar problem, be aware of coding windows within multiple C++ classes.
A listener class was built within one of the classes. However, it called an infinite loop (not an optimal way to design code, but sufficient for the program).
Hence, the code was stuck in the infinite loop, causing the next line of code to remain unexecuted.
SOLUTION: Use multithreading libs if necesary.
Related
I'm working on a small game project and by mere curiosity I commented the line that makes a refresh to the main WINDOW object.
while(game->state)
{
//Move into player
params->mov = player_1;
params->x = player_1->pos_x;
params->y = player_1->pos_y;
params->game = game;
//curs_set(FALSE);
player_1->key_move(params);
//Move into player
mvwprintw(p_info,y, x, "TERRAIN: [%c]", player_1->inplace);
//wrefresh(main_scene); /* THE LINE I DELETED */
wrefresh(p_info);
sleep(TICK);
}
The game ran without problems and player updated its position graphically. player_1->key_move(params) eventually calls wgetch(), mvwaddch(), and mvinch(), nothing else (from ncurses). wrefresh(p_info) was commented after and, as expected, that WINDOW object never updated. I'm wondering if that function calls wrefresh() at some point. There's no direct indication of this in the manual.
If it does, are there alternatives to mvwaddch() that doesn't update the WINDOW object?
According to man wgetch, and I quote:
If the window is not a pad, and it has been moved or modified since the last call to wrefresh, wrefresh will be called before another character is read.
Because this is a game, inside the loop, and more concrete in the routine call to player_1->key_move(params) there are modifications to the WINDOW object. This is why the program is causing such behaviour.
I realised that game logic was depending on state from the WINDOW, so several reads/writes would potentially come in the future. All game logic is to be handled separately.
I'm writing an application in C++ using the Qt library. There is a central window (the parent) and all the children are launched when needed. Since a number of these windows can be open multiple times, but display different data, I'm declaring the objects with new. Here is an example of what I've got:
Home_Window.hpp
View_Window *SomeWindow;
Home_Window.cpp
void Home_Window::on_WindowButton_clicked()
{
SomeWindow = new View_Window();
SomeWindow->show();
}
What I want to do, is delete the object, when the window is closed to reduce the memory footprint of the application. I've already been able to delete all of the objects contained in the child window to reduce memory usage, but the core object still lingers, and if, through a single day a user opens and closes 1000's of windows, and each object holds onto 40-50KB of memory, the footprint of the application goes from a couple of MBs of memory to 100's of MBs of Memory.
I've not been able to find a guide online that would allow me to achieve this. I was considering a slot and signal pair, as I know that when a window is closed, it sends the QObject::destroyed() signal. Only issue, is I've not tried to setup a signal and slot pair like this.
Any suggestions are appreciated.
to delete the window when it is closed, you can set the WA_DeleteOnClose attribute on it. Your on_WindowButton_clicked() should look something like:
void Home_Window::on_WindowButton_clicked()
{
View_Window* w= new View_Window();
w->setAttribute(WA_DeleteOnClose);
w->show();
}
This way, you don't have to worry about destroying w yourself, it will get deleted automatically when it is closed.
You need to do two things:
The window's lifetime must be managed even if the window isn't closed.
You can give it a parent that you know will end its life at some point. Or you can use a QScopedPointer or std::unique_ptr.
The window must delete itself when it's closed.
void Home_Window::on_WindowButton_clicked()
{
// parent window flags
// vvvv vvvvvvvvvv
auto window = new View_Window(this, Qt::Dialog); /* 1. */
window->setAttribute(Qt::WA_DeleteOnClose); /* 2. */
window->show();
}
At the very least, you should set the Qt::Window flag. The Qt::Dialog includes the Qt::Window flag, and also declares the window to be a dialog box - that fact has platform-specific interpretation; read more about window flags here.
If your View_Window's API is broken, and it doesn't take the window flags as the 2nd argument to the constructor, you need to set them separately:
window->setWindowFlags(Qt::Dialog);
Every widget should be taking Qt::WindowFlags as the optional, 2nd argument to the constructor, with a default value reflecting the usual use of the window. That's the expectation set by all of Qt's widgets.
You can try to delete the pointer to ViewWindow by using: delete SomeWindow;
So, (I rewrote this since a lot of people didn't understand me. I apologize.)
I'd like to bring the window of my qt application to the very front of ALL windows on screen.
I've heard you can do this by attaching to the thread of the foreground window and then "stealing focus" aka putting yourself where that foreground window was.
(I'm using OSX, so windows.h is no option for me.)
I hope you understand now.
To bring a window to the front, ensure the window is visible, then activate the window.
As the docs state: -
Sets the top-level widget containing this widget to be the active window.
And
If you want to ensure that the window is stacked on top as well you should also call raise().
So, assuming you have a window called pWindow, you can do something like this: -
pWindow->raise();
pWindow->show();
pWindow->activateWindow();
Also note that OS X can have multiple desktops (Spaces). If you also want the window to track the user's Space when they switch between them, you can add this function to your window class: -
void MyWindow::DisplayOnAllSpaces()
{
// ensure we stay on the active desktop
WId windowObject = this->winId();
objc_object* nsviewObject = reinterpret_cast<objc_object *>(windowObject);
objc_object* nsWindowObject = objc_msgSend(nsviewObject, sel_registerName("window"));
int NSWindowCollectionBehaviorCanJoinAllSpaces = 1 << 0;
objc_msgSend(nsWindowObject, sel_registerName("setCollectionBehavior:"), NSWindowCollectionBehaviorCanJoinAllSpaces);
}
I have a Application mostly written with the owl-libary.
There I want open new vcl-windows out of the main owl-window.
This works great, though if a dialog-window is opened (even with ShowModal) and I focus another application, then the main-window get's into foreground but is blocked by the window behind it.
I guess the Problem is the missing parent-setting.
However, I can't convert owl's TWindow to vcl's TWinControl.
Is there a trick to set a vcl's parent setting to a owl's TWindow-Object?
Or could this be caused by something entirely different?
EDIT:
I'm using...
void(TWindow* parent){
Form=new TForm((HWND)parent->Handle);
Form->ParentWindow=parent->Handle;
Form->BorderIcons >> biMinimize >> biMaximize << biSystemMenu; //No minimize, no maximize, but close
Form->BorderStyle = bsSingle;
Form->Position = poMainFormCenter;
...
Form->ShowModal();
...now.
However, the new window is locked up and can not be clicked/closed/switched to.
Is there something I missed in using ParentWindow?
EDIT2:
I think it might be a Problem that the parent is a TDecoratedMDIFrame, which is a MDI-Container, so my dialog is treated like a mdi-child instead of a normal dialog...
TWinControl has a ParentWindow property for specifying a non-VCL parent window.
Also, in modern VCL versions, you can specify a ParentWnd when displaying a VCL dialog.
How can I get a window visible before processing?
I'm trying to do something like this:
void CMyClass::OnButton1Clicked()
{
CString class_str = AfxRegisterWndClass(CS_VREDRAW | CS_HREDRAW, ::LoadCursor(NULL,IDC_ARROW),(HBRUSH)::GetStockObject(WHITE_BRUSH),::LoadIcon(NULL, IDI_APPLICATION));
CWnd* wnd = new CWnd();
wnd->Create(class_str,"Test",WS_CHILD | WS_VISIBLE | WS_BORDER, CRect(0,0,100,100), AfxGetMainWnd(), 1432);
//AfxMessageBox("test"); // <- if this is executed wnd gets visible before sleep()
Sleep(5000); //this would be processing
wnd->DestroyWindow();
delete wnd;
return;
}
The window doesn't show at all. I've tried displaying it in an UI thread but it doesn't show either. If I do a message loop until window is created, it shows up but after a while the main message loop asserts.
I know it shouldn't be made like this but rather processing in worker thread, but with current code I'm working with it would require changes too big.
Disclaimer: I don't know MFC, but I know the windows API, which is what MFC was built on top of.
Perhaps you need to make a call to ShowWindow(). Also, are you handling the WM_CREATE message? If so, perhaps you are returning the wrong value.
If the above doesn't apply or make sense, disregard.