Changing Deprecated Items in 2019r2

It’s deprecated with no replacement. No you do not need to remove it, it will still be available for many years to go (unless Apple breaks it). :wink:

But @Christian Schmitz MBS Plugins are a great replacement for the deprecated AddressBook stuff.

WOW… some of these “deprecations” verge on the edge of ludicrious

  • field.TEXT needs to be field.VALUE
  • g.DRAWRECT needs to be g.DRAWRECTANGLE
  • g.FORECOLOR needs to be g.DRAWINGCOLOR
  • g.FILLRECT needs to be g.FILLRECTANGLE
  • g.DRAWRECT needs to be g.DRAWRECTANGLE
  • g.DRAWSTRING needs to be g.DRAWTEXT
  • x.APPEND needs to be x.ADDROW
  • event OPEN needs to be event OPENING
  • SegmentedControl is now SegmentedButton
  • SelectColor is no Color.SelectedFromDialog
  • g.TEXTASCENT is now g.FONTASCENT
  • g.TEXTSIZE is now g.FONTSIZE
  • me.BACKCOLOR is now me.BACKGROUNDCOLOR
  • me.HASBACKCOLOR is now ME.HASBACKGROUNDCOLOR
  • me.COLUMNALIGNMENT is now me.COLUMNALIGNMENTAT
  • ACTION is now PRESSED

And these are just a few of the ones I found in the first project I thought I update (and each appears dozens of times)… but to make matters even worse… I had used some of the NEW keywords for other purposes, since they weren’t key words before. [for example I use BACKGROUNDCOLOR as a preference name]. So not would I need to change all the deprecations, I would need to figure what words I used for other purposes. And a lot of these changes are just for “changes sake” and autocomplete not withstanding just adds more “characters” to the source code with no real added value

No, I can’t run my project, it stops at the line System.AddressBook .

Ahhhhh, I wrote :

Var book As AddressBook book = System.AddressBook
But if I write

Var book As New AddressBook

Then it run. Xojo updated Var which replace Dim in the documentation but they didn’t write we can’t use the second method, only the first one.
UserGuide:AddressBook .

You saved my day Sascha (in fact my night, I live in France).

One more thing :
I use BevelButton but they are not optimised for DarkMode. I use BevelButton as “ToggleButton”, normal or pressed (darker). And I use them as flag. I will replace them by Segmented control with only one item. Is there a trap I should be careful of?

sigh… here is an inconsistancy… and I bet it applys to MANY more items than this.

for i=integer =0 to UBOUND(points)

Well UBOUND is deprecated… and replaced with LastRowIndex
yet this is not valid

for i=integer =0 to LASTROWINDEX(points)

you must change it to

for i=integer =0 to points.lastrowindex

Not to mention… UBOUND was changed everywhere [SegmentedControl Items]

yes… it is just semantics… but that is all a programming language IS

I realize “deprecated” is not “removed” [yet]]… but those of us who want to stay on ONE path are going to be months just changing things before being productive again

It’s not an inconsistency. Global namespace items are deprecated, except for the math functions.

Converted a whole medium-sized project over to API 2.0 in a weekend. Tested as thoroughly as I possibly could.

unless they are going to make

123.toString

work or other LITERAL. styles work they need to keep the global ones
Or force everyone to write what used to be one liners as really fugly one liners or multiple lines

[quote=457503:@Norman Palardy]unless they are going to make

123.toString

work or other LITERAL. styles work they need to keep the global ones
Or force everyone to write what used to be one liners as really fugly one liners or multiple lines[/quote]
I understand that, but I’m just commenting on what the reality is right now.

Having to train my OCD to just ignore all the deprecation warnings :slight_smile:

[quote=457503:@Norman Palardy]unless they are going to make

123.toString

work or other LITERAL. styles work they need to keep the global ones
Or force everyone to write what used to be one liners as really fugly one liners or multiple lines[/quote]
What’s wrong with “123” ? Or am I missing something?

Yes - that was deliberately a trivial example

Literal.extension method for ANY type
IE/ 123.ToHex wont work

so you either convert your code to API 2.0 which means adding a var then calling toHex on the variable
Or you stick with the old ToHex(123) which is deprecated

There are other places where this also applies
see The Global Namespace Is Now the Enemy in https://thezaz.com

EDIT - again with trivial examples of how this makes you rewrite your code you cant do

var i As Integer
var j As Integer

var s0 As String = (i + j).ToHex

where you could with the global “hex” do

Dim i As Integer
Dim j As Integer

Dim s1 As String = REALbasic.Hex(i + j)

so if you have mid, instr, hex, etc that you called with “an expression” as a parameter you may have issues trying to move it to the new form using extension methods
Its why the old framework had both
extensions cant replace 100% of the uses that the global methods were used for without requiring a decent amount of code rewriting
one of the projects I’m working on has 138 MB of code :stuck_out_tongue:

Would those globals functions not just be moved to a namespace eg integer.toHex(123) like math functions?

read my edit above
there are just a set of things you cannot do with extensions UNLESS Xojo insists on making us rewrite our code

Fair enough, I had my own extensions for int / double / boolean / date etc .toString()
Guess who has to fix 4000+ compile errors now :stuck_out_tongue:

such joy aint it ?

+100 for Xojo team developing on… :wink:

Is it a good idea to step by step better subclass or build own class for all things in Xojo?
For example new DateTime(DateTime.Now) seems to be odd…
But, maybe then even 4000+ errors.

(“123” + “456”).Left(2) does not work; so does not work 123.toString()
Scala and Kotlin do this as they do infix function call; but this seems not a good idea.
No problem to define a var for it, is it?

In a tiny program probably not
In 130 mb of code and having to go through it all to define variables for this ?
keep the global versions AND the extends- just like they are now

At least with the “new framework” you had a choice to totally ignore it (which I did).
But with API2.0 not so much. While “API1.0” still works… you get thousands of deprecation warnings, and most of the previous stuff has been removed from autocomplete… putting a huge damper on productivity

I spend 4 hours yesterday removing deprecations from a rather small project, and then tripped over some bug with subclasses (mentioned in another forum topic), So finally said “screw it” and went back to R1

Guess I’ll be saving my $$$ come the annual Black-Friday sale :frowning:

My god, the biggest RS/Xojo program I ever wrote (it was pretty huge) involved serial comms with external hardware, and great deal of it consists of midB, instrB, hex, etc with expressions as parameters. Thankfully I’m no longer responsible for its maintenance.

[quote=457520:@Norman Palardy] read my edit above
there are just a set of things you cannot do with extensions UNLESS Xojo insists on making us rewrite our code[/quote]
I highlighted this to Xojo via Feedback in July. At the time I didn’t realise the full extent of the problem as I only related it to our use of CLong. Unfortunately, my response from the start of August was never acknowledged.

The v2 API just seems like a big mess to me. Lots of stuff renamed for no benefit and lots of stuff deprecated that don’t have a direct replacement. If this doesn’t hit Xojo’s bottom line with people not renewing I would be surprised (they are more than likely two license renewals down from us).