I'm using MFC for Visual Studio 2003. I have an Edit Control with ID IDC_COMMENT_EDIT.
In the following code, after my first call to GetClientRect, I don't expect the value of rc to change.
CWnd* pWnd = GetDlgItem(IDC_COMMENT_EDIT);
if (pWnd != NULL)
{
RECT rc;
pWnd->GetClientRect(&rc);
pWnd->MoveWindow(&rc, TRUE);
pWnd->GetClientRect(&rc);
}
rc.top and rc.left are 0 all the way through, as expected.
However:
After the first call to GetClientRect, I get rc.bottom == 52, and rc.right == 575.
After the second call to GetClientRect, I get rc.bottom == 48, and rc.right == 571.
Does anyone have any idea what is going on?
Your call to MoveWindow is resizing. You need to use GetWindowRect instead of GetClientRect.
The client rect only includes the client area which is the non windows elements (such as border) of the window.
The client rect doesn't include the window borders, but MoveRect expects a rectangle that includes the borders. Use GetWindowRect instead.
Related
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.
I made a galaxy sketch in p5.js using rotates and radians, but it's erased each time the background() is loaded as draw() runs. Is there a way to over-ride the background() function? I want the galaxies to remain in view.
var stars;
function preload(){
//for (var i = 0; i < planetArray.length; i++) {
//stars = loadImage('Assets/stars.png');
}
function setup(){
createCanvas(windowWidth, windowHeight);
}
function draw() {
//background(0);
star()
//function mousepressed(){
}
function star(){
//angle = map(mouseX, 0,width, 0,360);
//rotate(radians(angle*100));
noStroke();
//translate(width/2, height/2);
translate(mouseX,mouseY);
fill(0);
rotate(radians(frameCount%360)); //rotates output of ellipses
rotate(radians(1000*frameCount%360));
for(var i =0; i < 20; i++){
push();
noStroke();
fill(random(200),0,random(150),random(2));
// fill(random(125),random(250),random(100));
ellipse(10*frameCount % (width/10),0,10,10);
//image(stars, 10*frameCount % (width/2),0,10,10)
//image((10*frameCount % (width/2),0,10,10)
//
pop();
}
}
Well, there really isn't any magic to it. Calling the background() function fills the window with a solid color (or image) and draws over anything you've previously drawn.
The solution to this problem isn't to "over-ride" the background() function. It's to restructure your program so your stuff gets drawn properly. Exactly how you do that depends on exactly what you want to happen.
Option 1: Only call the background() function once.
If you just want a black background at the beginning, and everything you do from the draw() function should still add up, then maybe you just want to call the background() function once. You could do it as the last line in your setup() function, for example.
Option 2: Store everything you want to draw in a data structure.
This is probably the most typical case. If you want a background to be drawn behind shapes that are moving around, you're going to have to store those shapes in some kind of data structure, and then draw all of them every single frame.
Option 3: Draw to an off-screen image, and then draw that image on top of your background.
This is a bit of a mix between the first two options. You can draw everything (except the background) to an off-screen PImage, and then draw the background to the screen, then draw the image to the screen. This allows you to have a background that changes colors without having to redraw everything else.
Which option you choose really depends on exactly what you want to happen.
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 have overridden WndProc in UserControl level to detect MouseDown, MouseUp, and MouseMove to any Control added in that UserControl.
protected override void WndProc(ref Message m)
{
Point mouseLoc = new Point();
switch (m.Msg)
{
case WM_LBUTTONDOWN:
System.Diagnostics.Debug.WriteLine("mouse down");
//this.OnMouseDown(new MouseEventArgs(MouseButtons.Left, 1, mouseLoc.X, mouseLoc.Y, 0));
break;
case WM_LBUTTONUP:
System.Diagnostics.Debug.WriteLine("mouse up");
//this.OnMouseDown(new MouseEventArgs(MouseButtons.Left, 1, mouseLoc.X,mouseLoc.Y, 0));
break;
case WM_MOUSEMOVE:
int lParam = m.LParam.ToInt32();
//mouseLoc.X = lParam & 0xFFFF;
//mouseLoc.Y = (int)(lParam & 0xFFFF0000 >> 16);
mouseLoc.X = (Int16)m.LParam;
mouseLoc.Y = (Int16)((int)m.LParam >> 16);
System.Diagnostics.Debug.WriteLine("mouse move: " + mouseLoc.X + ", " + mouseLoc.Y);
//this.OnMouseDown(new MouseEventArgs(MouseButtons.Left, 1, mouseLoc.X,mouseLoc.Y, 0));
break;
}
base.WndProc(ref m);
}
MouseMove, Down, and Up are working when the mouse pointer is in UserControl but when the mouse pointer is on other control (inside my UserControl) it doesn't work.
Am I doing something wrong?
Currently developing a flick and scroll control.
This is how windows works - each control in winforms is a window, and mouse messages go to the window they are over. If you need to get the mouse input from other windows you need to cooperate them somehow.
Having said all of that, if all you want is a flick and scroll control, you should consider looking at the WM_GESTURE APIs - that is what they are for, and they will allow you to implement flick and scroll without any cooperation from your child windows.
You're not doing anything "wrong", but Windows is simply sending the message to the correct control. It does not send the message to all the enclosing controls as well.
For key events there is the the Form.KeyPreview property, which allows the form to receive the events as well, but I'm not aware of anything similar for mouse events.
Hey, I'm using D 1.041 with Tango 0.99.8 and was wondering how I would go about moving the mouse and simulating keyboard presses and getting infos from the screen, for example the color of a specific pixel on a specific coordinate. I'm using Windows.
Any help would be greatly appreciated. I want to program a class-based library with functionality that resembles AutoIt's. For example:
mouse.move(100, 200);
mouse.click(2); // 2 = Middle Mouse Click
keyboard.type('abc');
import tango.sys.win32.UserGdi;
class Mouse{
alias SetCursorPos set_pos;
alias GetCursorPos get_pos;
void left_click(){
mouse_event(MOUSEEVENTF_LEFTDOWN, 0, 0, 0);
mouse_event(MOUSEEVENTF_LEFTUP, 0, 0, 0);
}
void right_click(){
mouse_event(MOUSEEVENTF_RIGHTDOWN, 0, 0, 0);
mouse_event(MOUSEEVENTF_RIGHTUP, 0, 0, 0);
}
}
This code gives me the following error:
Error 42: Symbol Undefined
_mouse_event#16
--- errorlevel 1
Any help on that? I'm still using version.
This is a bug in Tango.
Tango declares mouse_event as:
void mouse_event(DWORD, DWORD, DWORD, DWORD);
while MSDN shows that it takes 5 parameters, not 4.
For serious Win32 development you should take a look at the Windows API bindings project.