Fixing code by not touching it follow up

In the case I described the code is in a subclass a Xojo class

The idea here is to INSERT a new subclass between the existing subclass and the new one. And the newly inserted subclass will expose things in a way the OLD existing code wont break

So we never touch the old code
We just modify the inheritance chain in a way we can then alter how things behave

So in his case we can add a new subclass of EmailMessage that exposes the Source as a Method pair ( get & set) and then make the existing class inherit from our new class

And the existing code will then JUST work without ever having had to alter any of it

Next time you have an issue like this consider that as an option !

Fixing code by not touching it

The other day I was helping a friend with some code that worked fine in several versions of Xojo but then in a newer one wouldn’t compile

Seems he found a compiler regression Whether this _should_ have been caught by regression tests etc is an entirely different question.

It exists. And now his large project doesn’t compile.… Read the rest

Delegates

The Xojo docs about delegates are quite sparse about what you can or cannot do with them and whether they can or cannot take certain kinds of parameters. What they do say is that

A Delegate data type is an object representing a specific method. It is a function pointer with a method signature.

I was recently asked if a delegate that did not make use of any external dynamic library could take an object parameter.… Read the rest

EmbeddedWindowControl

If you’ve ever used a container control on a layout and then tried to manipulate the controls at runtime with code like


For i As Integer = 0 To Self.ControlCount - 1
  Dim ctrl As Control = Self.Control(i)  
  // now manipulate this control or call its methods
Next

you’ve probably run into the EmbeddedWindowControl

Its what you get when you use a Container Control on a layout either by placing one at design time or dynamically adding one at runtime.… Read the rest

Interfaces

Interfaces are one of those things in Xojo, and many other computing languages, that can really help you make your code more reusable and generic.

For instance, suppose you need a class that is a “List”. You could write a single class, called list, that you could add items to, remove items from, and generally manipulate in a “list like way”.… Read the rest

Making platform specific error codes generic

A few threads on the forums have commented that the URLConnection isnt quite as easy to use as many might expect. In particular there are comments about having to know what error codes a platform might return makes it harder to use than it should be.

Normally Xojo hides this level of detail from us.

I was thinking about this problem and have come up with something of a solution that makes it possible to both know the specific error code and yet still write code that is portable.… Read the rest

Implementing the Factory pattern in Xojo

When using the “factory” pattern you should only be able to get a valid instance from the factory and NO other way. Thats kind of the point of the pattern – to reduce the number of points at which instances can be created. Normally in Xojo you might have a module with a method that can create instances, and its the only one allowed to do this.… Read the rest

C Unions

An interesting question came up on the forums the other day about how to mimic “Unions” from C.

Turns out I had answered this some time ago – its close but not exactly the same as in C. But it is close enough to be functional and close enough for most uses.

And it’s not mentioned anywhere in the Xojo docs.… Read the rest