Writings from the sticks

In the IDE you can create constants.

And if you create them as string constants you can set them to be “localized” or not.

This gives you the ability to support multiple different languages in a single build as the localized language files will be saved and used by your application.

But what happens to other kinds of constants if you add different instance values to ? What does the IDE do with those ? And how does it use those ?

Create a new desktop project. Add a new number constant, kWindowMin. Then add set a new instance value for MacOS ANY LANGUAGE and make the value 500. Add another instance for Windows ANY LANGUAGE and make the value 700.

Set the Window1 Width to #kWindowMin

And notice what it does on macOS (or Windows) immediately. Then run it on macOS and Windows.

Note that this is NOT a value looked up at runtime. It’s not determined at runtime like a dynamic language constant is. With a dynamic constant you can change the system language, run and if there is a localization for that language it will show that localization. Stop the app, switch languages and run again and the new language should show.

This kind of constant is looked up in a platform specific way at COMPILE / BUILD time.

Its set AT COMPILE TIME and never again.

They can be handy because in some situations you need a larger window or field size because the default localized values for a language are longer (German tends to be this way compared to English)

And since you can use it for all kinds of values including integers yiu could use it for colors and have a different set of colors you use for macOS or Windows quite easily.

And you can use Booleans. So with settings for transparency its fairly easy to set up one value for macOS to be TRUE – since it supports transparency very nicely – and FALSE for Windows. Then you can assign that constant to those Windows & controls TRANSPARENT property and easily switch between macOS having transparency on and Windows having it off.

Enjoy !

And how they work …..

In a bug report I made I posted a tiny sample of code

Dim tokens() As String

Select Case True
  
Case tokens.ubound < 0
  
Case tokens(0) = "End"
  
Case  "Dim"
  break
  
End Select

(Not this code has a known bug in it – Case “Dim” is wrong but it illustrated the bug I was reporting) I’ve used this style for very long sections of code esp where I dont want to clutter it up with extraneous “if then” or “elseif”

But it gathered a curious comment that convinced me the writer of that comment isnt certain how SELECT CASE works. The comment was

I see no sense in the line „Select Case True“, since True is always True. So the error message points in the right direction, correcting this line.

While I understand the reasoning it also happens to illustrate the misunderstanding of how select case works.

The statement that follows select case is known as the Test Expression.

Xojo will then evaluate each case expression and find the first one that matches that Test Expression.

In the case of the code above it will find the first one that has a case expression that is true

It behaves as if the code was written as

if true = (tokens.ubound < 0) then
  
elseif true (tokens(0) = "End") then
  
elseif true = ( "Dim" ) then

end

This sample replicates the same bug as the original BUT this time the compiler correctly complains about the comparison between TRUE and “DIM” (which is what my bug report was about originally)

Select case can be a very handy way to declutter code and remove a lot of “if then” and “elseif then” from your code.

But only if you know how it works.

Should be a great WWE match up

Really the question was “should I use a class or a module?”

There’s not really global “Oh always use X” answer here.

But usually if you find yourself wiring code that passed data to a method and you have a group of methods that collectively define a “data type” then you probably want a class.

What do I mean by that ?

Suppose you create a structure and put it in a module. And then that module has all kinds of methods that perform some kind of operations on that structure. That really probably _should_ be a class and all the methods in that module methods in the class.

Modules, or namespaces, arent as a mechanism to define a data type. This kind of style is very classical non-OOP design.

There _may_ still be reasons you want to use this style though. Yoi might use it when the data you’re dealing with is used for a declare or other external API and so your choices ARE limited by what declares can accept. There _may_ be other ways to deal with this situation but it wouldn’t be the worst choice to use a namespace in such a case.

Sometimes when you want to subclass a control you want to retain the property name the Xojo control uses, but you want to add some custom functionality by putting a computed property in place in your subclass.

