Let the compiler help you

An interesting question posed by a relatively new user came up on the forums. It had to do with how the Array() function worked and how he could force it to return an array of variants to call his method.

His method was defined like

BuildMenu( base as menuitem, params() as variant)

And he would call it like

Result = BuildMenu (base, Array ("Run", False, "Edit", "Rename", "Delete") )

and this would build up a menu from the base item and append menu items to it. Those new menu items were configured by the array of variants

‘False’ means the previous menu item is disabled (‘True’ means it is enabled, but is optional and assumed)

Because the boolean elements are optional, it is possible to make a call using only string elements, such as:

Result = BuildMenu (base, Array (“Run”, “Edit”, “Rename”, “Delete”) )

But when I do this, I get the following compile error:

So he’s trying to figure out how to force Array to return variants ALL the time. Which is the wrong question to ask in many ways.

Using an array of variants means the compiler cannot help you out and tell you when you are trying to assign the wrong kind of value to another.

Normally if you did something like

dim foo as integer
foo = "123"

the compiler will warn you about this. But if you change this simple code to :

dim foo as variant
foo = "123

you will no longer get a compile error. And depending on how you use “foo” you may, or may not, get some kind of runtime error.

This is why some of the long time users of Xojo suggest avoiding variants unless you absolutely cannot do something any other way.

Variants make it possible to bypass and avoid type checking by the compiler. What this means is that by using a variant you are possibly only finding out about errors at runtime because the compiler cannot do its normal helpful type checking to make sure you catch errors early on.

So in this particular thread on the forums the right question isn’t “how to force the array() function to always return a variant array” but “how to design this particular API so variants are not required”. And that is certainly possible since Xojo supports variable argument lists, optional parameters and other features that retain strong type checking at compile time AND still allow for a good degree of flexibility in designing an API.

And I made a suggestion on that thread :

Result = BuildMenu (base, BuildItem( “Run”, false), BuildItem(“edit”), BuildItem(“Rename”), BuildItem(“Delete”))
with buildmenu defined as

Sub BuildMenu(base as menuitem, paramarray items as menuitem)
// just append the items passed to the base
for i as integer = 0 to items.ubound
base.append items(i)
next
end sub

and BuildItem as

Function BuildItem(name as string, enabled as boolean = false)
dim item as new menuitem(name)
item.enabled = enabled
return item
end function

Avoid variants where you can and design an API that permits the compiler to help you out at compile time. The earlier you catch possible bugs the easier, and less costly, they are to fix.

The compiler can help you IF you let it.

A new take on listbox resizing

Normally a listbox doesnt support much in the way of live resizing of rows or columns if you dont have a header row.

Turns out that for something else I’m working on I needed to be able to resize things and NOT have a header row – and also make it possible to resize rows as well by clicking & dragging.

And the result so far is this

Live resizing by clicking & moving the grids themselves !

There is no header on this listbox either.

I’ll see if I can release this as a stand alone item.

Fun things to do with Xcode

I know a lot of you don’t want to mess with Xcode BUT there are some really handy things it can help you with and you don’t have to write any Swift or Objective-C code.

Since you can drop a plist into Xojo to supplement or replace certain keys at some point you may need to create one. Xcode has an excellent editor for plists.

If you start Xcode and select File > New > File and scroll down there is a section that lists various kinds of files that you can edit. In this list is a Plist.

Select that template and edit and you have a plist ready to add to your Xojo project.

But thats only the beginning.

Perhaps the handiest things Xcode can do is examine the view hierarchy of ANY application. In Cocoa every control is a kind of “view” and your entire UI is composed of multiple views one on top of the other and composited together.

If you’re having issues getting things to appear correctly this can be very handy to know whats above or below what in the entire view hierarchy that macOS uses to create what you see on screen.

We’ll work thought a quick example.

Start Xcode. Start a new empty macOS project. Use the Cocoa App template. It doesn’t matter what you call it just that Xcode wont work for this without an open project. Save that project in a new folder on your desktop since we’re going to throw it away when done.

