Get superclass in string format

[Oliver_Scott-Brown]

How do I get the superclass of a particular instance of an object presenting through a string value. That string value being the name of the superclass.

Thanks

[Christian_Schmitz]

you mean Introspection.GetType(SomeObject).fullname?

[Oliver_Scott-Brown]

The code has a nil check before the object gets checked. For example:

if v <> nil then
Introspection.GetType(v).fullname
end if

I get a NilObjectException even though I check if the value is nil prior?

Thanks

[Oliver_Scott-Brown]

@133469:@Christian Schmitz

you mean Introspection.GetType(SomeObject).fullname?

Note that the variable is a variant. Thanks

[Eli_Ott]

Then v is not an Object.

If v is a Variant do:

If v IsA Object Then Dim ti As Introspection.TypeInfo = Introspection.GetType(var) ... End

[Oliver_Scott-Brown]

[quote=133478:@Eli Ott]Then v is not an Object.

If v is a Variant do:

If v IsA Object Then Dim ti As Introspection.TypeInfo = Introspection.GetType(var) ... End[/quote]
I thought that to start with but I did the check and ‘v isa object’ returns true. I also tried v.ObjectValue <> nil.

Thanks

[Eli_Ott]

Do you get to the line with the Break statement when running?

If v IsA Object Then Dim ti As Introspection.TypeInfo = Introspection.GetType(var) Break ... End

[Norman_P]

[quote=133454:@Oliver Scott-Brown]How do I get the superclass of a particular instance of an object presenting through a string value. That string value being the name of the superclass.
[/quote]
A few questions

1. you HAVE the name & want an instance of the super ?
2. what is it you’re trying to achieve ?

[Oliver_Scott-Brown]

[quote=133483:@Norman Palardy]A few questions

1. you HAVE the name & want an instance of the super ?
2. what is it you’re trying to achieve ?[/quote]
   I have a bug in app. The value is suppose to be of a particular type and it appears that when getting the value it does not return a value of the correct type. It seems that the value is being set to an object but I have no idea what the value is being set to.

Thanks

[Jason_King]

Use the debugger and break points. It will help you find your bug. As for the use a variants, ask yourself if it is truly necessary, or if it could be done using specific classes and/or types to allow the compiler to help you prevent bugs like this. Using variants inappropriately can cause pain just like you are experiencing.

[Norman_P]

[quote=133484:@Oliver Scott-Brown]I have a bug in app. The value is suppose to be of a particular type and it appears that when getting the value it does not return a value of the correct type. It seems that the value is being set to an object but I have no idea what the value is being set to.
[/quote]
Make whatever property is being set into a computed property
Then you can put a break point in the setter & see what the value is when you hit that break point

And, I’d recommend avoiding variants where possible as a general rule
Sometimes you can’t but where you can I would
It means the compiler can actually catch things BEFORE you ever hit run because it can check types
When you use variants the compiler mostly cannot help out any more

[Oliver_Scott-Brown]

[quote=133488:@Norman Palardy]Make whatever property is being set into a computed property
Then you can put a break point in the setter & see what the value is when you hit that break point

And, I’d recommend avoiding variants where possible as a general rule
Sometimes you can’t but where you can I would
It means the compiler can actually catch things BEFORE you ever hit run because it can check types
When you use variants the compiler mostly cannot help out any more[/quote]
I have tried debugging with computed properties. The values require variant. I will try checking the type inside a computed property.

Thanks

[Oliver_Scott-Brown]

The type can be numbers, objects, colours and all sorts so variant seems appropriate. I have already written lots of code that uses the variant value.

[Oliver_Scott-Brown]

[quote=133488:@Norman Palardy]Make whatever property is being set into a computed property
Then you can put a break point in the setter & see what the value is when you hit that break point

And, I’d recommend avoiding variants where possible as a general rule
Sometimes you can’t but where you can I would
It means the compiler can actually catch things BEFORE you ever hit run because it can check types
When you use variants the compiler mostly cannot help out any more[/quote]
The type is null with computed properties. Thanks