In the long run this makes your subclass a better drop in replacement. You dont end up with the case where the superclass has a property named one thing, like Text, and your subclass has a similar property named something else, like Caption.

For some properties the IDE will prevent you from doing this at all. Basically IF the property you want to do this with is named TEXT you cant create a subclass with a computed property named TEXT because the IDE will stop you – TEXT is a data type and Xojo will stop you from using that name since TEXT is a data type.

Most times you’re stuck.

Notice I say “most times”

There ARE ways to make this work – but it involves working AROUND the IDE outside of the IDE. And it can be “fragile” – if you do anything that would alter the signature in the IDE it will fix it for you then you have to redo things.

When I have wanted to do this I will name my property something memorable – often “Caption” or something mostly suitable but still not the name I really want.

Then I save as text (xml would also work since its mostly plain text). Then I open my project in a text editor like BBEdit & I find the item I named “Caption” and rename it “Text”. Save the edited text and now get the IDE to reload the project.

And there’s my property named “Text” as I expect and I can then also edit and fix any code in the getter & setter and the IDE wont fight me.

I’ve submitted a feature request to make it so that if there is a property on the super class that has the same name as a data type like Text that the IDE permit me to make a computed property on a subclass that shadows that one.

In the mean time this is a workaround.

There are some really handy pragmas that can help you speed up your code a lot if you turn off the things they deal with.

Normally Xojo puts in extra checks to make sure you dont exceed array boundaries and dont overflow the stack on recursive calls. The list is on this page but I’ll repeat a few here

BackgroundTasks Enables or disables auto-yielding to background threads.In addition to the pragma directive, specify True or False. You may place this pragma anywhere within the method to enable or disable background threads as necessary.

BoundsChecking Enables or disables bounds checking.In addition to the pragma directive, specify True or False. You may place this pragma anywhere within the method to enable or disable bounds checking as necessary.

NilObjectChecking Controls whether to automatically check objects for Nil before accessing properties and calling methods. In addition to the pragma directive, specify True or False.

StackOverflowChecking Controls whether to check for stack overflows.In addition to the pragma directive, specify True or False. You may place this pragma anywhere within the method to enable or disable stack overflow checking as necessary.

These 4 can be VERY handy and can improve speed a lot. But, I would suggest ONLY enabling them in release builds AFTER you have debugged everything satisfactorily.

Why ?

Enabling them in a debug build may mean you get odd crashes of your debug builds because none of these checks will be done. And if you have an issue that causes one of these you may get a hard crash of your app being debugged instead of breaking into the debugger where the issue exist.

And there is one more you might need to carefully determine if you want it enabled or not

BreakOnExceptions Used to override the BreakOnExceptions menu item in the IDE. The possible values are: True, False, and Default. You may place this pragma anywhere within the method to enable or disable breaking on exceptions as necessary.

In conjunction with the others if you turn break on exceptions off as well then you can have a horrible time trying to debug.

Often I will use code like

#if debugBuild = false
  #pragma BackgroundTasks false
  #pragma BoundsChecking false
  #pragma NilObjectChecking false
  #pragma StackOverflowChecking false
#endif

at the beginning of methods so that during debugging runs I still get the exceptions if I do something that would cause a crash in a release build. Eventually I may also add

#pragma BreakOnExceptions false

outside that group because I have debugged that code well enough and tested whatever exception handling in there I’m happy with it and can ignore any exceptions the code might raise.

Careful out there !

Sure I badly paraphrased the line from Wizard of Oz but this isn’t a word junkies blog. Or a Word© junkies blog either 🙂

Stupid tech jokes aside this one is about Ptr and Memoryblock and their interesting relationship.

In Xojo a memory block is just that – a chunk of memory acquired in one of many ways, that usually can be manipulated in lots of ways. They can be really useful for all kinds of tasks like dealing with byte oriented data (files, binary streams) as well as more high level things like manipulating UTF-8 data since at the very lowest level UTF-8 is just special runs of bytes that we interpret as “characters” or “text”.