Start Activity Monitor so you can get the the PID of your running application. I’m going to select Xojo since everyone reading this should have a copy.

I happened to show the Memory usage but other views like CPU time also have a PID column. The number in that column is what you need.

Now back to Xcode.

Select Debug > Attach to Process by PID or Name. A small panel should appear and in here you can put the PID from Activity Monitor. Nothing else will appear to change.

However there are new options available.

Select Debug > View Debugging > Capture View Hierarchy. Once you do that you get what appears to be a 2-D wire frame drawing of the user interface views. However, this is NOT just a 2D view. You can slick and drag in the view area and Xcode will reveal the various layers used to composite the image you see on screen.

There are scrollers on the bottom left to adjust the separation of the layers so its easier to see them. You can, in this view, see what is in front of or behind something else and that can help you resolve weird drawing issues and may help reveal how other applications achieve specific affects like the translucency seen in the Finders left hand navigation panes.

As well in this view you can right click on any view and select the “Print description of” menu item. This wont always tell you something really useful in the lower panes. But it does tell you what Cocoa UI element an object is in case you need to use declares to manipulate it.

There are lots of other things you can do in Xcode once you have attached to a process to examine it. Observing the view hierarchy is just one really useful one.

Enjoy !

Keep your code off of my controls

Suppose you are creating a new container control to encapsulate some functionality onto this new control. You’re already thinking about “encapsulation” which is a good thing.

Why, when you create this new container, would you then make all the controls on it public so code outside the container can change it ? That seems like it would be a good way to ruin the encapsulation you’re trying to achieve.

And, if you do this, any changes to your nicely set up container then may require broader changes in your application if, or when, you make changes to your container.

Lets walk through a quick and simple example that illustrates the issue.

Start a new desktop project.

Add a container control to the project – it will cleverly be named ContainerControl1.

Add a Generic Button to this container. It will be called “PushButton1”.

Make sure its scope is “Public”

Now add an instance of this container to Window1.

Add the Open Event to Window1.

In there put

ContainerControl11.Pushbutton1.enabled = false

And when you run the pushbutton on the container will indeed show up as disabled.

Now imagine you add a lot of other functionality to your application and there are several places where your code enables or disables this button under various conditions. And perhaps you reuse this container on several other windows.

And then you decide to make some changes to the container. And one of those changes is to rename the button to something more meaningful.

In the project we’ve built so far this isnt so bad. If we rename PushButton1 to “ContainerButton” and try to run again we’ll get an error saying

Window1.Open, line 1
Type "ContainerControl1.ContainerControl1" has no member named "PushButton1"
ContainerControl11.PushButton1.Enabled = false

Now in a small application this is manageable. You simply hunt for and change the names and off you go.

But, you may have to do this many times depending on how many times you set the enabled state of the button. And you have to update them all.

And none of this was necessary.

If instead of letting code outside the container reach in and manipulate the control directly we provided an API to do this and hid the innards then we could be sure we have fewer places to fix and that no code outside the container isnt somehow changing the setup in some way that will cause other issues.

In the example lets do this.

In ContainerControl1 add a method

SetButtonEnabled(assigns isEnabled as boolean)
  ContainerButton.enabled = isEnabled
End Sub
  

Make the container buttons scope Private.

Now if you run you will get an error in the Window1.Open event saying

Window1.Open, line 1
Type "ContainerControl1.ContainerControl1" has no member named "Pushbutton1"
ContainerControl11.Pushbutton1.enabled = False

This is because the push button is now private and hidden to code outside the container control.

So we’ll fix this one line to

ContainerControl11.SetButtonEnabled = False

Now if you run the button is once more disabled. But now when we make changes to the ContainerControl we can focus on the container control and the methods it exposes to the rest of our code and not have to worry that we will have to fix a lot of other code elsewhere in our application.

Lets try this out.

Open the container and change the buttons name to “foobar”. And change our method we had for setting the enabled state to

foobar.enabled = isEnabled

And run the sample again.

