New To RB: Windows are Special Objects

Other Peoples Code projects are always instructive because it gives me some insights and things to talk about.  REALbasic is easy-to-use.  I sometimes think it’s too easy-to-use because it lets people get away with a lot of things that aren’t necessarily good. Today, in my ongoing occasional series on things that new people have problems with in REALbasic we’ll talk about Windows.

REALbasic has strong typecasting and is very object oriented, but Windows are a prime example of an object that can quickly get new developers into trouble.  Take this bit of code:

if myWindow.visible = true then
     myWindow.visible = false
end

What the user was TRYING to do was keep the window from loading. Unfortunately, what he was doing was loading myWindow and then making it invisible regardless if myWindow had been created previously. What the user should have done was something like this to see if that window has been created already:

for i as integer = 0 to windowcount-1
     if window(i) isa myWindow then
          //do something special here
          return
     end
next

What is this? Windows are special objects in REALbasic. They can be called without explicitly calling the ‘new’ statement. For example, the following two pieces of code do the same thing:

mywindow.show
dim w as new myWindow
w.show

The first one uses the implicit instance of a window, meaning that if you call it, myWindow gets created if it’s not already created and shows it. The second bit of code creates a new instance of myWindow and then shows it. In the first bit of code you can call this a million times and you’ll only get one window. The second example will let you create as many windows of myWindow as you have memory for.

Real Software introduced the ImplicitInstance property in RB 2007 R4 and, to me, this should be false by default (I wish it were a preference setting). Turning this property off and compiling will immediately tell you if you’re accessing the properties/methods/constants of the window definition rather than the instance of the window.

Look at it another class as an example. This code will fail:

dim d as date
d.totalseconds = 123412354

Why does it fail at runtime with a nil object exception? Because d is a date object and it hasn’t been created yet (i.e. d is nil). The following code will work because d, the date object, has been created using the new command:

dim d as new date
d.totalseconds = 123412354

The fact that windows can be created implicitly is both a feature and a hindrance. Turning off the implicitinstance property in your windows may just save you some time in tracking down window issues.

A good friend of mind said, “If you’re using the implicit instance, you’re code is broken – you just don’t know it yet.” While it’s somewhat of an exaggeration it’s advice well worth listening to. Treat your windows like classes and you’ll have fewer problems.

Happy Coding!

5 thoughts on “New To RB: Windows are Special Objects

  1. Recalling the old VB days: “Option Explicit”! Ditto on default for ImplicitInstance property.

    On a similar note, what about the risk of “Dim d as new Date” etc.? Also convenient, but also in effect implicitly creating the object on its first (subsequent) reference; what are your thoughts that on the same logic one should always explicitly create the instance? After all you need to do so if the date is a property of an object, so why not apply the same principles to local variables/objects?

  2. Essentially using that syntax you are relying on the compiler to determine when the constructor of the object will fire, rather than expressly specifying it in your code.

    In RB2009 the constructor fires on the dim; however there is no logical reason why the compiler might not fire it on the first reference to the object (VB used to do so), so should we make the assumption that this behaviour might not change in the future? Depending on your code that could leave a couple of seconds difference in the datetime.

    In VB there were some significant differences including if d were set to nothing (nil in RB), and you referred to it again a fresh instance was implicitly created; fortunately that particular behaviour does not apply to RB. It did however lead to a lot of consideration of explicit v implicit declaration of objects. In RB it is much more a philosophical/theoretical question (to date), but it fits in with what you are saying about referring to windows.

  3. There’s nothing much to worry about with Dim d as new Date. REALbasic’s compiler treats the declaration line as a code execution point (you may notice that in the debugger, as you can step through them). So if you have the “new” keyword there, it will always fire. The only thing you do have to worry about is dead stripping unused code. Let’s say you use Dim d as new Date and then never refer to d. Well, you still referred to it in the declaration line, so it won’t be dead stripped. But that’s a very small and rare price to pay for code clarity. I am pretty sure VB took the opposite approach as a micro optimization for dead stripping unused code.

  4. S-Copinger :

    In RB2009 the constructor fires on the dim; however there is no logical reason why the compiler might not fire it on the first reference to the object (VB used to do so), so should we make the assumption that this behaviour might not change in the future? Depending on your code that could leave a couple of seconds difference in the datetime.

    I’m still not entirely sure I understand what your trying to say. The date constructor isn’t called until you use “new”. If you attempt to use d before you create the object (using new) you will get a nil object exception at runtime. So it’s entirely unlike a window where calling the window implicitly creates a new instance. This is why windows are ‘special’ because they are unlike any other RB class.

Comments are closed.