Compat flags

What are these things and what use do they have ?

Buried away on the advanced tab of the inspector for most things is a little section that has a lot of check boxes labelled Desktop, Web, Console, iOS that I’m sure most folks dont know what they are for or what you’d use them for.

For your own code these can be immensely useful. If you happen to want to share code between project of different kids then you may need to use these.

What they let you do is create classes or code that can have different implementations depending on what kind of project the code is in.

For instance suppose you have a library of code you were working on, your own “framework” for an app that had aspects that ran on all targets.

You might create a module for your framework code. And in there it could have several implementations of your crucial method, Foo() – one for each of console, web desktop and even iOS as follows

Public Sub Foo(param as string)
  MsgBox "desktop foo !"  
End Sub
Public Sub Foo(param as string)
  MsgBox "Web foo !"
End Sub
Public Sub Foo(param as string)
  MsgBox "Console foo !"  
End Sub
Public Sub Foo(param as Text)
  Dim helloMessage As New iOSMessageBox
  HelloMessage.Title = "Hello"
  HelloMessage.Message = "iOS foo !"
  HelloMessage.Show // Not modal, so code does not pause here
End Sub

Yeah I realize its not sophisticated. Thats not the point. Maybe this ias a method that you have for calculating some vital function for your app. Or for fetching some data from a web service.

The compatibility flags for each of these would be set differently. The one that sayd “Desktop foo” should be marked for desktop only

The web one would be marked for web only

And similarly for the iOS and Console one

So now we have this handy dandy super module with all kinds of functionality in it that …

yeah … this is an example OK ?

I have my module set up in a desktop application and if, in Window1.Open I put


module1.Foo(CurrentMethodName)

Guess which method gets executed ?

If you guessed the one marked compatible with desktop apps then you’re quite right.

And if we take this handy dandy module and copy & paste it into a Console app, guess which one runs ?

Web

And even iOS

Thats all well and good but whats going on ?

Is all this magic happening at runtime and all the code is in the app all the time ?

Not at all.

The IDE, at compile time, selects the compatible version of the methods to compile depending on how the compatibility flags are set. And it only compiles those.

So despite our handy dandy module having all those different versions in it only the desktop ones will get compiled in a desktop app, only the web ones in the web app, and so on.

I hope you can make good use of this !

Citizen developers

No this isnt a rant about segregating developers into groups – maybe that will be a different post.

This is more about a couple recent conversations.

One had to do with how Xojo handles conversion & comparison of unsigned & signed values. Turns out that while I closed the bug report way back when based on info from a compiler developer I now think that was the wrong move.

Citizen developers shouldn’t be expected to know, and usually don’t want to know, the arcana of why a 32 or 64 bit value compares to another using a specific x86 or x86_64 instruction that performs a bitwise comparison (which IS whats going on).

What they DO know is Xojo compares in a way that appears to them as really really wrong. The following code on 64-bit Mac and Windows, says “Value is greater than 0.” On 32-bit Mac and Windows, the message box says “Value is less than or equal to 0.”

Var Value As UInt32 = 4294967295
If Value <= 0 Then
  MessageBox("Value is less than or equal to 0")
Else
  MessageBox("Value is greater than 0")
End If

Thats not helpful and the explanation is truly arcane and relies on the bit wise representation of the values to explain why it appears so wrong. It might even explain some really erratic an unusual errors that people report that only occur once in a while.

The other issue that another user I was helping recently stumbled into was one I had never even thought about. If you create sql statement that uses prepared statements and dont provide as many bind variables as specified in the query then it can just silently do .. something.. which appears to vary depending on the database in use.

Again, this is not helpful and could quietly be doing harm by inserting bad data.

Thankfully this has been reported & fixed now(that no one noticed until now is a different issue)

But these two point out a specific problem. A citizen developers should be able to rely on the IDE and compiler to point out as many bugs and errors as early in the process as possible AND they should do “sensible” things.

Comparing what looks like a giant positive number and telling me its less than zero isnt sensible. Silently inserting nil instead of reporting a mismatch in the number of bind parameters isnt sensible.

Neither helps anyone, of any skill, write better more bug free code.

Shouldnt that be the goal though ?

TextInputCanvas series

I’m currently posting a tutorial about the TextInputCanvas at If Not Nil

A powerful and flexible but under documented control in Xojo’s toolkit it forms the basis of the Code Editor in the IDE

