Writings from the sticks

The pic says it all

Suppose you want to do something like a set of preferences that are a simple key/value pairing.

A dictionary seems a great choice. Its keys can be any type and the values any type because both are variants.

So far so good.

Now you can do something like

dim i as integer = PrefsDict.Value("keyForIntegerValuedPreference")

And all seems great ! i gets an integer value and life is good

Except that this is ALSO legitimate

dim s as string = PrefsDict.Value("keyForIntegerValuedPreference")

And now your “strongly typed” system is fubarred. And the Xojo compiler will not complain

So how are you going to get an integer from something that SHOULD be an integer, and a string from something that should be a string ?
And get the compiler to help you do this ?

If you just use a dictionary you wont be able to. Its accessors dont have that capability.

You could try

GetValue(extends d as dictionary, key as variant) as Integer
GetValue(extends d as dictionary, key as variant) as String

but it wont work. Xojo doesn’t support multiple methods with the same signature and only differeing in return type 🙁

So how could you do this AND get the compiler to help you out ? What if instead of return values (which I will admit would be nicer) you do

GetValue(extends d as dictionary, key as variant, byref value as Integer)
GetValue(extends d as dictionary, key as variant, byref value as String)

and so on for every type ?

Now the compiler will tell you when you try to do something unsupported.
In our example with only integer and string values supported if we did

dim d as double
PrefsDict.GetValue("keyForIntegerValuedPreference", d)

the compiler would tell us this isnt supported

Its about the best we can hope for until/unless Xojo alters the compiler to permit several return types (and does the correct work to make use of it) In theory Xojo could make it so the compiler matched the right signature with the right return type to whatever is expected (like the following)

Dim i as integer = PrefsDict.GetValue("keyForIntegerValuedPreference") // would call the integer returning version
dim s as string = PrefsDict.GetValue("keyForStringValuedPreference") // would call the String returning version

Xojo decided to change Feedback statuses on reports by essentially telling users less.

So instead of knowing what reports have been reviewed and found to be reproducible by their testing staff, which ones have been verified as bugs by development staff, etc everything is now just “Open” until one day it may reach some other status.

The change wasnt welcomed by many by like other changes the blog post wasnt a proposal but a heads up that this is what we’re going to do

And now it appears to be done

So my numbers look like

Closed (Already Exists) 8 (+1 from last)
Closed (By Design) 46 (+1 from last)
Closed (Duplicate) 50 (+1 from last)
Closed (Misc) 34 (+3 from last)
Closed (No Longer Reproducible) 5 (+3 from last)
Closed (Not Actionable) 7
Closed (Not Reproducible) 45 (+1 from last)
Fixed 2 (-9 from last)
Fixed & Verified 118 (+11 from last)
Implemented & Verified 16 (+1 from last)
Open 464 (+18 from last)
Resolved 2

Suppose there is a software product that sells brand new for $99

And once you own one you can update it for 50% off

If you can attract 500 new users every year then you should go after new users since you earn more money than if 500 existing users renew. 2x as much.

Now suppose you adopt Apples full price renewal model ?

New or renewals now bring in the same amount of revenue.

So who should you focus on ?

Marketing 101 tells us it’s easier to sell to people who already use your product. And it’s easier to upsell them since they already have experience with the product. The cost to get those people to update to a new version should be lower than the costs to attract new users.

And existing users might care more about bug fixes than new features. They might actually have a more balanced preference.

Just a thought

Over the years I’ve seen lots of people say they buy a license whether they intend to actually use it or not JUST to support Xojo.

If thats you I’d sure willingly accept what ever extra cash you have to put to things you wont use and I’m sure I can write you some in short order.

Of course I’m being facetious.

Seriously though do you send money to MS for licenses you don’t use ? Apple ? Do you send Ford money “just to support their efforts” ?

Sure those are all giant corporations that probably wouldn’t notice if you did or didn’t.

So how about your local grocer ? A small store you stop in during your day ? The trendy coffee shop ? Do you just stop in there and hand them 20 bucks “just because” ?

If not then WHY would you with ANY vendor ?

If that vendor makes a product you depend on, and they go out of business it is painful (been there done that at least once) But your single license purchase also isn’t likely going to sustain time for very long either.