We made two small changes and no other code had to change. If we had used this container many many times the time savings could have been significant. And the chance for odd bugs caused by code outside the container altering the containers contents significantly reduced.

Make your controls private and expose an API for them and save yourself a lot of grief.

Who defined that ?

Sometimes its nice to be able to know what class defined a property or method. Introspection makes this mostly knowable.

The reason I say “mostly” is that something the introspection metadata does not tell you is if the property definition is local or inherited. So you cant tell for sure if a property in a subclass is one defined in the subclass or the inherited one from the superclass. It would be nice if this were knowable and introspection told you this but I’m not holding my breath that this will be altered as its been this way for a long time.

So lets see what introspection _can_ tell you as sometimes that is sufficient. And for when its not well you’ll have to sign on to a feature request to add metadata to introspection so you can tell.

One thing to know about introspection is that for a subclass you also get all of the supers information. So when you get the list of properties in a subclass all the supers properties will be included in that list as well.

We’ll make use of that tidbit.

For we need to get the TypeInfo for the class of interest. We’ll focus on doing this with something simple to start with – a Window. If you put this code in the open event of a Window you will get the TypeInfo for the window this is in.

// get a list of current class up through all its supers
dim current as Window = self
Dim t As Introspection.TypeInfo = Introspection.GetType ( current )

The TypeInfo is the metadata that tells you

  • the class’ name
  • if its an array, class enum, interface, or pointer,
  • if the item is a primitive type like an integer, color, or double
  • if its public or not
  • if the item is a value type or not (yes I wrote that article too)

This is all handy info. In addition to telling you all this the TypeInfo item is the one that allows you to access the properties, methods, attributes, and constructors of a class. There are several methods on the TypeInfo instance you can call that gets you a list of items you can then use.

To access the list of properties you call the GetProperties method of the TypeInfo instance

Dim props() As Introspection.PropertyInfo = t.GetProperties

Note you get back an array of PropertyInfo instances. Since any class might have more than one property this makes sense. An array is useful.

If you put a break point on the “Dim Props” line and ran this code you could manually see whats in the Props array. For a Windows you’ll have a length list and it will include things like Handle, Top, Left, Width and all the properties you might expect to see. And for each PropertyInfo object you see whether the item is private, public, protected, computed, readable and writable, shared and another object that tells you about the type of the property.

Introspection if full of objects that use other objects to tell you more information.

Again, this list doesn’t tell you anything about where the property originated – whether its defined IN this class or inherited from a super class.

So to keep track of where the property “originated” as best we can we’ll need to go through this list and mark every property as “from this class”. Then we’ll move up to the super class, get its list of properties, mark all of the ones we already knew about that match, by name, as being from the superclass. And then repeat this until we get all the way to the point where we are at the very base class that has no super.

For Window this is easy as Window has no super

We’ll create the code to do a window and then extend it to do a class that does have a deeper hierarchy of supers.

Start a new desktop project.

Add a listbox and pushbutton to the Window. Make sure the listbox has 2 columns.

Then create a new method on Window1 – GetSuperPropertyList( w as window)

In there lets put code similar to what was mentioned above.

// get a list of properties on Window
Sub GetSuperPropertyList(current as Window) 
  Dim t As Introspection.TypeInfo = Introspection.GetType ( current )
  Dim allprops As New dictionary
  Dim props() As Introspection.PropertyInfo = t.GetProperties
  For j As Integer = 0 To props.ubound
     Dim oneProp As Introspection.PropertyInfo 
     oneProp = props(j)
     listbox1.addrow t.name, oneProp.Name
  Next
End Sub

We start by getting the TypeInfo for the Window passed in. And then from that we get the list of properties on a Window and put those in a listbox.

In the pushbuttons action event put

GetSuperPropertyListCount( self )

And run.

Press the pushbutton.

You should see in the listbox a list of about 30 or so items. In the first column everything will say “Window1” and the second column are the names of all the properties on a Window.

Quit the running application.

Lets adjust the code so it can handle more than just a Window.

Fortunately this change is quite simple. Every object type in Xojo inherits from “Object” and so we can pass ANY class instance to a methd that uses “Object” as the type of the parameter.