Adventures in B4J

I’ve been poking about with some alternative tools – probably more than I have in the last decade or more.

Previously I’d look at them for “competitive intelligence” reasons. To see where they were, where they were going and what things they did better.

Now that focus has shifted entirely. I, like many others, have been looking at other tools with an eye towards maybe moving away from Xojo. Thats not likely to happen ASAP but there are some promising options I’ve looked at.

B4J is one.

Its visual designer behaves differently than Xojo’s but its not entirely foreign. And one thing you’;ll find different is that the B4J style of working is that you have to add references to controls & windows & the events they handle in a manner that is different than Xojo’s.

Its not better, or worse, just different.

Last night I sat and created a simple web browser app which in B4J took me about as long to create as it did in Xojo. Its really simple with a text field, a button, and an html viewer.

So that easy stuff just works – exactly as you’d expect.

I’ll report more as I tinker more.

How crash logs lie to you

Sometimes you get a crash log and start digging through the call stack assuming that what it shows you is The Truth.

But, it may not be.

If you strip symbols from your apps then the crash logs you get can be horribly misleading.

For instance a crash that looks like


Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00007fff6597bfce __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff658d830a abort + 127
2 libsystem_c.dylib 0x00007fff658a0360 basename_r + 0
3 XojoFramework 0x000000010ca2fa79 _Z29ShowDebuggerConnectionFailurev + 0
4 SpawnCompiler.dylib 0x000000011262b260 REALPluginMain + 934808
5 SpawnCompiler.dylib 0x0000000112694dfb REALPluginMain + 1367859
6 Xojo 0x0000000107a430cb DebuggerMap.LookupLineAddress%b%o<DebuggerMap>si8&i8 + 107
7 Xojo 0x000000010a207ac5 StudioDebuggerUI.StudioDebuggerUI.LookupBreakpointAddress%i8%o<StudioDebuggerUI.StudioDebuggerUI>si8 + 421

Where the offset from REALPluginMain is an enormous value is VERY likely NOT correct that the call site was in REALPluginMain

So why does this happen ?

The system component that records the stack trace simply looks for symbols that are before the call site and reports those.

If symbols have been stripped then you see the problem. That crash logger cannot find the “correct” symbol and so may simply walk back a long long way to find one that hasnt been stripped. It reports that + a really large offset.

Exceptions in Xojo however ARE quite accurate.

Another one joins the party !

We have MS trying to move Xamarin into a much more capable x-platform tool chain. Windows, iOS, Android, macOS (eventually) and even web is on the roadmap somewhere.

And, as of Sept 22, we get the announcement that the Swift team has released a toolchain for Windows.

What remains unclear with the both toolkits is how easy it will be to design a UI in a cross platform way.

Some tools already do work x-platform, like Elements compilers.

But they require you to have different custom UI’s per platform usually made in the platforms “preferred tool” – Xcode on macOS and VS on Windows

If I wanted to use those tools I’d already be using them and have a single common “platform abstraction layer” then my common business logic I can just share and a custom UI per platform.

IF these big guys ever figure this out it could put a lot of pressure on a tool like Xojo.

Snow Leopard

Once upon a lifetime ago Apple did a release of macOS X that was focused solely on bug fixes & performance improvements.

Over the years people using Xojo have said how they wish Xojo would do such a release. Either tick tock back and forth or some other scheme.

And usually those requests have been in comments on forums threads etc.

Well I put a feature request in feedback so others can vote for it etc and Xojo gets a good sense of how important it is

EDIT : case rocketed up the top 20 list and now has been closed as “unactionable”

Pick a decently long list of reproducible bug and fix them

That was in theory the reason we spent time to create reproducible bug reports

Disappointed that “do a release with nothing but bug fixes” is seen as unactionable.

EDIT 1 : I’ve rewritten the request in a way that it _should_ be actionable

Taking flight

This past weekend I took a novice hang glider source and it was a blast !

Some of the things it showed me

  1. rocks dont fly
  2. Norm is mostly a rock
  3. omg there are muscles there, and there, and there ?
  4. and why do all those muscles hurt now ? 😛

I’m sure a lot of people imagine that this is a simple thing and a few quick basics and pretty soon you’re running off cliffs and gliding for hours.

Turns out the flying part is the easy part.

Take off and landing is hard !

Still had a great time and might just have to try this one again.