[Jason_King]

Have you considered overloaded methods?

[Oliver_Scott-Brown]

@133493:@Jason King

Have you considered overloaded methods?

How would I use overloaded methods? Example?

Thanks

[Jason_King]

Overloaded methods are methods with the same name which accept different parameters. Then you can stick to the specific types/classes inside of the methods and avoid variants. For example, three methods all called Foo:

Function Foo(bar as integer) as integer Function Foo(bar as string) as string Function Foo(bar as color) as color //etc...
In code you still only use Foo but the compiler will select the correct method based on the passed types.

dim i as integer = Foo(100) //use the integer type Foo dim s as string = Foo("myString") //use the string type Foo dim c as color = Foo(RGB(255,0,0)) //use the color type Foo ///etc...

[Oliver_Scott-Brown]

[quote=133497:@Jason King]Overloaded methods are methods with the same name which accept different parameters. Then you can stick to the specific types/classes inside of the methods and avoid variants. For example, three methods all called Foo:

Function Foo(bar as integer) as integer Function Foo(bar as string) as string Function Foo(bar as color) as color //etc...
In code you still only use Foo but the compiler will select the correct method based on the passed types.

dim i as integer = Foo(100) //use the integer type Foo dim s as string = Foo("myString") //use the string type Foo dim c as color = Foo(RGB(255,0,0)) //use the color type Foo ///etc...[/quote]
So you mean I should still use variants but for debugging purposes I should overload methods?

[Norman_P]

Design to avoid using widespread use of variants

Class myHoldAnythingICareAboutClass
              private property intProp as integer
              private property doubleProp as double
              private property stringProp as string
              private property PropType as string
              private property classTypeProp as ClassType // where class type is some class defined in your app

             sub DoubleValue() as Double
                     select case propType
                              case "String"
                                      return val(stringProp)
                              case "Integer"
                                      return intProp
                              case "Double"
                                      return doubleProp
                              else
                                  raise new UnsupportedFormatException                            
                              end 
             end sub
             
             function DoubleValue( assigns d as double )
                       propTYpe = "Double"
                       doubleProp = d
             end function
  
             sub ClassTypeValue() as ClassType
                     select case propType
                              case "ClassType"
                                      return classTypeProp
                              else
                                  raise new UnsupportedFormatException                            
                              end 
             end sub
             
             function ClassTypeValue( assigns ct as ClassType )
                       propTYpe = "ClassType"
                       classTypeProp = ct
             end function

            // and so on for integer etc

end class

now if eventually you wrote

  dim mv as new MyVariant
  
  mv.DoubleValue = 123.45
  
  dim d as double = mv.ClassTypeValue <<<<<< the compierl stops here with a type mismatch

But it CANT with a variant because variants automagically convert themselves to pretty much anything

And … now you have a TYPE that can hold whatever types you DO care about and YOU control all the conversions.
AND the compiler CAN help you out since you DONT use variants.
You can even add in whatever SPECIFIC object types you want, pictures, that YOUR app cares about.

Variants have a lot of magic but sometimes that magic is “Hey look you blew your feet off”

• yes you could use computed properties instead of method pairs - thats really not that relevant to the technique

[Oliver_Scott-Brown]

[quote=133497:@Jason King]Overloaded methods are methods with the same name which accept different parameters. Then you can stick to the specific types/classes inside of the methods and avoid variants. For example, three methods all called Foo:

Function Foo(bar as integer) as integer Function Foo(bar as string) as string Function Foo(bar as color) as color //etc...
In code you still only use Foo but the compiler will select the correct method based on the passed types.

dim i as integer = Foo(100) //use the integer type Foo dim s as string = Foo("myString") //use the string type Foo dim c as color = Foo(RGB(255,0,0)) //use the color type Foo ///etc...[/quote]
Shouldn’t I use ‘assigns’.