Automating adding comments

In Xojo I often need to add in a comment about when I modified something or what I was working on
And the comment needs to be in a particular format – and it needs the current date & time as part of the comment
And, I want to be able to insert these EASILY into whatever code I’m working on right where the insertion point is

To do this I came up with this IDE Script that I saved in my Scripts dir next to the IDE

Dim stripped As String
stripped = DoShellCommand("echo ""// Updated `/bin/date ""+%Y-%m-%d %H:%M:%S %Z""` -- NJP"" | /usr/bin/tr -C -d ""[:print:]"" | /usr/bin/pbcopy -Prefer txt")

DoCommand("Paste")

this will make use of the DoShellCommand to get the unix shell to write a line with the current date in it, copy that to the clipboard, and then paste it right where the insertion point is

You can modify the unix shell commands used to do just about whatever else you want

Archived cases to be reopened

Posting this list here so its publicly known these exist & should be reopened
I’d post this list on TOF as well if I could

http://feedback.xojo.com/case/55562
http://feedback.xojo.com/case/55777
http://feedback.xojo.com/case/56094
http://feedback.xojo.com/case/56923
http://feedback.xojo.com/case/55319
http://feedback.xojo.com/case/57381
http://feedback.xojo.com/case/57380
http://feedback.xojo.com/case/56113
http://feedback.xojo.com/case/57125
http://feedback.xojo.com/case/56765
http://feedback.xojo.com/case/56233
http://feedback.xojo.com/case/57500

if you have your own list add to the thread on INN


Why you should subscribe to feedback cases

One of the criteria Xojo uses is number of voters (or subscribers) to judge how important a case is

Its been repeated that

I’m told it’s not that important to Xojo users or else they would have voted for it. So I’m going to rally the troops here and ask you to vote for it.

Because of how they rate importance it is important that you subscribe to bugs, not just read the case and hope Xojo does something about it.

Multiple return types dream

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

The great opening

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

New vs renew

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

If you have money to throw around

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”.

Numbers

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)