many commands have been deprecated

  1. 3 weeks ago

    DEVSTUDIO S

    May 15 Testers, Xojo Pro

    Hi, I'm a programmer who has been using RealBasic / Xojo for many years
    Over the years I have seen that many commands have been deprecated but with an improvement sense. The command has been replaced with a different but more functional one.
    In the latest version, an abominable thing was done, many senseless commands were changed:
    VAR instead of Dim
    Rowcount instead of listcount
    deleteallrows instead of Removeallrows
    and many others including the getfolderitem
    commands only changed in the name that in fact do not change anything in functionality, but only give headaches to programmers who have to carry the sources from version to version.
    I hope you want to remedy this problem by keeping the compatibility in the 2 versions of the controls and that none of this will happen in future versions.

  2. Markus R

    May 15 Testers, Xojo Pro Europe / Germany / Lower Saxon...

    there was a long thread about after api 2 appear ...

  3. Michael H

    May 15 Testers, Xojo Pro Europe (Hamburg, Germany)
    Edited 3 weeks ago

    I’ve made the changes (not that it was strictly necessary as deprecated stuff can still be used) when they were introduced and it’s actually not such a big deal. I’ve come to terms with the new terminology which is often – although not always – clearer. And I I was quite enthusiastic about the change from Dim to Var – I’ve always hated Dim and Var was the keyword my first programming language had been using for variable declarations: Pascal (that was in 1978 I think).

  4. Rick A

    May 15 Testers, Xojo Pro (Brazil. UTC-3:00)

    @Michael Hszlig;mann I’ve made the changes ... it’s actually not such a big deal.

    If that was true, Xojo would make a code "translator". But as things potentially will break, like 1 based code needing refactoring for 0 based, they don't.

  5. Geoff P

    May 15 Xojo Inc Austin, Texas

    @Rick A If that was true, Xojo would make a code "translator". But as things potentially will break, like 1 based code needing refactoring for 0 based, they don't.

    It is our opinion that translators have to work nearly 100% perfectly or they shouldn't work be done at all. Or to put it another way, users have the expectation they will work nearly 100% perfectly.

  6. Geoff P

    May 15 Xojo Inc Austin, Texas

    @DEVSTUDIO S. Hi, I'm a programmer who has been using RealBasic / Xojo for many years
    Over the years I have seen that many commands have been deprecated but with an improvement sense. The command has been replaced with a different but more functional one.
    In the latest version, an abominable thing was done, many senseless commands were changed:
    VAR instead of Dim
    Rowcount instead of listcount
    deleteallrows instead of Removeallrows
    and many others including the getfolderitem
    commands only changed in the name that in fact do not change anything in functionality, but only give headaches to programmers who have to carry the sources from version to version.
    I hope you want to remedy this problem by keeping the compatibility in the 2 versions of the controls and that none of this will happen in future versions.

    I understand that it can be frustrating to have to learn something new when there doesn't appear to be a good reason given that you already know the existing APIs.

    At Xojo, we think about both the short term and the long term. In the long term, having a very consistent API makes the framework easier to you. It's easier to remember what the class members are for example. As someone who has used Xojo for 22 years, I can tell you that once you get used to the new names, it's easier because of the consistency. However, that does take some time. I think you will find that in the long run it's worth the investment. It's definitely worth it for us to make Xojo easier to learn and use.

  7. 2 weeks ago

    Johann K

    May 16 Perth, Australia

    to have more consistency is only true for 20% of the changes ...

  8. Geoff P

    May 16 Xojo Inc Austin, Texas

    @JohannKienbrandt to have more consistency is only true for 20% of the changes ...

    I'm not sure what you mean. Could you give an example?

  9. Michael H

    May 17 Testers, Xojo Pro Europe (Hamburg, Germany)
    Edited 2 weeks ago

    @Rick A If that was true, Xojo would make a code "translator". But as things potentially will break, like 1 based code needing refactoring for 0 based, they don't.

    Yes, switching from 1-based to 0-based isn’t a matter of search-and-replace but it’s worthwhile – making everything 0-based is the path to sanity in my view. Having said that there is no pressing need to make all the changes at once; you could start with the simple changes and turn to the more complex stuff at your leisure.

  10. Stuart L

    May 17 Tokyo, Japan

    I have only been using Xojo for a few weeks. Not sure if it is related API 1 or 2 but the inconsistency drives me crazy.

    Why is there Add for a collection, Addrow for an array and an item assignment for a Dictionary.
    In reverse there is remove for both collection and dictionary, but only a RemoveAt for an array.

    What is the point of this?

    Thanks

    stu

  11. Beatrix W

    May 17 Testers, Third Party Store Europe (Germany)

    Collection should have been removed 10 years ago. Don't use it.

    A dictionary doesn't have an order so the beyond silly AddRow doesn't make sense. The RemoveAt also doesn't make sense for a dictionary.

  12. @Geoff P — My main problem here is that there are hundreds of bugs waiting to be fixed for years and yet Xojo would rather give priority to changing method's names.

    If we want to change a RemoveAllRows method by DeleteAllRows, we can do it ourselves. What we cannot do ourselves is to make the compiler better and properly handling cases where it fails now.

    So please set your priorities right.

  13. Ulrich B

    May 17 Testers, Xojo Pro Europe (Germany, Berlin) · xo...

    @Geoff P I'm not sure what you mean. Could you give an example?

    I would not agree with the 20 %, but String.Nthfield is an unlogic that already struck me a few times. Why is this still 1-based?

  14. Alberto D

    May 17 Testers, Xojo Pro Austin, Texas

    @Ulrich B I would not agree with the 20 %, but String.NthField is an unlogic that already struck me a few times. Why is this still 1-based?

    The problem with NthField is that there is no new API 2.0 method.

    This is what is being deprecated:

    result=NthField(source, separator, fieldNumber)

    The API 2.0 way to use NthField is being available since 5.0 (don't know if that is RealBasic or RealStudio).
    This from NthField doc:

    result=stringVariable.NthField(separator, fieldNumber) Introduced 5.0

    This from String.NthField doc (API 2.0 way):

    result=stringVariable.NthField(separator, fieldNumber)

    If I were in charge of the docs, I will remove the big red box here and change the deprecated syntax only to:

    result=NthField(source, separator, fieldNumber) // This syntax is deprecated, use the other syntax

    If someone can find a good name for the NthField replacement, maybe Xojo can create an API 2.0 version that is 0 based. It can't be NthField because that will break old code that use the String.NthField syntax.

    String.NthField2 to indicate is API 2.0 ? or String.NthField0 to indicate that is 0 based?

  15. Sam R

    May 17 Testers, Xojo Pro, Third Party Store Hengchun, Pingtung, Taiwan

    You can always create your own Nthfield. Hint: Use instrb

  16. Julia T

    May 17 Sandy Hook, Connecticut

    I never had any problems, from Day One of my use of RealBasic/Studio/Xojo, with the fact that string functions were all one-based, and everything else was zero-based. Just not an issue at all. Now it's become an issue, because I have to unlearn :(

  17. Karen A

    May 17 Testers

    @Julia T I never had any problems, from Day One of my use of RealBasic/Studio/Xojo, with the fact that string functions were all one-based, and everything else was zero-based.

    Some say that Files indexes in folders were 1 based... but that was not true.. originally the 0th item was the parent folder!

    The only place that they really messed up in API 1 IMO was in the database Recordset methods where RecordSet.ColumnType is 0 based while RecordSet.IdxField is 1 based... I do trip over that one a lot!

    -Karen

  18. Julia T

    May 17 Sandy Hook, Connecticut

    @Karen A RecordSet.IdxField is 1 based

    I'm not a database user, so never encountered that, but yeah, it sounds like that should definitely be zero-based.

  19. Emile S

    May 17 Europe (France, Strasbourg)

    Checking the LR for 0 or 1 based is far less than an annoyance (for me).

    But reaching how to replace http://docs.xojo.com/GetFolderItem is real challenge: it takes far more time.

  20. Stuart L

    May 17 Tokyo, Japan

    @Beatrix W Collection should have been removed 10 years ago. Don't use it.

    A dictionary doesn't have an order so the beyond silly AddRow doesn't make sense. The RemoveAt also doesn't make sense for a dictionary.

    Thank you for responding, I will not use collection any more.

    An Add method to go with the Remove method on the dictionary would be nice though. :)

  21. Newer ›

or Sign Up to reply!