But then, everything in a program is JUST runs of bytes that are interpreted in special ways depending on what the bytes are, whether they happen to be “data” or “code”.

And this is where things get interesting.

A recent post on the forums did

dim p as ptr = d //d is a delegate like "AddressOf methodName"
dim mb as MemoryBlock = p
dim id as string = Crypto.SHA256(mb)

So exactly whats going on here and why might this be a problem and why might it cause a crash ?

AddressOf returns, as it states, the in memory address of whatever method you ask for. And this address is a ptr – a specific place in the running instance as loaded at this time which _could_ be different next time you run the application. This tends to be an OS level security measure.

Memory blocks CAN be created from a Ptr. Usually this is so you can use it with a declare that creates and allocates some memory and returns a pointer to that allocated chunk of memory. But, a pointer is a pointer is a pointer. So it really doesn’t matter where that pointer came from. And with this particular pointer

dim mb as MemoryBlock = p

being the address of some method, or executable code, it just happens to be in our program and its memory space. But it is relevant that is its executable code.

And then when this code tries to access that ptr it tries to READ the code, not just the ptr, since the base address of the memory block is just where “the bytes that make up thi memoryblock” are.

Crypto may die for one of two reasons. First – the OS may bock you from reading the executable code this way. Secondly Crypto would need to know how much data to encrypt. And a memoryblock created from a Ptr doesn’t have a known size. So SHA256 may just try and read -1 byes (which is a HUGE unsigned number) and crash because of that.

If you’re going to mess with Ptr’s & memoryblocks make sure you know what toes you’re prepared to lose 🙂

One day on IfNotNil we were discussing byte code and interpreters.

And the conversation came around to old CPU’s like the 6502. One many folks cut their teeth on. My first computer was a TRS-80 CoCo and after than I stepped up to an IBM clone; a TI Professional which lasted me through University and up until I started my first job after school.

As part of the discussion it was hinted that writing a byte code interpreter for any one of several old 8 bit CPU’s might be an interesting diversion. And it might also prove to be useful as a learning exercise for others.

Since the 6502 is an 8 bit only machine it basically is a “byte code” interpreter by its very definition. Each opcode is entirely contained in one byte – instead of like some current machines today that have very wide opcodes.

As such its possible to encode EVERY opcode and an associated handler in a simple table of 255 entries that, when an opcode is encountered, the handler is fetched from a table of handlers and invoked.

Those handlers are all 0 parameter methods that fetches whatever necessary operands it requires, executes the specific instruction, sets registers, and returns.

Here’s my evolving project on GitHub

Methods should solve a single problem, answer a single question, or otherwise do one thing.

When you, the author, are asked “what is this code going to do ?” you should be able to say it in ONE sentence without the use of conjunctions or disjunctions – no ANDs and ORs required.

The upside to such a description is that this often can make method nice and short. A “page” of code or less so its easy to read and see that the stated purpose is met.

As well you should be able to avoid side effects as the code answers the one question its asked, or solves the one purpose its started to solve (esp if you adhere to the Law Of Demeter)

What do I mean by all this ?

Often in code you have a need to know IF some variable contains a value that IS representative of some kind of data. Is the value in a string a date, an email address, a url your code knows how to handle, an integer, a floating point value, a boolean etc.

In one bit of code I’m working on there are strings that may hold one of several types of data. And we need to know what data type that data is. So there is code like the following to examine the value and decide what kind of value this is

Select Case True
Case value.Left(1) = """" And value.Right(1) = """"
  type = "String"
Case IsInteger(value)
  type = "Integer"
Case IsRealNumber(value)
  type = "Double"
Case value = "True" Or value = "False"
  type = "Boolean"
Case value.Left(2) = "&c"
  type = "Color"
Case value.Left(2) = "&h"
  type = "Uinteger"
End Select
End If

