I've read window(3NCURSES) man page, but I can't fully understand what mvwin() function actually does and what happens to its subwindows.
The code below creates a window with a title "Window" and a border, it also creates a subwindow that is used for printing y,x position without corrupting parent window border. It then moves the parent window to a new location, but the result is not what I expected:
After the window is moved, the outline of the windows border + text is not automatically erased at the old location.
After the move, writing text to a subwindow, outputs it at the old and new location.
After the move, parent window has new y,x coordinates, but subwindow still shows old coordinates.
I don't have a lot of experience with ncurses, and maybe I'm missing something, but this behaviour is completely illogical. If I have to manually erase windows at old location and manually move all subwindows, then this negates the benefit of using ncurses in the first place. I was expecting ncurses to automatically handle these low-level details.
My understanding of subwindows was that they are used to partition one large window into smaller non-overlapping areas. So when the parent window is moved or refreshed, all its subwindows should be moved or refreshed automatically. Is this correct?
#include <assert.h>
#include <ncurses.h>
#include <unistd.h>
int main()
{
WINDOW *win, *swin;
int lines, cols, y, x;
initscr();
keypad(stdscr, TRUE);
noecho();
// Create window
lines = 10; cols = 40;
y = 5; x = 5;
win = newwin(lines, cols, y, x);
assert(win != NULL);
// Create window border
box(win, 0, 0);
mvwprintw(win, 0, 2, " Window ");
// Create subwindow
swin = subwin(win, lines-2, cols-2, y+1, x+1);
assert(swin != NULL);
// Print window and subwindow y,x
mvwprintw(swin, 0, 0, "win y,x=%d,%d swin y,x=%d,%d\n",
getbegy(win), getbegx(win), getbegy(swin), getbegx(swin));
// Refresh
wnoutrefresh(stdscr);
wnoutrefresh(win);
wnoutrefresh(swin);
doupdate();
sleep(2);
// Move window
y = 20; x = 40;
mvwin(win, y, x);
mvwprintw(swin, 0, 0, "win y,x=%d,%d swin y,x=%d,%d\n",
getbegy(win), getbegx(win), getbegy(swin), getbegx(swin));
// Refresh
wnoutrefresh(stdscr);
wnoutrefresh(win);
wnoutrefresh(swin);
doupdate();
wgetch(swin);
endwin();
return 0;
}
Apparently not: a quick check with Solaris 10 gives the same behavior. You might find some scenario where ncurses differs unintentionally, but this is not one of those. The FAQ makes this point about compatibility:
extensions (deviations from SVr4 curses) are allowed only if they do not modify the documented/observed behavior of the API.
The Solaris manual page does not make this clear, since the only mention of subwindows is in regard to moving them:
The mvwin() routine moves the window so that the upper left-hand corner is at position (x, y). If the move would cause the window to be off the screen, it is an error and the window is not moved. Moving subwindows is allowed, but should be avoided.
The Solaris source code tells the story for that: it does nothing with subwindows. Some retesting a while back (early 2006) in response to a user's comment about differences pointed out that ncurses was incorrectly attempting to copy subwindows. That part is ifdef'd out (since it's too interesting to just delete). Since there's not much left for mvwin to do, the actual code is fairly similar.
X/Open's description of mvwin is too brief and vague to be of any use.
Related
I'm using the following code to lock an IDirect3DTexture9 for update. This piece of code works fine on my NVidia graphic card (NVidia GeForce GTX 970M) but causes memory violation on Intel integrated graphic card (Intel HD Graphics 530), even the texture is immediately unlocked and no data is written on locked region. x, y, w and h parameters are far from boundary conditions so the locked rect is totally inside the texture.
void InnerLock(int x, int y, int w, int h, D3DLOCKED_RECT *lr)
{
int left, right, top, bottom;
left = clamp(x, 0, Width() - 1);
top = clamp(y, 0, Height() - 1);
right = clamp(x + w, left + 1, Width());
bottom = clamp(y + h, top + 1, Height());
RECT rc = { left, top, right, bottom };
texture->LockRect(0, lr, &rc, D3DLOCK_NO_DIRTY_UPDATE);
// this line returns zero but causes an exception on igdumdim32.dll later
texture->AddDirtyRect(&rc)
// everything become all right when I set the whole texture as dirty region
//RECT fc = { 0, 0, Width(), Height() };
//texture->AddDirtyRect(&fc);
}
The AddDirtyRect operator returns correct value, but the error occurs later in igdumdim32.dll (I'm not sure where the error exactly occurs, maybe in the draw call).
I first found the error when using LockRect with zero flag. The program crashed on some rect parameter (in my case the error occurred when y value of the rect is large enough, but still smaller than texture height). Then I used D3DLOCK_NO_DIRTY_UPDATE and manually added dirty rect. The error only occurs when AddDirtyRect is called.
This error is reproduced on another user with intel graphics card. My operating system is Windows 10. All drivers are updated to the latest version. If you need any information please tell me. Thank you!
I'm trying to set my X11 cursor position. I tried calling XWarpPointer with the window set to None, root (DefaultRootWindow(display)), to the previously created window (XCreateWindow). The function IS being called, the mouse slows down a bit, but it does not physically move. Why could this be?
void GameWindow::ResetCursor() {
SetCursor(resX / 2, resY / 2);
}
void GameWindow::SetCursor(int x, int y) {
// Window root = DefaultRootWindow(display);
XWarpPointer(display, None, root, 0, 0, 0, 0, x, y);
XFlush(display);
}
EDIT: Here's the entire X11 Windowing file in case you can't find the reason here. https://gist.github.com/KarimIO/7db1f50778fda63a36c10242989baab6
The answer to this was relatively silly. I was using Gnome on Wayland, assuming it supported X11 as well. I assumed wrong.
I try to delete a square when I input the number as "1" into the program. How can I delete it?
sf::RectangleShape rec1(sf::Vector2f(50, 100));
rec1.setPosition(200, 700 );
rec1.setFillColor(sf::Color(100, 250, 50));
window.draw(rec1);
int num;
cout << "Please enter a number: ";
cin >> num;
SFML itself won't track what's drawn on screen – you'll have to do that yourself – and you're supposed to redraw the window contents when needed.
A basic "main loop" for a SFML based program would typically look like this:
while (window.isOpen()) {
sf::Event event;
while (window.pollEvent(event)) {
// Handle events here
}
// Update your program logic here
window.clear();
// Draw your stuff here
window.display();
}
Depending on what you draw, you determine what's visible on screen. So if you want your rectangle to no longer appear, simply no longer call window.draw(rectangle);. How you achieve this – e.g. by removing the rectangle from a std::vector<sf::Drawable*> that's iterated over while drawing – is up to you.
You can't delete it when you created it like that. you can color it as transparent using sf::Color::Transparent and it will become unseenable.
If you want to delete it. you have to make it a pointer first. or wrap it out of a class that handles it.
auto rect = make_unique<sf::Rectangle>(sf::Vector2f(50, 100));
and then use std::unique_ptr::reset() to delete it.
rect.reset();
I am trying to implement a zoom in function to my app.
The idea is when I chose to zoom in, the graph should expand horizontally 2 times larger so that only half of the graph will be shown in the window, and one will need to scroll to see the other half despite the size of the window.
I have a zoom variable for zoom factor. Then in onDraw(CDC &pDC):
//...set pen and others...
CRect rect;
GetClientRect(rect);
for (int x=0; x < zoomFactor*rect.Width(); x++)
//....draw the graph
then in onToolsZoomin():
void CMyGraphView::OnToolsZoomin()
{
zoom *= 2;
CRect rect;
GetClientRect(rect);
CSize sizeTotal;
sizeTotal.cx = zoom*rect.Width();
sizeTotal.cy = 0;
SetScrollSizes(MM_TEXT, sizeTotal);
this->RedrawWindow();
}
When I run this, I can have the window correctly draw half of the graph and a scrollbar that indicate only half of the graph is shown. But when I try to scroll it, it goes back to the original position (bottom left) and the other half of the graph won't show up.
The parameters in both functions are not the same one. It can be the first reason of the problem.
Can you put the code that is suppose to call OnToolsZoomin please ? Is it handled through a WM_VSCROLL or WM_HSCROLL message ?
Is your function OnToolsZoomin called at all ?
Is you scrollbar properly initialized (scroll range) ?
I wrote a program that i used ncurses library, i used, keys menu windows and other its facilities.
I run my program without any error.
After quit program, i can't see any input data (certainly same you run passwd command and wanna input new password), for example if you run ls, i can see output of ls(list of current dir) , but i can't see ls word.
How i solve this problem?
piece of my code:
WINDOW *menu_win,*qmenu_win,*amenu_win,*smenu_win;
char *query;
char *fields;
WriteFile *writePtr = new WriteFile();
ReadFile *readPtr = new ReadFile();
int highlight = 1;
int choice = 0;
int c;
initscr();
clear();
noecho();
cbreak(); /* Line buffering disabled. pass on everything */
startx = (80 - WIDTH) / 2;
starty = (24 - HEIGHT) / 2;
menu_win = newwin(HEIGHT, WIDTH, starty, startx);
keypad(menu_win, TRUE);
mvprintw(0, 0, "Use arrow keys to go up and down, Press enter to select a choice");
refresh();
print_menu(menu_win, highlight);
while (true)
Make sure your program calls endwin() before exiting. Otherwise, the state of the terminal may not be restored.
When this happens, type reset at your prompt.
Also be aware that problems may be due to your terminal program itself. If it does not properly emulate the terminal it claims to emulate, you will run into problems.
Or it could be a bug with your program: maybe you need to replace noecho with echo?