Change the declaration of GetSuperPropertyList from

Sub GetSuperPropertyList(current as Window) 

to

Sub GetSuperPropertyList(current as Object) 

And now in the pusbutton’s action event you can write

GetSuperPropertyList(self) 
GetSuperPropertyList(me)

Run and again press the button. This time you see a listing of the Window’s properties (self) and one from the pushbutton (me).

Now the only trick is to make the method list the properties of the immediate class and those of the supers. In order to do that we’ll need to :

  • go through the current class and make note of the class name and property name
  • get the super class
  • go through its properties making note of the class name and property name
  • lather rinse & repeat until we get to the point there is no super class any more
  • print out the list

Now as we go thought teach class and its super we want to note the property name and the class name, and then when we go through the super if the property exists we need to alter the name we recorded. A perfect place for a dictionary.

So lets alter the code to

// get a list of current class up through all its supers
Dim t As Introspection.TypeInfo 
// get the type info for the current item
t = Introspection.GetType ( current ) 
// a place to keep all the property info were about to gather up
Dim allprops As New dictionary

// as long as we have a class' typeinfo
While t <> Nil
  // get all the properties on the class
  Dim props() As Introspection.PropertyInfo = t.GetProperties
  // and save them in a dictionary
  // using the NAME of the property as the key
  // and the name of the class we founf it in as the value
  For j As Integer = 0 To props.ubound
    Dim oneProp As Introspection.PropertyInfo 
    oneProp = props(j)

    allprops.value( oneProp.Name ) = t.Name
  Next

  // get the immediate superclass of the class we're looking at now
  t = t.BaseType
Wend

// now we have a dict fill Of keys (propNames) 
// And values (the Class the define the prop)
// so list them all out
For i As Integer = 0 To allprops.Count - 1
  Dim key As String = allprops.Key(i)
  listbox1.addrow allprops.value(key).stringValue, key
Next

You can see that what we have added is code that does what we were doing before (getting the type info then the list of properties) and simply saves that list in a dictionary.

The thing that makes the code walk “up” the class hierarchy is the line

// get the immediate superclass of the class we're looking at now
t = t.BaseType

Every TypeInfo object knows which one is its superclass – this is the BaseType. And by using the BaseType each time in the while loop we move from the current type to its super type and so on until there is no super type.

In each iteration around the while loop we update any existing properties to say they cam from the super type (see note above about not being to actually tell if this is true or not). For most purposes this is adequate.

If you run this now & press the button you will see that instead of just Window & PushButton we see a bunch of properties from Control & RectControl. These are from the superclass of PushButton.

And there you go. A handy method to walk up the hierarchy and get which properties came from where.

Follow up on why shadowing should be avoided

Shadowing is usually a bad thing. But you can “sort of” do it right as I explained previously. I say sort of because there are some gotcha’s – one of which I’ll explain here.

However, there are still gotcha’s that can’t be worked around. Some of them are because of how the Xojo framework does things. Like control locking.

You’d think that for locking purposes the framework would set the instance’ left, top, width and height and, if properly shadowed, the instance computed properties would get set and they could pass the change along to their super class and voila everything would be happy.

In a perfect world this would be the case. But that doesnt appear to be how the framework does locking and so when you DO shadow a property like left, top, width or height the framework appears to cast everything to be a RectControl and sets whatever underlying properties it has thereby bypassing whatever shadowing you have so neatly set up.

And what you get is an issue like in this thread. Its unfortunate as shadowing would be a ton more useful if things like this worked by setting the instance’ properties.

Now, setting up shadowed properties “right” is a more advanced topic but if you’re doing this then you really need to understand what you’re doing and how to not make a mess.

But if it worked as I described above it would be super useful.

Handy Method Editor tips

Did you know that you can write, in the declaration pane for the method editor, the entire declaration and the editor will rip it apart for you ?

So instead of having type the name, tab, parameters, tab, return type, tab, select a scope you can type

Private Foo(i as integer) as string