Either they make a product you, and many others can depend on for a long time. Or not.

In the mean time if you have that extra few hundred $ to toss around I can think of lots of charities that could use it.

Xojo Inc. ISN’T a charity. Why treat them like one and just send money “just because”.

deltas are the change since Feb 23, 2021

Closed (Already Exists) 7 (+1 from last report)
Closed (By Design) 45 (+7)
Closed (Duplicate) 49 (+17)
Closed (Misc) 31 (+6)
Closed (No Longer Reproducible) 2 (+2)
Closed (Not Actionable) 7 (+4)
Closed (Not Reproducible) 44 (+6)
Closed (Won’t Implement) 8 (+1)
Fixed 11 (+6)
Fixed & Verified 107 (+16)
Implemented 1 (-1)
Implemented & Verified 15 (+6)
Needs Review 16 (+10)
Reproducible 174 (+33)
Resolved 2 (no change)
Reviewed 222 (+33)
Verified 34 (5)

Open 446 (+81)
Closed 329 (+70)

Some time ago I posted about making 2019r1.1 work on newer versions of macOS

And there are reports that a related technique can be used to enable older versions as well (post copied here for posterity sake)

I ran into this problem today when I wanted to use an older version of Xojo (2018 R4) on Monterey. I found a simple solution that works at least for running the app from Xojo. I could not test if it also works for building Mac apps, because I don’t have a desktop license. Obviously, the better solution is probably to modify your code so that it runs with a more recent version of Xojo (and buy the Xojo upgrade if necessary).

• Run the Xojo app at least once, so that Gatekeeper is out of the way and you can modify Xojo.
• Right-click the Xojo app and choose “Show package contents”.
• Go to the folder Contents/Resources/SDKStubs/macosx10.14/System/Library/Frameworks/AppKit.framework
• Open the file AppKit.tbd with a text editor like BBEdit.
• Under “reexports”, you’ll find the problematic UIFoundation framework that’s referenced in the error message from the linker (/System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation).
• Simply remove this text (/System/Library…) and the preceding comma. Don’t delete the closing bracket, it should now be where the deleted comma used to be.
• Save the file.

Now Xojo will run your apps again.

A couple years back I joined the Canadian Ski Patrol

Normally we’d have to requalify as a patroller every year. But since 2020 was deep in the pandemic at the time the CSP extended every ones qualification for a year.

So unlike most years we didnt have to do exams last year.

Which brings us to this year. We did.

And I have to admit that exams do NOT normally cause me any anxiety. Except this. There is both a written and diagnostic component. 100 multiple choice questions which for some reason I didnt feel prepared. And then they set up a scenario that you have to walk into, diagnose a patient and determine the correct course of action to take.

AND Yay I passed both ! First try !!!!!!!

Now I can quit waking up at 3am thinking “Am I ready ?”

Many many years ago when REALbasic first wrote the IDE in REALbasic it was said

“We’re also ‘eating our own dog food,’” said Perlman. Previous releases of REALbasic were coded using the C++ language, although with REALbasic 5.5, the last significant update, the groundwork was laid to add pieces that were written in REALbasic. When REALbasic 2005 is released, the entire Integrated Development Environment (IDE) will have been recoded in REALbasic itself.

“That has some benefits for our customers, most of them indirect” said Perlman. The engineers who are developing REALbasic are now having an experience more in line with their customers’ own experience, which gives them a better sense of what does and doesn’t work.

https://www.macworld.com/article/174461/realbasic-45.html

The various API changes made over the past 2+ years should be treated the same. They fundamentally change users experience. When Xojo’s team isn’t using the same API’s day in day out that users are the disconnect is as if they are writing in a completely different language.

As of Oct 18, 2021

Closed (Already exists) 7
Closed (By Design) 45
Closed (duplicate) 48
Closed (Misc) 31
Closed (No Longer Reproducible) 2
Closed (Not Actionable) 7
Closed (Not Reproducible) 44
Closed (Won’t Implement) 8
Fixed 8
Fixed & Verified 107
Implemented 1
Implemented & Verified 15
Needs Review 10
Reproducible 176
Resolved 2
Reviewed 217
Verified 32

Overall 435 Open cases