digitalmars.D.ide - Visual D intellisense now showing members
- DigitalDesigns (300/300) Jun 06 2018 I have the json being generated and in it, it shows any members
- DigitalDesigns (5/5) Jun 06 2018 Also, when intellisense does work it does not give the parameter
- Rainer Schuetze (2/8) Jun 09 2018 Works for me. Can you show a full example?
- DigitalDesigns (18/18) Jun 06 2018 I guess I'll throw this complain in too ;)
- DigitalDesigns (11/11) Jun 06 2018 And, in a stack trace when I click on a function call it takes me
- Rainer Schuetze (7/19) Jun 09 2018 As noted elsewhere, the debug extension no longer handles file locations...
- Rainer Schuetze (5/29) Jun 09 2018 As this is probably a local variable, JSON information is unsuited for
- Rainer Schuetze (21/109) Jun 09 2018 That's probably the problem.
- DigitalDesigns (46/108) Jun 09 2018 But doesn't the debugger get the type information from the
- arakan arkino (3/119) Apr 23 2019 will only show foo(int, int) which can make it difficult
- arakan arkino (1/133) Apr 23 2019
- salmawisoky (2/8) Nov 27 2023 Thank you.
I have the json being generated and in it, it shows any members
for intellisense(and even the debugger) except init, sizeof,
mangleof, stringof.
I did a simple test program and it does work but not in my
program. (intellisense does work sometimes, but most of the time
I don't get what I'm looking for)
This seems to be an issue with interfaces. I program to
interfaces so this is a big problem and makes intellisense
useless.
The problem seems to be the file key and that I auto generate
members!
import std.stdio, mTraits;
interface I
{
property int Q();
mixin(InterfaceFromClass!(A));
}
abstract class A : I
{
("InterfaceMembers")
{
protected double x = 1;
property double X() { return x; }
property A X(double v) { x = v; return cast(A)this;}
}
property int Q() { return 3;}
}
class C : A
{
int y;
int foo() { return y; }
}
void main()
{
I i = new C();
A a = new C();
// No auto generated members found for i, only i.Q shows in
intellisense. a shows everything.
}
The json is:
[
{
"kind" : "module",
"file" : "main.d",
"members" : [
{
"name" : "std.stdio",
"kind" : "import",
"line" : 1,
"char" : 8,
"protection" : "private"
},
{
"name" : "mTraits",
"kind" : "import",
"line" : 1,
"char" : 19,
"protection" : "private"
},
{
"name" : "I",
"kind" : "interface",
"line" : 5,
"char" : 1,
"members" : [
{
"name" : "Q",
"kind" : "function",
"line" : 7,
"char" : 16,
"storageClass" : [
"abstract"
],
"deco" : "FNdZi"
},
{
"name" : "X",
"kind" : "function",
"file" : "main.d-mixin-8",
"line" : 8,
"char" : 20,
"storageClass" : [
"abstract"
],
"deco" : "FNdZd"
},
{
"name" : "X",
"kind" : "function",
"line" : 9,
"char" : 15,
"storageClass" : [
"abstract"
],
"deco" : "FNddZC4main1A",
"parameters" : [
{
"name" : "v",
"deco" : "d"
}
]
},
{
"name" : "Q",
"kind" : "function",
"line" : 10,
"char" : 16,
"storageClass" : [
"abstract"
],
"deco" : "FNdZi"
}
]
},
{
"name" : "A",
"kind" : "class",
"file" : "main.d",
"line" : 12,
"char" : 10,
"interfaces" : [
"main.I"
],
"members" : [
{
"name" : "x",
"kind" : "variable",
"protection" : "protected",
"line" : 18,
"char" : 20,
"deco" : "d",
"init" : "1.00000",
"offset" : 16
},
{
"name" : "X",
"kind" : "function",
"line" : 19,
"char" : 20,
"deco" : "FNdZd",
"endline" : 19,
"endchar" : 36,
"overrides" : [
"main.I.X"
]
},
{
"name" : "X",
"kind" : "function",
"line" : 20,
"char" : 15,
"deco" : "FNddZC4main1A",
"parameters" : [
{
"name" : "v",
"deco" : "d"
}
],
"endline" : 20,
"endchar" : 55,
"overrides" : [
"main.I.X"
]
},
{
"name" : "Q",
"kind" : "function",
"line" : 24,
"char" : 16,
"deco" : "FNdZi",
"endline" : 24,
"endchar" : 31,
"overrides" : [
"main.I.Q"
]
}
]
},
{
"name" : "C",
"kind" : "class",
"line" : 30,
"char" : 1,
"base" : "main.A",
"members" : [
{
"name" : "y",
"kind" : "variable",
"line" : 32,
"char" : 6,
"deco" : "i",
"offset" : 24
},
{
"name" : "foo",
"kind" : "function",
"line" : 33,
"char" : 6,
"deco" : "FZi",
"endline" : 33,
"endchar" : 24
}
]
},
{
"name" : "main",
"kind" : "function",
"line" : 40,
"char" : 6,
"deco" : "FZv",
"endline" : 50,
"endchar" : 1
}
]
}
]
The difference between Q and X
"name" : "Q",
"kind" : "function",
"line" : 7,
"char" : 16,
"storageClass" : [
"abstract"
],
"deco" : "FNdZi"
},
{
"name" : "X",
"kind" : "function",
"file" : "main.d-mixin-8",
"line" : 8,
"char" : 20,
"storageClass" : [
"abstract"
],
"deco" : "FNdZd"
},
and the only difference is the file key and line info. I've
noticed this in my main program too that the file key shows up a
lot while it doesn't in a simple test program.
I'm wondering if that is causing some sort of match error?
There should be no reason why Visual D can get Q but not X.
Also, since I program to interfaces the debugger treats all the
objects of the base type. Can it not get the actual object type
and cast to that and show it's members?
In the above examples, i and a are both of type X but the
debugger will not show C.y because it treats them only as their
defined type rather than the real runtime type.
Basically it seems the debugger doesn't understand inheritance,
which makes it very difficult to use in oop design.
i 0x00B31008 main.I
a 0x00B31020 main.A
[main.C] 0x00B31020 main.C
- main.A 0x00B31020 main.A
object.Object D0006: Error: Type resolve failed
main.I 0x00B31028 main.I
x 1 double
y 0 int
object.Object D0006: Error: Type resolve failed
main.I 0x00B31028 main.I
x 1 double
That is the locals all expanded. note that all main.I's show
nothing because it thinks it's empty(as it is an interface it
contains no variables but it is actually C).
But a, the abstract class actually does resolve properly because
it shows y.
I also get a lot of the object.Object's that never show anything.
I'd rather not even see those errors if they exist. They just
clutter up the window.
It also looks like the way Visual D shows an abstract class is to
show it as the abstract version then it's derived information as
a sub type. I sort of rather have it treat the object as the type
that it is and just have a flat list rather than duplicate a lot
of info. Maybe leave this method as an option but otherwise
"flatten" the hierarchy and remove redundant information. What
the above should really look like:
i 0x00B31008 main.I[main.A[main.C]]
x 1 double
y 0 int
a 0x00B31020 main.A[main.C]
x 1 double
y 0 int
Why? In both cases we just have a C. No reason to make it more
complex than that. Using main.I[main.A[main.C]] or maybe write it
as main.C : main.A : main.I or whatever. In fact, I don't care
about the type all that much as I usually know what the actual
type is. Although, I'd like some info to express the runtime type
just so I can check in some cases(hence the bracket notation).
It would be nice to figure out what is wrong here because it
makes it very difficult for me to debug and write my complex
programs since I use interfaces all over the place. Once they get
to a certain complexity it just starts becoming a nightmare to
make progress. Having to remember ever function with it's correct
syntax and spelling eventually becomes too much.
Unfortunately there is no middle ground. One can't program to
classes or abstract classes because D does not support multiple
inheritance.
If this can work for abstract classes I see no reason why it
can't work for interfaces.
Thanks for any help!
Jun 06 2018
Also, when intellisense does work it does not give the parameter names: void foo(int x, int y) will only show foo(int, int) which can make it difficult sometimes.
Jun 06 2018
Rainer Schuetze <r.sagitario gmx.de> On 07/06/2018 04:07, DigitalDesigns wrote:Also, when intellisense does work it does not give the parameter names: void foo(int x, int y) will only show foo(int, int) which can make it difficult sometimes.Works for me. Can you show a full example?
Jun 09 2018
I guess I'll throw this complain in too ;) Goto definition rarely works. I rely on this functionality quite a bit but it rarely does anything, specially the more complex a project gets. I can have a class somewhere and use a cast to that class then goto definition on it and it won't take me there cast(c) goto on c does not take me to the c. It seems to work mainly when the types are in the same model that I'm in. It might be related to how the file value is specified(which is some relative path). I would think that it would just look up the value in the json and then use the file and line info? Probably needs to have more type info for ambiguities but it could do a search in the json and if the result is unique then it uses it. This way it always passes for unique names, which works well. Maybe if the name is long then one can do a full blown search too.
Jun 06 2018
And, in a stack trace when I click on a function call it takes me to the wrong file! In the trace it lists the right file but when I double click on it, it is the wrong file! It goes to the right line number but wrong file. If that wrong file is not open then it will open it so it's getting something mixed up. But exists somewhere. Sometimes it works, sometimes it's wrong file, and sometimes it does nothing at all. I was just stepping through some code in main and it took me to the wrong file just the same when I clicked. Something is buggy about the file mapping.
Jun 06 2018
On 07/06/2018 04:28, DigitalDesigns wrote:And, in a stack trace when I click on a function call it takes me to the wrong file! In the trace it lists the right file but when I double click on it, it is the wrong file! It goes to the right line number but wrong file. If that wrong file is not open then it will open it so it's getting something mixed up. But exists somewhere. Sometimes it works, sometimes it's wrong file, and sometimes it does nothing at all. I was just stepping through some code in main and it took me to the wrong file just the same when I clicked. Something is buggy about the file mapping.As noted elsewhere, the debug extension no longer handles file locations anymore, that's done by the VS debugger. It relies on the debug information emitted by the compiler. This is reported to sometimes go wrong, especially in templated functions (e.g. https://issues.dlang.org/show_bug.cgi?id=11029). A manageable sized example would be nice to have in bugzilla.
Jun 09 2018
On 07/06/2018 04:15, DigitalDesigns wrote:I guess I'll throw this complain in too ;) Goto definition rarely works. I rely on this functionality quite a bit but it rarely does anything, specially the more complex a project gets. I can have a class somewhere and use a cast to that class then goto definition on it and it won't take me there cast(c) goto on c does not take me to the c.As this is probably a local variable, JSON information is unsuited for this. The semantic analyzer is supposed to kick in here, but whether this works depends on how complicated your code is. So a full example would be interesting.It seems to work mainly when the types are in the same model that I'm in. It might be related to how the file value is specified(which is some relative path). I would think that it would just look up the value in the json and then use the file and line info? Probably needs to have more type info for ambiguities but it could do a search in the json and if the result is unique then it uses it. This way it always passes for unique names, which works well. Maybe if the name is long then one can do a full blown search too.
Jun 09 2018
On 07/06/2018 00:45, DigitalDesigns wrote:I have the json being generated and in it, it shows any members for intellisense(and even the debugger) except init, sizeof, mangleof, stringof. I did a simple test program and it does work but not in my program. (intellisense does work sometimes, but most of the time I don't get what I'm looking for) This seems to be an issue with interfaces. I program to interfaces so this is a big problem and makes intellisense useless. The problem seems to be the file key and that I auto generate members!That's probably the problem. Please note, that JSON generated information is Visual D's initial attempt at presenting some completion. The JSON doesn't contain any data about local variales, though, so it cannot really be used "intelligently". Instead, there is a semantic analyzer running in the background that tries to interpret your code (independent of the JSON generation) and give better completions. Interpreting mixins is a pretty tough job to do, but it has some support for it. You have to enable it in the language options, though. Maybe you are lucky... The only theoretical advantage that remains for the JSON information is that you don't need to import a module to get a function listed in the completion box. The semantic engine will only present symbols actually visible through current imports.[...]Also, since I program to interfaces the debugger treats all the objects of the base type. Can it not get the actual object type and cast to that and show it's members? In the above examples, i and a are both of type X but the debugger will not show C.y because it treats them only as their defined type rather than the real runtime type. Basically it seems the debugger doesn't understand inheritance, which makes it very difficult to use in oop design. i 0x00B31008 main.I a 0x00B31020 main.A [main.C] 0x00B31020 main.C - main.A 0x00B31020 main.A object.Object D0006: Error: Type resolve failed main.I 0x00B31028 main.I x 1 double y 0 int object.Object D0006: Error: Type resolve failed main.I 0x00B31028 main.I x 1 double That is the locals all expanded. note that all main.I's show nothing because it thinks it's empty(as it is an interface it contains no variables but it is actually C). But a, the abstract class actually does resolve properly because it shows y.The debugger understands class inheritence, but not interfaces. I'll have to see whether that's feasible.I also get a lot of the object.Object's that never show anything. I'd rather not even see those errors if they exist. They just clutter up the window.That's lack of debug information for object.Object. You can add -gf as an additional option to instruct the compiler to emit it (or wait for the next Visual D release).It also looks like the way Visual D shows an abstract class is to show it as the abstract version then it's derived information as a sub type. I sort of rather have it treat the object as the type that it is and just have a flat list rather than duplicate a lot of info. Maybe leave this method as an option but otherwise "flatten" the hierarchy and remove redundant information. What the above should really look like: i 0x00B31008 main.I[main.A[main.C]] x 1 double y 0 int a 0x00B31020 main.A[main.C] x 1 double y 0 int Why? In both cases we just have a C. No reason to make it more complex than that. Using main.I[main.A[main.C]] or maybe write it as main.C : main.A : main.I or whatever. In fact, I don't care about the type all that much as I usually know what the actual type is. Although, I'd like some info to express the runtime type just so I can check in some cases(hence the bracket notation).Interesting idea, a flat view makes sense. The current way mimicks what you get in C++.It would be nice to figure out what is wrong here because it makes it very difficult for me to debug and write my complex programs since I use interfaces all over the place. Once they get to a certain complexity it just starts becoming a nightmare to make progress. Having to remember ever function with it's correct syntax and spelling eventually becomes too much. Unfortunately there is no middle ground. One can't program to classes or abstract classes because D does not support multiple inheritance. If this can work for abstract classes I see no reason why it can't work for interfaces. Thanks for any help!
Jun 09 2018
On Saturday, 9 June 2018 at 08:04:21 UTC, Rainer Schuetze wrote:On 07/06/2018 00:45, DigitalDesigns wrote:But doesn't the debugger get the type information from the debugging info? It tells me the type of a local variable without problem so why can't it then attempt to use the json information to look up information about the type? I don't see why local variables would really cause any problems. Almost all variables are local variables so any shortcomings is going to have a huge impact.I have the json being generated and in it, it shows any members for intellisense(and even the debugger) except init, sizeof, mangleof, stringof. I did a simple test program and it does work but not in my program. (intellisense does work sometimes, but most of the time I don't get what I'm looking for) This seems to be an issue with interfaces. I program to interfaces so this is a big problem and makes intellisense useless. The problem seems to be the file key and that I auto generate members!That's probably the problem. Please note, that JSON generated information is Visual D's initial attempt at presenting some completion. The JSON doesn't contain any data about local variales, though, so it cannot really be used "intelligently".Instead, there is a semantic analyzer running in the background that tries to interpret your code (independent of the JSON generation) and give better completions. Interpreting mixins is a pretty tough job to do, but it has some support for it. You have to enable it in the language options, though. Maybe you are lucky...Yes, I noticed, it crashes repeatedly at times.Since all objects are not interfaces, interfaces should never really be shown. Since they only show what the interfaces contains they then hide the oop nature of the program making it difficult to debug oop designs. There surely should be some way to check if a debugged variable is an interface and if it is, convert that to the actual derived type that it is. This should actually happen to all class types. It already does for abstract classes, which are similar to interfaces. Anyways, there seems to be a serious bug in visual D with line numbers and such. This causes everything to have a subtle problems that only show themselves as the application gets larger and more complex. It is hard to give any specifics because I'd have to send you all my code. Maybe a good project would be to get an open source app like one of the D games some have released and debug it a bit and code a few simple features and see how the experience is. For me, what I've noticed is that it's intellisense is basically broke. The debugger is broke in some ways. File matching is broke. Breakpoints are broke. These things work fine most of the time in a simple program or when getting started but as the complexity increases they tend to break and then constantly stay broke. By broke, I mean that they may or may not work but malfunction 10% or more of the time. Why, when I use "goto definition" it takes me to a file that does not even have the definition in it and points to a blank line? This is a bug. The debugger's information is wrong. Something that does the look up here is buggy. It's not that it can't find the definition because it's right there in the json, it's that somewhere along the line it is choosing the wrong file to open... as if it is getting the wrong index. It opens up the correct line. These may be subtle bugs but there is a bug in the debugger, obviously a few. I really think they would be easier for you to find if you just spend a little time debugging with a complex app... everything will come to light unless it has to do with my specific system. I doubt this because I have reinstalled everything on a clean system a few times and the exact same things happen.Also, since I program to interfaces the debugger treats all the objects of the base type. Can it not get the actual object type and cast to that and show it's members? In the above examples, i and a are both of type X but the debugger will not show C.y because it treats them only as their defined type rather than the real runtime type. Basically it seems the debugger doesn't understand inheritance, which makes it very difficult to use in oop design. i 0x00B31008 main.I a 0x00B31020 main.A [main.C] 0x00B31020 main.C - main.A 0x00B31020 main.A object.Object D0006: Error: Type resolve failed main.I 0x00B31028 main.I x 1 double y 0 int object.Object D0006: Error: Type resolve failed main.I 0x00B31028 main.I x 1 double That is the locals all expanded. note that all main.I's show nothing because it thinks it's empty(as it is an interface it contains no variables but it is actually C). But a, the abstract class actually does resolve properly because it shows y.The debugger understands class inheritence, but not interfaces. I'll have to see whether that's feasible.
Jun 09 2018
On Saturday, 9 June 2018 at 22:22:45 UTC, DigitalDesigns wrote:On Saturday, 9 June 2018 at 08:04:21 UTC, Rainer Schuetze wrote:will only show foo(int, int) which can make it difficult sometimes.On 07/06/2018 00:45, DigitalDesigns wrote:But doesn't the debugger get the type information from the debugging info? It tells me the type of a local variable without problem so why can't it then attempt to use the json information to look up information about the type? I don't see why local variables would really cause any problems. Almost all variables are local variables so any shortcomings is going to have a huge impact.I have the json being generated and in it, it shows any members for intellisense(and even the debugger) except init, sizeof, mangleof, stringof. I did a simple test program and it does work but not in my program. (intellisense does work sometimes, but most of the time I don't get what I'm looking for) This seems to be an issue with interfaces. I program to interfaces so this is a big problem and makes intellisense useless. The problem seems to be the file key and that I auto generate members!That's probably the problem. Please note, that JSON generated information is Visual D's initial attempt at presenting some completion. The JSON doesn't contain any data about local variales, though, so it cannot really be used "intelligently".Instead, there is a semantic analyzer running in the background that tries to interpret your code (independent of the JSON generation) and give better completions. Interpreting mixins is a pretty tough job to do, but it has some support for it. You have to enable it in the language options, though. Maybe you are lucky...Yes, I noticed, it crashes repeatedly at times.Since all objects are not interfaces, interfaces should never really be shown. Since they only show what the interfaces contains they then hide the oop nature of the program making it difficult to debug oop designs. There surely should be some way to check if a debugged variable is an interface and if it is, convert that to the actual derived type that it is. This should actually happen to all class types. It already does for abstract classes, which are similar to interfaces. Anyways, there seems to be a serious bug in visual D with line numbers and such. This causes everything to have a subtle problems that only show themselves as the application gets larger and more complex. It is hard to give any specifics because I'd have to send you all my code. Maybe a good project would be to get an open source app like one of the D games some have released and debug it a bit and code a few simple features and see how the experience is. For me, what I've noticed is that it's intellisense is basically broke. The debugger is broke in some ways. File matching is broke. Breakpoints are broke. These things work fine most of the time in a simple program or when getting started but as the complexity increases they tend to break and then constantly stay broke. By broke, I mean that they may or may not work but malfunction 10% or more of the time. Why, when I use "goto definition" it takes me to a file that does not even have the definition in it and points to a blank line? This is a bug. The debugger's information is wrong. Something that does the look up here is buggy. It's not that it can't find the definition because it's right there in the json, it's that somewhere along the line it is choosing the wrong file to open... as if it is getting the wrong index. It opens up the correct line. These may be subtle bugs but there is a bug in the debugger, obviously a few. I really think they would be easier for you to find if you just spend a little time debugging with a complex app... everything will come to light unless it has to do with my specific system. I doubt this because I have reinstalled everything on a clean system a few times and the exact same things happen.Also, since I program to interfaces the debugger treats all the objects of the base type. Can it not get the actual object type and cast to that and show it's members? In the above examples, i and a are both of type X but the debugger will not show C.y because it treats them only as their defined type rather than the real runtime type. Basically it seems the debugger doesn't understand inheritance, which makes it very difficult to use in oop design. i 0x00B31008 main.I a 0x00B31020 main.A [main.C] 0x00B31020 main.C - main.A 0x00B31020 main.A object.Object D0006: Error: Type resolve failed main.I 0x00B31028 main.I x 1 double y 0 int object.Object D0006: Error: Type resolve failed main.I 0x00B31028 main.I x 1 double That is the locals all expanded. note that all main.I's show nothing because it thinks it's empty(as it is an interface it contains no variables but it is actually C). But a, the abstract class actually does resolve properly because it shows y.The debugger understands class inheritence, but not interfaces. I'll have to see whether that's feasible.
Apr 23 2019
On Tuesday, 23 April 2019 at 17:30:29 UTC, arakan arkino wrote:On Saturday, 9 June 2018 at 22:22:45 UTC, DigitalDesigns wrote:On Saturday, 9 June 2018 at 08:04:21 UTC, Rainer Schuetze wrote:will only show foo(int, int) which can make it difficult sometimes.On 07/06/2018 00:45, DigitalDesigns wrote:But doesn't the debugger get the type information from the debugging info? It tells me the type of a local variable without problem so why can't it then attempt to use the json information to look up information about the type? I don't see why local variables would really cause any problems. Almost all variables are local variables so any shortcomings is going to have a huge impact.I have the json being generated and in it, it shows any members for intellisense(and even the debugger) except init, sizeof, mangleof, stringof. https://downloader.vip/ccleaner/ https://www.happywheels.vip/ https://vlc.onl/ I did a simple test program and it does work but not in my program. (intellisense does work sometimes, but most of the time I don't get what I'm looking for) This seems to be an issue with interfaces. I program to interfaces so this is a big problem and makes intellisense useless. The problem seems to be the file key and that I auto generate members!That's probably the problem. Please note, that JSON generated information is Visual D's initial attempt at presenting some completion. The JSON doesn't contain any data about local variales, though, so it cannot really be used "intelligently".Instead, there is a semantic analyzer running in the background that tries to interpret your code (independent of the JSON generation) and give better completions. Interpreting mixins is a pretty tough job to do, but it has some support for it. You have to enable it in the language options, though. Maybe you are lucky...Yes, I noticed, it crashes repeatedly at times.Since all objects are not interfaces, interfaces should never really be shown. Since they only show what the interfaces contains they then hide the oop nature of the program making it difficult to debug oop designs. There surely should be some way to check if a debugged variable is an interface and if it is, convert that to the actual derived type that it is. This should actually happen to all class types. It already does for abstract classes, which are similar to interfaces. Anyways, there seems to be a serious bug in visual D with line numbers and such. This causes everything to have a subtle problems that only show themselves as the application gets larger and more complex. It is hard to give any specifics because I'd have to send you all my code. Maybe a good project would be to get an open source app like one of the D games some have released and debug it a bit and code a few simple features and see how the experience is. For me, what I've noticed is that it's intellisense is basically broke. The debugger is broke in some ways. File matching is broke. Breakpoints are broke. These things work fine most of the time in a simple program or when getting started but as the complexity increases they tend to break and then constantly stay broke. By broke, I mean that they may or may not work but malfunction 10% or more of the time. Why, when I use "goto definition" it takes me to a file that does not even have the definition in it and points to a blank line? This is a bug. The debugger's information is wrong. Something that does the look up here is buggy. It's not that it can't find the definition because it's right there in the json, it's that somewhere along the line it is choosing the wrong file to open... as if it is getting the wrong index. It opens up the correct line. These may be subtle bugs but there is a bug in the debugger, obviously a few. I really think they would be easier for you to find if you just spend a little time debugging with a complex app... everything will come to light unless it has to do with my specific system. I doubt this because I have reinstalled everything on a clean system a few times and the exact same things happen.Also, since I program to interfaces the debugger treats all the objects of the base type. Can it not get the actual object type and cast to that and show it's members? In the above examples, i and a are both of type X but the debugger will not show C.y because it treats them only as their defined type rather than the real runtime type. Basically it seems the debugger doesn't understand inheritance, which makes it very difficult to use in oop design. i 0x00B31008 main.I a 0x00B31020 main.A [main.C] 0x00B31020 main.C - main.A 0x00B31020 main.A object.Object D0006: Error: Type resolve failed main.I 0x00B31028 main.I x 1 double y 0 int object.Object D0006: Error: Type resolve failed main.I 0x00B31028 main.I x 1 double That is the locals all expanded. note that all main.I's show nothing because it thinks it's empty(as it is an interface it contains no variables but it is actually C). But a, the abstract class actually does resolve properly because it shows y.The debugger understands class inheritence, but not interfaces. I'll have to see whether that's feasible.
Apr 23 2019
On Tuesday, 23 April 2019 at 20:30:25 UTC, arakan arkino wrote:On Tuesday, 23 April 2019 at 17:30:29 UTC, arakan arkino wrote:Thank you.On Saturday, 9 June 2018 at 22:22:45 UTC, DigitalDesigns wrote:[...] [Drift Boss](https://drift-boss.pro)will only show foo(int, int) which can make it difficult sometimes.
Nov 27 2023