and press tab or return and it will all get split into the right spots.

Like this

Press Enter and get

EDIT : FWIW you can do this in a property as well that isn’t a computed property. But not in a constant (yeah you can probably blame me for that)

Friends

When you design classes you often make the properties they hold private or protected so outside code cant mess with the innards.

But what if you want to allow that – sometimes ?

This is the notion of a “friend”. Another class that you can literally say “yeah its ok I know them and it’s OK if they mess with my innards as they are my friend”. Xojo doesn’t have such a notion. So how do you make this possible ?

First off you really need to think hard about what it is you want to do and do you really need “friend”liness ? You may not. An interface or some other mechanism may be more suitable.

But if you do some to the conclusion you DO need a “friend” then you can make one using namespaces and private interfaces.

What you CAN do is

  1. take your class (call it AllowFriends) & put it in a module
  2. declare a PRIVATE class interface that class AllowFriends implements since you CAN implement an interface with private methods.
  3. Add classes to this module that you want to make friends of class AllowFriends
  4. on each class that wants to allow “friend” access implement the interface with PRIVATE methods.
  5. now anything in this module, classes or methods, that is a friend of class AllowFriends can cast it to the private interface & access whatever you exposed in that interface – this WILL only be methods but since you can make method pairs act like a getter/setter things should be fine.

And now you have classes in that module that can be “friends” but nothing outside the module can be since they cannot access the private methods on each class OR the private interface. The interface is restricted to only be used by classes & methods that exist in the module.

It’s not exactly “friend” from C++ but its about as close as you can get in Xojo.

My departure

Originally published on my old blog March 12, 2019

After Joe Ranieri quit* & moved to a new job I think everyone felt stressed. I know I did. It felt like so much more was expected of an ever smaller group of engineers.

By Dec of that year I’d had enough of the forums and some of the general dumping on Xojo as a product. I’d made a post, I forget about what, and decided later to remove it. And I removed a bunch more of my posts.

And that lead to https://forum.xojo.com/44831-norman-s-posts

So my account was altered so I could read but not post delete etc

Fast forward to last week.

Internally we had a Slack question about how everyone learned to code.

I replied as did Dana and others.

Dana mentioned that she’d learned HTML and CSS (I think)

I replied that they aren’t for application coding and and while lots of devs know them those aren’t quite the same.

And there was a reply about how it was expected that maybe a customer might do this “gatekeeping” it wasn’t expected of someone internal.

I replied to the effect “nm forget I said anything”

Later I decided that post was not suitable, nor the gatekeeping one so I removed them. And I was editing my previous one about how I got started and managed to delete the thing. Not sure how but I did. Maybe having a granddaughter around when you’re at your computer is a bad idea. I don’t honestly know but Slack really needs UNDO (maybe it has one and I don’t realize it?)

Anyway it was gone and I didn’t think it was a big deal as I could repost how I learned if necessary and the other two did not need to be revived.

Monday morning I got up. Grabbed a coffee. Sat at my machine. And since I had slept in a bit started Slack preparing for the usual morning meetings we have. 

And there was a message from Travis asking “Hey you there?”

Now he NEVER pings a person before the morning huddle. And I mean never. So this was weird.

I answered him and he called. Right from the outset I had a bad feeling as his tone and what he said made it obvious this was a “Bad Day”

We talked a bit – but it was obvious the decision was already made and out of his hands. I truly had to laugh at the … pettiness … not sure thats the right word .. the sheer insanity of being fired for removing a few posts that I had come to realize probably should not have been posted in the first place. The was a passing mention of “abrasive to customers” or something along those lines but it was obvious that wasn’t THE core issue.

And that is why I’m no longer at Xojo. Deleting posts that I realized probably should have been posted in the first place.

At least thats how I understand things.

Things will, eventually be ok here.

At Xojo I don’t know as the IDE code base, never mind everything else, is large complex and can be very hard to move in any particular direction and NOT break a lot of things along the way.

*Joe continued to work for Xojo on contact for a few months after this because his work on Android wasn’t finished.