That shows a screen shot of the behavior. Not sure why some type are not showing while others are. They are all from gtkD. Most seem to be window.

Looking at window, it looks like the only field defined is

        /** the main Gtk struct */
        protected GdkWindow* gdkWindow;

It would be nice if protected fields were shown.

The real problem is that it looks like getters and setters are shown to return the data and, of course Visual D has no way to know what is what.


        /** the main Gtk struct as a void* */
        protected override void* getStruct()
                return cast(void*)gdkWindow;


        public static GType getType()
                return gdk_window_get_type();

and these are not marked in any way.

I'm not sure what Visual D can do to help this situation.

It's obvious to a human that the above functions are effectively wrappers around an internal field.

I'm not sure if Visual D can determine functions that return non-void and take 0 args(i.e, getters, specially if their name starts with get) and basically treat them as a field and call the function to get their value that is inserted in the list as if it were a field seamlessly?

If it could, it would at least help fill out the information listed a bit rather than show {}. Then we can parse down through the data structure and see more of whats going on.


public static string Name() { return "xyc"; }

should ultimately, in the locals/watch/autos, be treated as if it were a field of type string with name `Name`. The value, of course, can only be gotten by calling the function, which I'm not sure if the debugger can do or not while debugging and sitting on a BP?(it should, since it should know the address and these functions almost surely are safe to call in most cases. If not, it just catches the error and displays it. Obviously the function could do bad things like write to disk, etc.

Instead, maybe it just list them by name and ignores the value. Maybe double clicking on it then could run the function and insert the data in to the tree.

Anyways... So close but so far away ;)

Reply via email to