On 07.08.2017 04:25, Johnson Jones wrote:
https://ibb.co/kaJAwa
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.
e.g.,
/** the main Gtk struct as a void* */
protected override void* getStruct()
{
return cast(void*)gdkWindow;
}
or
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.
When debugging C++, you can call functions in the watch window. I'm
hoping this will work for D, too, someday. Unfortunately, it seems with
the Concord debugger integration it needs a very different approach to
expression evaluation than what is currently used.
A slight complication is that member functions are never zero argument
function, because the this pointer has to be passed. So it always needs
to respect the proper ABI to call a function.
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?
@property functions would be the appropriate members, though that
attribute is more or less deprecated.
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.
e.g.,
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`.
Not sure why a static function should be considered a field ;) @property
members would fit in, though.
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 ;)
See also https://issues.dlang.org/show_bug.cgi?id=16692
