After a brief intro and some bragging about how this XDC sold out faster than any XDC before, how 25% of attendees are first-timers and how Xojo is represented by users from 12 different countries – shoutout to Stephane Pinel Xojo’s French Evangelist and and Javier Menendez our Spanish Evangelist who is attending for the first time (don’t think he’s a newbie though, he’s been with Xojo for 10 years), Geoff discussed the Xojo Community. Our forum has grown over 20% since the last XDC, with 18,000 members and over 43,000 conversations.

Xojo Cloud

People use Xojo Cloud because zero-configuration is an obvious advantage – we install more than 100 software updates per year which is 100+ actions that protect your app and your data that you don’t have to manage or install yourself. But it’s the industrial strength security that adds the most value. Xojo Cloud servers have been scanned over 1 billion times with zero known breaches to date. While no one can make servers 100% secure, Xojo Cloud certainly has proved itself to provide best-of-class security which is absolutely critical in today’s always-on, always-connected world. Check out Xojo Cloud‘s bigger and better servers – now with monitoring and stats build into the Xojo IDE.

Platform Landscape

You can use it to examine a lot of the objects that are in memory at runtime. You can access the properties in those objects, call methods on those objects and even create new instances (with some caveats here).

But there are limits to what you can do with it. You can’t use it to create things that do not exist at runtime because they’ve been stripped out when your app was built.

Suppose you have a class, MyCoolClass, and nowhere in your app do you have a parameter of that type used, a property of that type, or you never have any IsA MyCoolClass checks and never dim a variable as MyCoolClass. Then the likelihood your class has been stripped out of the final built executable is high. Basically if you never use the class it will likely get stripped out.

It’s possible to create classes that exist at runtime so you have to make sure they do not get stripped out. And there is no way for you to create one at runtime “by name” because there is no “make me this class by name” operator or function.

So in order to use introspection to create a class you need to have the class IN your compiled code.

Something like:

dim ti as Introspection.TypeInfo = GetTypeInfo( MyCoolClass )

will ensure MyCoolClass won’t be stripped out. And then you can creates instances from the TypeInfo by accessing the class’ constructors.

Watch our Intro to Introspection webinar on-demand:

You can use Introspection to examine many of the objects that are in memory at runtime. You can access the properties in those objects, call methods on those objects and even create new instances- with some caveats of course.

There are limits to what you can do with Introspection. You can’t use it to create things that do not exist at runtime because the Xojo compiler will have removed them from the app. What might something like that be?

Suppose you have a class, MyCoolClass, and nowhere in your app do you use it. You have no property of that type, you never had any “IsA MyCoolClass” checks and never Dim a variable as MyCoolClass. Then the likelihood your class has been stripped out of the final built executable during compilation is high. Basically, if you never use the class, it will likely get stripped out.

And there is no way for you to create one at runtime “by name” because there is no “make me this class by name” operator or function.

Since it’s only possible to create classes that exist at runtime, you need to make sure they do not get stripped out. The easiest way to do this is to make sure you use the class somewhere in your code. Some like this is sufficient:

Dim info As Introspection.TypeInfo = GetTypeInfo(MyCoolClass)

Now your class is referenced and it will not be stripped out. Now you can create instances from the TypeInfo by accessing the class’ constructors.