The calls to IsInteger and IsRealNumber examine the passed parameter and return a true false value. And do NO more than that. They do not alter the value as that could cause side effects in other code.

When you write code that does more than answer the question asked you can cause yourself unnecessary work. How so ? Imagine that the IsInteger call above actually altered the value passed in. I would need an extra variable to make a copy of that value before calling it.

As well, its not obvious that this IsInteger method WILL alter the value passed in just by reading the code. At the time you write this code you will probably remember it. But in 6 months you won’t. Nor would someone else reading the code expect that should happen.

Dont do it to yourself or to your team mates.

If you have an IsX method then you probably also need a “ConvertToX” method. So for the example above IF some data can be determined to BE suitable for an integer then a “ConvertToInteger” method would make perfect sense.

Don’t do them in one step and don’t alter the data your given (ie/ do not use a byref parameter and alter the original data)

You future self will like your code a lot more.

Or “write once”

This is a form that LLVM uses for its IR when compiling. It makes certain kinds of analysis much easier to perform as its simpler to determine how variables are affected long term and what their life times are.

And Rust uses it for EVERYTHING – you literally have to tell Rust that a variable should be “mut” or mutable.

Now you might think “OMG this makes things SO difficult”.

But in reality it actually makes things easier especially in multi threaded code because you cannot from one thread modify something in a way that could cause side effects in other threads.

And the really nice thing is that Rust actually can tell at compile time that your code is thread safe – this is really pretty cool and the more I learn about Rust the more I like some of the design decisions they made when creating the language.

This style is much harder to use in Xojo. You’d have to make every property that is exposed a computed property that you can assign once. And this is a bit of work to do. But it is possible. Again doing this could help eliminate certain kinds of bugs. Those that come from side effects because in one place you alter a property and yet it shouldn’t be or wasn’t expected to be.

Certainly computed properties can help as it makes it possible to put code in the setter so you can see when a property is modified. This is handy as heck and something I use a lot to try & make sure I don’t have weird side effects. Or when I do I can convert the simple property to a computed one and then put break points in the setter & getter.*

While SSA form has certain qualities that work well in languages & tools designed around this form, using it in Xojo _might_ be more pain than its worth.

Why ?

Suppose you create a custom subclass of a control and want to use SSA. If you have added properties on your subclass they may get initialized when the window is opened. Should your SSA property be accepting that value and no others ? Or should it only accept the first value it is assigned from code ?

Determining which case you’re dealing with is possible (see https://www.great-white-software.com/blog/2019/05/31/making-a-constructor-sometimes-illegal-to-call/) but now you have a lot of extra code in every property you want to be this kind.

In total I’m not sure that th effort is worth it for every property. But for a handful it might be.

• That you can switch a simple property to a computed on or method get / set pair and NOT have to change other code is actually one of the things I appreciate about Xojo.

Joel Spolksy has some great blog posts

Several I re-read from time to time just to refresh my recollection of them or to glean something new from them I may have missed on one of the tens of rereads I did.

I really like his blog posts about organization style, functional specs and other aspects of software development. Mostly because he’s done a lot of this more than once.

Some of my favourites

How to be a program manager It’s a great read and talks about WHAT a program manager does and who should, and who shouldn’t be the program manager and why. And it has some excellent lins to other posts about functional specs. Perhaps the BETS bit of advice in this one is

To make sure that the debate happens respectfully and on a rational basis of facts, it’s absolutely critical that the program managers and developers be peers

https://www.joelonsoftware.com/2009/03/09/how-to-be-a-program-manager/

Painless Functional Specifications is another great one and has sound advice for anyone who writes software. Starting WITHOUT a spec is masochistic. Or as Joel writes

It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to “wing it.” 

https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/

Setting off without knowing where you’re going, how you plan to get there, or even where “there” is is simply crazy. And a waste of time and effort

If you haven read his blog I would – especially the archives as there is a lot of really good advice on it.