I have a local array and I'd like to take a look at the contents with Xcode 4.3.2. The array does not appear in the Variable View window, so I don't know how I can access it, either through the Variable View window or through a memory window. I can create a pointer to the array and view memory that way, but that seems like unnecessary work. Other variables are working just fine. Here's the code:
int width = 32;
int height = 24;
unsigned int testData[width * height];
unsigned int *ptr = &testData[0];
The width, height, and ptr variables appear in the Variable View window, but not testData. What am I missing with Xcode? Thanks!
If you're using LLDB, switch back to GDB. LLDB is still not entirely ready for prime time.
(Edit your scheme, choose the Run action, and in the "Info" tab, you can choose which debugger to use.)
Also: Make sure you are debugging a "debug" build, with no optimizations. The "Optimization Level" build setting should be "None [-O0]". Higher optimization levels can confuse any debugger.
Related
I wrote a simple resource display program, that displays in a very small window some stats, like amount of free RAM. I want it to be visible on any desktop when I switch between them, how to achieve that?
UPDATE:
Thanks to n.m. I am on the right track (hopefully), here is what I have got so far:
unsigned int ints[2];
ints[0] = 0xFFFFFFFF;
ints[1] = 2;
XChangeProperty(d, w, XInternAtom(d, "_NET_WM_DESKTOP", 1),
XA_ATOM,
32,
PropModeReplace,
(unsigned char*)ints,
2);
It compiles, but it does not do anything, i.e. the window is still only visible on the desktop it was originally started. What's wrong with my code?
X11 or Xlib by themselves have no notion of desktops or switching between desktops. It's all in your window manager. Usually a window informs the WM about it needs through window properties.
Modern Freedesktop-compliant window managers use _NET_WM_DESKTOP property. Set it to 0xFFFFFFFD before mapping the window.
Edit the correct incantation is
unsigned long prop = 0xFFFFFFFF; // note long! even if long is 64 bit
XChangeProperty(d, w, XInternAtom(d, "_NET_WM_DESKTOP", 1),
XA_CARDINAL, // note CARDINAL not ATOM
32,
PropModeReplace,
(unsigned char*)&prop,
1); // note 1
XMapWindow(d, w); // map after changing the property
You can use the xprop command line utility to verify that the property is set correctly.
I have some C++ classes from a library which have opaque data types. Xcode doesn't understand them and so can't show them in the variable inspector. I've written Python scripts for lldb which can decompose these opaque types correctly and return synthetic children. I have a Python class OpaqVector_syntheticChildren which implements get_child_at_index(), num_children() and so on.
For example, at the lldb prompt when the program is paused at a breakpoint in Xcode:
(lldb) frame variable sarr
(OpaqueVector) sarr = {
[0] = 1
[1] = 2
[2] = 3
}
However, in the variable inspector, sarr shows the pink 'S' to show it's a structure and has no summary nor expansion arrow. I can right-click and choose 'Print description of "sarr"' and get the correct (matching above) output in the lldb console. Is there some extra trick to get Xcode itself show the structure's synthetic children?
Xcode calls the has_children() method of the class you provide to generate the synthetic children. If that function does not return True, it won't call num_children() or get_child_at_index(), whereas the lldb command prompt doesn't seem to do that check. Hence, if you have a bug in that function you'll get the behaviour I described in the question.
I met this problem. I have a simple Win32 program which is like the boilerplate which I can get from selecting a "Win32 project" under Visual Studio 2010's "Template --> Visual C++".
I found all other Windows based program like Adobe Reader, Windows Explorer having the feature which is: you enlarging the main window to a new size and then select "Close" or "Exit" from File menu or system menu to close it, then you launch the program again, the main window would be of the size that you adjusted to last time. However that program I got from Visual Studio as the bootstrap does not have such feature.
I researched more on it but cannot find which setting in either WndClass or CreateWindow that I can tweak to make that happen. Does anyone know it, thank you for your help in advance.
The simplest way to do this is with the GetWindowPlacement() and SetWindowPlacement() functions. These manage the window size and state (minimized/maximized/restored) for you.
Call GetWindowPlacement() when you want to record your window's current state:
WINDOWPLACEMENT wp = {0};
wp.length = sizeof(wp);
if (GetWindowPlacement(hWnd, &wp))
{
// save wp values somewhere...
}
You can then save the values of the WINDOWPLACEMENT structure somewhere in your program's configuration files - either in the registry or on disk.
To restore your window's information, load the saved values into the WINDOWPLACEMENT structure, then call the SetWindowPlacement() function:
if (values were previously saved)
{
WINDOWPLACEMENT wp = {0};
wp.length = sizeof(wp);
// load wp values from somewhere...
SetWindowPlacement(hWnd, &wp);
}
You will need to save the position (X, Y) and size (Height, Width) of the window yourself, and set those values when the program starts up again.
Depending on the nature of the program, you might set this in a configuration file, a registry key, or a database (among other options).
Argh, I hit a really weird problem.
I have a breakpoint set, and I'm trying to inspect a BOOL value. The summary in the locals section says clearly that it is NO. However, I'm pretty sure that the paramater passed in should have evaluated to YES.
So, I hovered my mouse over the variable in question and get the following screen, where the value is 0x01, and the summary says it is NO. (screen attached for your amusement).
What is going on here?
I have reported this bug to Apple and this is the work-around (solution) that works by me:
Right click on the variable in the Variables View and select "Edit
Summary Format…". Do you see the string "NO" in there? If so, delete
that.
Context:
I use glfw under xmonad. Glfw apparently sets the window title after creating the window, thus not allowing xmonad to properly handle it. I want to modify the glfw source so that I can set the window title before creating the window.
Problem:
So I download glfw-2.6, and I look into lib/x11/x11_window.c ; the lines causing the trouble are:
// Create a window
_glfwWin.Win = XCreateWindow(
_glfwLibrary.Dpy,
RootWindow( _glfwLibrary.Dpy, _glfwWin.VI->screen ),
0, 0, // Upper left corner
_glfwWin.Width, _glfwWin.Height, // Width, height
0, // Borderwidth
_glfwWin.VI->depth, // Depth
InputOutput,
_glfwWin.VI->visual,
CWBorderPixel | CWColormap | CWEventMask,
&wa
);
Followed sometime later by:
_glfwPlatformSetWindowTitle( "GLFW Window" );
where
void _glfwPlatformSetWindowTitle( const char *title )
{
// Set window & icon title
XStoreName( _glfwLibrary.Dpy, _glfwWin.Win, title );
XSetIconName( _glfwLibrary.Dpy, _glfwWin.Win, title );
}
Now, if I tr yto move the glfwPlatformSetWindowTitle call before the CreateWindow call, I get a segfault -- as I should, since _glfwWin.win would not be defined.
I don't know how to solve this problem since to set the window title, I need _glfwWin.Win to be initialized, but to initialize it, I need to create the window.
Thus, I ask: in X11, what is the proper way to set the window title before creating the window?
Thanks!
This is not possible in X11, but also not necessary for stuff to work. There must be a bug somewhere causing the symptoms you're seeing. The window title is just a property on the window, and properties can't exist until there's a window for them to be on.
You say "not allowing xmonad to properly handle it" which implies it isn't coping with changes to the name; window managers absolutely must handle setting the title at any time, including changing the title long after a window is created.
What the spec says (http://www.x.org/docs/ICCCM/icccm.pdf) is:
"The window manager will examine the contents of these properties when the window makes the
transition from the Withdrawn state and will monitor some properties for changes while the window is in the Iconic or Normal state."
The "transition from the Withdrawn state" is the point where glfw calls XMapWindow(). At that point, the window will remain unmapped but the WM will receive a MapRequest. The WM would then read properties and such and then map the window. All window managers I've ever seen also handle later changes to the property because changing the window title is pretty normal. For example web browsers the page title on every url.
If xmonad doesn't handle changes maybe it at least waits for the map, so maybe you just need to set title before XMapWindow(). Really all setup should be done before MapWindow though only a few properties are required to be before it by the specs. The props that must be before it generally can't be changed without unmapping.
Incidentally, _glfwPlatformSetWindowTitle won't work for anything but Latin-1. The modern way to do it is to set _NET_WM_NAME and _NET_WM_ICON_NAME with XChangeProperty() (setting the old Latin-1 WM_NAME is fine too but only as a fallback).