If it compiles when I press run …

Folks come to expect that if I press run and the code compiles that when I press build it will still compile.
And realistically why shouldn’t it ?
Run builds an actual application and, for the most part, the only difference was that now in a Xojo debug run the debug app has a bit of code in it for the IDE to talk to and control and query back and forth.

Other than that its “the same”

Except now.

With the addition of Workers what can happen is you can write code that, when you RUN, uses threads. And that means that certain code will appear to compile – although it might not do anything useful.

But when you BUILD now the IDE will compile that worker in to a separate console application.

Which means that your code that worked while you hit run all the time might no longer work. Or even compile.

I submitted this bug report about it Oct 10, 2020

Things that go unanswered

From Xojo’s forums where no one has bothered to answer that _could_ answer

Container Control Init

Should Container Controls be receiving set calls on computed properties before the open event fires?

Yes. When Xojo creates the layout that contains the container it effectively sets EVERY property regardless. Its as if you wrote :

dim c as new ContainerControl
c.property = value
c.property = value
... and so one for EVERY property ...
and now the Open Event can be raised

Setting left/right margins to 0

I am trying to add “MarginLeft=0” and “MarginRight=0” to the setupstring. I have
settings=ps.SetupString and can dump the values in settings but the margins are not setup by default so I want to force it.

I’ve searched for a while but cannot find a way to add those two entries.

In general no you cant / shouldnt try to stuff values in there manually as this “string” is not meant to always be human readable to modifiable like this. MBS has plugins for Windows & MacOS that will permit you to control this in greater depth

Is it built in or …

Xojo has a pretty handy language feature called “extension methods”

They can be used by anyone to add functionality to any existing class. And they cane/have been used by Xojo to do exactly this.

For instance, the currency class has no built in functions to convert itself to a string, from a string, etc. Yet when you enter code like

Dim c As Currency

s = Currency.

and press tab you will see various methods presented.

You can see some of this when you select one option and then view the hint at the bottom of the editor

Normally it doesnt matter that a function is or isnt done this way.

Unless you expect things in XojoScript to also have these functions. They wont exist because the module(s) that provide all these handy functions are not part of the framework available to XojoScript.

And so code that would work in Xojo may not work in XojoScript.

Is this just rearranging deck chairs ?

On the forum theres a long thread about altering how the points in Feedback work and how they can be assigned.

I have to admit that from my perspective, and seemingly from others, the issue is not so much with gathering reports, but the “processes” that occur after gathering reports.

Currently we can assign points to reports by making them favourites. This at least indicates the 5 items each person considers high priority. And because more points go to higher priced licenses it also gives people who hold Pro and Pro+ licenses more influence when they do select a case to be a favourite.

Xojo frequently says that feedback is NOT the only criteria they use. They also consider the scope of the issue. I’m not sure how they assess this though.

Isn’t that what a lot of users making a case one of their top 5 cases _should_ indicate already ?

Even if the points system is overhauled does that changes the internal processes they have around Feedback ?

What priority _should_ a bug that causes a reproducible crash have – whether it has points assigned or not ? Or an exception that causes the IDE to lose whatever it is you’ve been working on ?

It would seem to me that those kinds of nicely reproducible bugs that cause fatal problems should have high priority regardless of how many points they have.

I’d think the KIND of case matters – sometimes more than how many points it has.

As Thom said on that thread

That’s where I think Feedback’s effort needs to be. The human element. Not to say the technical element is perfect, of course.

https://forum.xojo.com/t/the-feedback-points-system/57327/37

Thom wrote the initial versions of Feedback – they been updated since – but he’s not wrong. He worked at Xojo. As did I.

Case report acquisition isnt the issue. And in my opinion rearranging or redefining the points system is just rearranging deck chairs and not dealing with the actual problem.

Careful with your IDE & Xojo scripts

The project I’m working on uses a TON of XojoScript.

And for the most part I can test things in the IDE script editor window since that also runs XojoScript code. It just has a different context assigned to it that permit access to the IDE.

However, recently my apps with the XojoScript code would crash.

So I then tried the code in the IDE script editor window and to my surprise that crashed the entire IDE.

You can see one of my vastly trimmed down scripts in the feedback case attached to this report and this other one

Heads up !

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.